Hi Guys,

Just wanted to settle an argument with a colleague.

I'm using a 3rd party business application that uses extended MAPI to generate and send simple emails via SMTP (To, Subject, Message Body and attachment) in Outlook with things like invoices, remittances attached. The problem I'm having is that the date header is missing from emails generated this way. This results in a number of emails being rejected as spam by certain email servers (Error 552 - no date header....)

My question is then who is responsible for ensuring these emails are RFC2822 compliant?(ie include the origination date in the header) The MTA, MUA or the 3rd party business application? I suspect the business app, but my colleague insists the MUA, as the date can only be known when the command to send (ie pushing the send button) is made.

Thanks in advance

Andy.

Microsoft Outlook or Outlook Express (which is part of Internet Explorer)?



"ezandy" wrote in message
...

Hi Guys,

Just wanted to settle an argument with a colleague.

I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body and
attachment) in Outlook with things like invoices, remittances attached.
The problem I'm having is that the date header is missing from emails
generated this way. This results in a number of emails being rejected
as spam by certain email servers (Error 552 - no date header....)

My question is then who is responsible for ensuring these emails are
RFC2822 compliant?(ie include the origination date in the header) The
MTA, MUA or the 3rd party business application? I suspect the business
app, but my colleague insists the MUA, as the date can only be known
when the command to send (ie pushing the send button) is made.

Thanks in advance

Andy.




--
ezandy

ezandy;49468 Wrote:
Hi Guys,

Just wanted to settle an argument with a colleague.

I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body and
attachment) in Outlook with things like invoices, remittances attached.
The problem I'm having is that the date header is missing from emails
generated this way. This results in a number of emails being rejected
as spam by certain email servers (Error 552 - no date header....)

My question is then who is responsible for ensuring these emails are
RFC2822 compliant?(ie include the origination date in the header) The
MTA, MUA or the 3rd party business application? I suspect the business
app, but my colleague insists the MUA, as the date can only be known
when the command to send (ie pushing the send button) is made.


My take: The sending client can add it (and most do) but if the date is
missing, the SMTP should add it - its the responsiblity of the MTA to
make sure its there. The 3rd party biz app could be considered a client
since it is generating the message... so you are both correct.

f.h. should know for sure - he's a student of the RFCs.


--
Slipstick

'Outlook & Exchange Solutions Center' (http://www.slipstick.com)

'Outlook Tips' (http://www.outlook-tips.net/)
http://forums.slipstick.com/

I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body
and attachment) in Outlook with things like invoices, remittances
attached. The problem I'm having is that the date header is missing
from emails generated this way. This results in a number of emails
being rejected as spam by certain email servers (Error 552 - no date
header....)

My question is then who is responsible for ensuring these emails are
RFC2822 compliant?(ie include the origination date in the header) The
MTA, MUA or the 3rd party business application? I suspect the
business app, but my colleague insists the MUA, as the date can only
be known when the command to send (ie pushing the send button) is
made.

My take: The sending client can add it (and most do) but if the date
is missing, the SMTP should add it - its the responsiblity of the MTA
to make sure its there. The 3rd party biz app could be considered a
client since it is generating the message... so you are both correct.


f.h. should know for sure - he's a student of the RFCs.


Good thing this was the only message in my last download or I'd never have
noticed it.

Based on the RFC and the wording below, the client is the responsible party
for entering the data.

3.6.1. The origination date field

The origination date field consists of the field name "Date" followed
by a date-time specification.

orig-date = "Date:" date-time CRLF

The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message
for delivery. The origination date is intended to contain the date
and time that the user queued the message, not the time when the user
connected to the network to send the message.)

A server should not pay attention to the header. Section 3.3 of 2821:

When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body. In particular,
they MUST NOT reject messages in which the numbers of Resent-fields
do not match or Resent-to appears without Resent-from and/or Resent-
date.

But, of course, should != must. As for whether the server may add a date:
Yes. Section 6.3 of 2821:


The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting protocol:

- Addition of a message-id field when none appears

- Addition of a date, time or time zone when none appears

So, technically, it is the User Agent that should be adding the date. The
SMTP server may, or may not, add the date. It isn't required to by the rules.

And, in this case, that'd be your business app, because if you're just using
extended mapi to create an SMTP message, Outlook isn't the user agent, your
application is. Whatever is submitting to the SMTP stream is the UA. If Outlook
was actually sending the message, it'd add the Date field just fine. (but
my OL programming skills aren't strong, so I bet slipstick would be better
on that front).

--
f.h.
Microsoft Outlook MVP

Section 6.3 of 2821:

The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting protocol:

- Addition of a message-id field when none appears

- Addition of a date, time or time zone when none appears


This is what I remembered... so I was half right. g

I don't code much anymore either... outlookcode.com is the place to go for
that.

--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com

Outlook Tips by email:


EMO - a weekly newsletter about Outlook and Exchange:


Let's Really Fix Outlook 2010
http://forums.slipstick.com/forumdisplay.php?f=34

"F.H. Muffman" wrote in message
.com...
I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body
and attachment) in Outlook with things like invoices, remittances
attached. The problem I'm having is that the date header is missing
from emails generated this way. This results in a number of emails
being rejected as spam by certain email servers (Error 552 - no date
header....)

My question is then who is responsible for ensuring these emails are
RFC2822 compliant?(ie include the origination date in the header) The
MTA, MUA or the 3rd party business application? I suspect the
business app, but my colleague insists the MUA, as the date can only
be known when the command to send (ie pushing the send button) is
made.

My take: The sending client can add it (and most do) but if the date
is missing, the SMTP should add it - its the responsiblity of the MTA
to make sure its there. The 3rd party biz app could be considered a
client since it is generating the message... so you are both correct.


f.h. should know for sure - he's a student of the RFCs.


Good thing this was the only message in my last download or I'd never have
noticed it.

Based on the RFC and the wording below, the client is the responsible
party for entering the data.

3.6.1. The origination date field

The origination date field consists of the field name "Date" followed
by a date-time specification.

orig-date = "Date:" date-time CRLF

The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message
for delivery. The origination date is intended to contain the date
and time that the user queued the message, not the time when the user
connected to the network to send the message.)

A server should not pay attention to the header. Section 3.3 of 2821:

When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body. In particular,
they MUST NOT reject messages in which the numbers of Resent-fields
do not match or Resent-to appears without Resent-from and/or Resent-
date.

But, of course, should != must. As for whether the server may add a date:
Yes. Section 6.3 of 2821:


The following changes to a message being processed MAY be applied
when necessary by an originating SMTP server, or one used as the
target of SMTP as an initial posting protocol:

- Addition of a message-id field when none appears

- Addition of a date, time or time zone when none appears

So, technically, it is the User Agent that should be adding the date. The
SMTP server may, or may not, add the date. It isn't required to by the
rules.

And, in this case, that'd be your business app, because if you're just
using extended mapi to create an SMTP message, Outlook isn't the user
agent, your application is. Whatever is submitting to the SMTP stream is
the UA. If Outlook was actually sending the message, it'd add the Date
field just fine. (but my OL programming skills aren't strong, so I bet
slipstick would be better on that front).

--
f.h.
Microsoft Outlook MVP

So far, Outlook Express and Windows Mail

Hope this helps.

TIA

Andy

"ezandy" wrote in message
...

So far, Outlook Express and Windows Mail

Then you're asking in the wrong newsgroup. As in
microsoft.public.outlookexpress.general
--
Brian Tillman [MVP-Outlook]

I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body
and attachment) in Outlook with things like invoices, remittances
attached.

Are you sending it through Outlook using ExMapi or through Outlook Express?


--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com

Outlook Tips by email:


EMO - a weekly newsletter about Outlook and Exchange:


Let's Really Fix Outlook 2010
http://forums.slipstick.com/forumdisplay.php?f=34

"ezandy" wrote in message
...

So far, Outlook Express and Windows Mail

Hope this helps.

TIA

Andy



'K. Orland[_2_ Wrote:
;314283']Microsoft Outlook or Outlook Express (which is part of Internet
Explorer)?



"ezandy" wrote in message
...-

Hi Guys,

Just wanted to settle an argument with a colleague.

I'm using a 3rd party business application that uses extended MAPI to
generate and send simple emails via SMTP (To, Subject, Message Body
and
attachment) in Outlook with things like invoices, remittances
attached.
The problem I'm having is that the date header is missing from emails
generated this way. This results in a number of emails being rejected
as spam by certain email servers (Error 552 - no date header....)

My question is then who is responsible for ensuring these emails are
RFC2822 compliant?(ie include the origination date in the header) The
MTA, MUA or the 3rd party business application? I suspect the
business
app, but my colleague insists the MUA, as the date can only be known
when the command to send (ie pushing the send button) is made.

Thanks in advance

Andy.




--
ezandy-




--
ezandy

Thanks for everyone's responses.

Apologies, I may have confused the issue somewhat.

I'm generating emails from the business app using extended mapi, which dumps email message + attachments in the outbox of outlook (not express or mail) and then sends.

The real issue for me is where the responsibility lies is adding this header to the message. No doubt RFC 2822 is basic compliance and observed by all applications capable of generating email messages.

My initial thoughts were either the business app or Outlook. SMTP servers can be configured to various degrees to reject emails without a date header. Additionally so can spam filters.

If it is the responsibility of the business app to add the date header through ExMapi, then surely this must be a short-coming and one that must be addressed by the vendor?!?!

Alternatively, if ExMapi cannot do this, then I would think that the MUA is responsible. How else could email messages from Outlook comply in the first place.

As is plainly evident, I'm a troglodyte on this matter, but at least it will give me a starting point, as this issue is impacting my business!

Thanks,

Andy

Ok so it sounds to me like the client (in this case the business app) should be adding the date in the header, BUT SMTP servers must not reject emails based on no date in the header.

I think I'm getting closer (or possibly not!!)

Cheers

Andy