Outlook 2003 delayed emails

V

Vanguard

Pete c said:
...

You are correct to identify the message ID as a source of the
problems.

Emails without message IDs get stuck at our server, and a manual
process is undertaken to clear these. This is why you are experiencing
the delays. This process is to stop 'spoofing', whereby users sending
unsolicited mail hide the true origin to cover their tracks. These
emails are then manually checked for their validity before being
forwarded to the recipient.
...

Then reply back to Wanadoo that they are VIOLATING the RFC 2821 and RFC
2822 standards for SMTP. The Message-ID headers is ***OPTIONAL***. The
e-mail client (MUA) does NOT have to provide one. According to RFC
2822, Internet Message Format, 3.6 Field Definitions, the MUA may insert
the Message-ID header zero or one times. That means this header is
optional (as it may appear zero times) and, if specified, can appear a
maximum of once. According to RFC 2821, Simple Mail Transfer Protocol,
6.3 Compensating for Irregularities, the mail server (MTA) can add a
Message-ID header *if* it wants to add the header but it can add this
header ONLY if it is missing in the content transferred during the DATA
command to their SMTP server.

So is is NOT a requirement that the MUA (mail user agent) include the
Message-ID header. If and only if it is missing in the content
transferred in the DATA command from the MUA, and only if the MTA (mail
transfer agent) deems that this header should be present, the MTA can
add this header. Tell Wanadoo their mail server is ****ed up. They are
enforcing their own non-compliant policies. That's their choice but
then they need to announce that fact in the help web pages, in their
setup help, notify their tech support reps, and also realize that they
are barring MANY e-mail clients from using their e-mail service or
causing problems with its use. Fact is, it seems users could retaliate
by spewing as many e-mails as they could that do not include the
Message-ID header to force Wanadoo to expend even greater resources in
manually handling these e-mails to the point that they wise up and
decide to make the mail servers compliant with the RFC standards. Make
them work even harder at enforcing their non-compliant and
personal-choice policies.

By the way, if the MUA (mail user agent) is generating the unique
identifier string in the Message-ID header then the mail server cannot
ever check its validity since the mail server wasn't the one that
generated the unique string identifier. Their mail server will somehow
query my e-mail client that it was the one that generated the unique
identifier string? Yeah, sure, uh huh. RFC 2822, Internet Message
Format, says:

Section 3.6.4 Identification fields:
"The Message-ID field provides a unique message identifier that refers
to a particular version of a particular message. The uniqueness of the
message identifier is guaranteed by the host that generates it."

Since Wanadoo isn't generating the unique identifier, and instead your
e-mail client generates that string, there is no way anyone at Wanadoo
can verify whether or not it is a valid identifier. They only part of
the string that Wanadoo can check is the domain portion after the
at-character. However, while the unique identifier contains the domain
that could be the internal domain of the user rather than of an external
ISP. The syntax for the Message-ID header's msg-id value is:

message-id = "Message-ID:" msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-right = dot-atom-text / no-fold-literal / obs-id-right

(CFWS is folding white space). It does not dictate that the id-right
token must contain a domain (except in the obsolete version) but it
seems the de facto standard that id-right contains the domain. Since
you are running your e-mail client on your computer which may be within
your own domain, there is no guarantee that the domain used by the
e-mail client will have anything related to some external domain (i.e.,
your ISP) and obviously your internal domain is not likely to be the
same as the external domain for your ISP. If Wanadoo wants to ensure
the Message-ID is distintive to their e-mail accounts then Wanadoo needs
to add the Message-ID header itself to every outbound e-mail (and
discard any that was added by the e-mail client).
 
V

Vanguard

Pete c said:
...
You are correct to identify the message ID as a source of the
problems.

Emails without message IDs get stuck at our server, and a manual
process is undertaken to clear these. This is why you are experiencing
the delays. This process is to stop 'spoofing', whereby users sending
unsolicited mail hide the true origin to cover their tracks. These
emails are then manually checked for their validity before being
forwarded to the recipient.

(Sent this twice before. Didn't appear on msnews.microsoft.com, or it
showed as "no longer on server" although just posted today. Maybe the
third time is charmed, and will try a different NNTP server. So forgive
if you see my post 3 times. Microsoft's server accepted my posts but
won't show them [to me], and I didn't see a FollowUp-To header that
would hide my reply into some other group.)

Then reply back to Wanadoo that they are VIOLATING the RFC 2821 and RFC
2822 standards for SMTP. The Message-ID headers is ***OPTIONAL***. The
e-mail client (MUA) does NOT have to provide one. According to RFC
2822, Internet Message Format, 3.6 Field Definitions, the MUA may insert
the Message-ID header zero or one times. That means this header is
optional (as it may appear zero times) and, if specified, can appear a
maximum of once. According to RFC 2821, Simple Mail Transfer Protocol,
6.3 Compensating for Irregularities, the mail server (MTA) can add a
Message-ID header *if* it wants to add the header but it can add this
header ONLY if it is missing in the content transferred during the DATA
command to their SMTP server.

So is is NOT a requirement that the MUA (mail user agent) include the
Message-ID header. If and only if it is missing in the content
transferred in the DATA command from the MUA, and only if the MTA (mail
transfer agent) deems that this header should be present, the MTA can
add this header. Tell Wanadoo their mail server is ****ed up. They are
enforcing their own non-compliant policies. That's their choice but
then they need to announce that fact in the help web pages, in their
setup help, notify their tech support reps, and also realize that they
are barring MANY e-mail clients from using their e-mail service or
causing problems with its use. Fact is, it seems users could retaliate
by spewing as many e-mails as they could that do not include the
Message-ID header to force Wanadoo to expend even greater resources in
manually handling these e-mails to the point that they wise up and
decide to make the mail servers compliant with the RFC standards. Make
them work even harder at enforcing their non-compliant and
personal-choice policies.

By the way, if the MUA (mail user agent) is generating the unique
identifier string in the Message-ID header then the mail server cannot
ever check its validity since the mail server wasn't the one that
generated the unique string identifier. Their mail server will somehow
query my e-mail client that it was the one that generated the unique
identifier string? Yeah, sure, uh huh. RFC 2822, Internet Message
Format, says:

Section 3.6.4 Identification fields:
"The Message-ID field provides a unique message identifier that refers
to a particular version of a particular message. The uniqueness of the
message identifier is guaranteed by the host that generates it."

Since Wanadoo isn't generating the unique identifier, and instead your
e-mail client generates that string, there is no way anyone at Wanadoo
can verify whether or not it is a valid identifier. They only part of
the string that Wanadoo can check is the domain portion after the
at-character. However, while the unique identifier contains the domain
that could be the internal domain of the user rather than of an external
ISP. The syntax for the Message-ID header's msg-id value is:

message-id = "Message-ID:" msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-right = dot-atom-text / no-fold-literal / obs-id-right

(CFWS is folding white space). It does not dictate that the id-right
token must contain a domain (except in the obsolete version) but it
seems the de facto standard that id-right contains the domain. Since
you are running your e-mail client on your computer which may be within
your own domain, there is no guarantee that the domain used by the
e-mail client will have anything related to some external domain (i.e.,
your ISP) and obviously your internal domain is not likely to be the
same as the external domain for your ISP.

If Wanadoo wants to ensure
the Message-ID is distintive to their e-mail accounts then Wanadoo needs
to add the Message-ID header itself to every outbound e-mail (and
discard any that was added by the e-mail client).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top