From: "Matti Aarnio" <mea(_at_)nic(_dot_)funet(_dot_)fi>
On Thu, Jun 30, 2005 at 11:03:50AM +0200, Arnt Gulbrandsen wrote:
I would have used strict-rfc822 mode in my work production systems,
if it would not reject something like 95% of users who send thru their
ISP master relays...
MS Outlooks do put those extra white-spaces in there blatantly..
At my own private system I use strict syntax processing, and those
who can't send because of it, well.. tough. However I can't do
that for paying customers :-(
Very true.
But now, what are really talking about here?
Strict RFC822 and/or RFC 2822 compliancy across the board?
If we begin to use this "MAIL FROM:sp" (and "RCPT TO:sp") syntax mite as a
strict reject in the name of spam or as a indicator for spam, then you also
apply the same consideration for other entities of the state machine. We
can't pick one thing like this and skip all other considerations, such as
the example in my last message illustrating the HELO local domain spoofing.
Same with the Return Path. This is required to be valid by RFC x821
standards.
Also, what about DATA blocks with no headers in it? Many servers accept
this and will use the envelope to fill in From:/To:.
Microsoft's SenderID/PRA will enforce 2822. At HOTMAIL.COM, if it can't
extract the PRA from the 2822 header, then the message is no good according
to the specs. At hotmail.com, the message is accepted and goes into la-la
land. No bounce, no other indication.
The PRA is:
Resent-Sender
Resent-From:
Sender:
From:
In that order, but the PRA also has logic for the group positions of the
headers, including Return-Path. I still don't see the reasoning behind it.
Microsoft calls it a "Complex" PRA lookup logic, so complex, its patented!
The problem, the first three are not required, and the From: can be assigned
the Mail From: if the data block is message.
So in short, SenderID/PRA ignores the Mail From: when in fact, a good bit
of the time, over 80% based on my logs:
2822.PRA = 2821.MAIL FROM
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com