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