Missing Date Header in Outlook Express

Status
Not open for further replies.
E

ezandy

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
 
K

K. Orland

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

"ezandy" <ezandy.4a105e1@outlookbanter.com> wrote in message

news:ezandy.4a105e1@outlookbanter.com...

> 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
 

Forum Admin

Senior Member
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.
 
F

F.H. Muffman

>> 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
 

Diane Poremsky

Senior Member
Outlook version
Outlook 2016 32 bit
Email Account
Office 365 Exchange
>
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. :)



"F.H. Muffman" <f.h.muffman@hotmail.com> wrote in message

news:1d3d24f84d0838cbd1dfb47c53f3@msnews.microsoft.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

>
 
E

ezandy

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" ezandy.4a105e1@outlookbanter.com wrote in message
> news:ezandy.4a105e1@outlookbanter.com...-

> 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
 

Brian Tillman

Senior Member
"ezandy" <ezandy.4a1aea2@outlookbanter.com> wrote in message

news:ezandy.4a1aea2@outlookbanter.com...


> So far, Outlook Express and Windows Mail


Then you're asking in the wrong newsgroup. As in

microsoft.public.outlookexpress.general

--
 

Diane Poremsky

Senior Member
Outlook version
Outlook 2016 32 bit
Email Account
Office 365 Exchange
>>> 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?



"ezandy" <ezandy.4a1aea2@outlookbanter.com> wrote in message

news:ezandy.4a1aea2@outlookbanter.com...

> 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" ezandy.4a105e1@outlookbanter.com wrote in message
> > news:ezandy.4a105e1@outlookbanter.com...-
>

>> 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
 
E

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

'Diane Poremsky [MVP Wrote:
> ;314426'] 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?

> >

>

>

>

> "ezandy" ezandy.4a1aea2@outlookbanter.com wrote in message
> news:ezandy.4a1aea2@outlookbanter.com...-

> 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" ezandy.4a105e1@outlookbanter.com wrote in message
> news:ezandy.4a105e1@outlookbanter.com...-

> 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 -


ezandy
 
E

ezandy

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

ezandy;314565 Wrote:
> 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


ezandy
 

Diane Poremsky

Senior Member
Outlook version
Outlook 2016 32 bit
Email Account
Office 365 Exchange
Right - the biz app should do it, but if not then the smtp server that

accepts it should do it. I personally think outlook should since it is

handing it off, but apparently its getting dropped into the outbox in such a

way that outlook can't add it.

What app is it?



"ezandy" <ezandy.4a3547f@outlookbanter.com> wrote in message

news:ezandy.4a3547f@outlookbanter.com...

> 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!!)
>
 
F

F.H. Muffman

>> 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!!)


> Right - the biz app should do it, but if not then the smtp server that
> accepts it should do it. I personally think outlook should since it is
> handing it off, but apparently its getting dropped into the outbox in
> such a way that outlook can't add it.


The server shouldn't 'should' do it, the server should 'may' add it.

Horrible grammar, but I think it's vaguely clear.

Basically, the server doesn't have to add it, there's absolutely no rule

saying it should, just that it can. I'd argue that it shouldn't do it, but

since the rules don't go either way, we're both right.

And I agree about how its getting into the outbox. In fact, lets reverse

engineer it.

The Date field is actually set by when the client submits a message into

the queue, not the server queue but the local queue. NNTP messages are the

same way, you reply offline at 10pm, but don't sync until the next day at

7a, all the posts come in with 10p timestamps (or should, last I checked).

So, the 2822 header must get built somewhere in the clicking of the 'send'

button (or alt/ctrl-enter). Whatever internal code is being called gets skipped

by the business app which just drops into the outbox.

So, your app is letting Outlook do the mailing, making your app not the user

agent, but leaving Outlook to be the user agent. Which means Outlook is responsible

for adding the date.

However, whatever method you're using to get the message into the Outbox

seems to circumvent the code that creates the SMTP header. I don't see an

easy way to get to the Internet Headers via the gui for a message in the

Outbox to verify this, so you might want to pop into one of the coding forums

to see if there's a way to get this to work better.

Or, conversely, just configure your app to not use Outlook and just speak

SMTP and actually be the user agent.

f.h.

Microsoft
 
Status
Not open for further replies.

Top