On Sep 29, 2010, at 3:31 AM, Hector Santos wrote:
SM wrote:
Hi Murray,
At 15:48 28-09-10, Murray S. Kucherawy wrote:
In some R&D I'm doing I'm comparing numerous MTAs about how they handle
things like a non-header line before CRLF between the header and body. I'm
trying to figure out if there's a rough consensus among them about how to
handle such exceptions.
Documenting the exception handling is useful.
Would a compilation of the results of that investigation be a useful
candidate for publication as a BCP or Informational?
I suggest Informational. If you are aiming for consensus on how to handle
the exceptions, it can end up being more work that it is worth.
+1.
There are all kinds of issues here that I don't think a tabulation of MTAs
will correctly represent.
It could be a matter of a "Switch" for strict vs Relax 822/2822/5322
compliance. A few years back in this group we had a long discussion about
the level of 822 vs 2822 compliance and how some MTA will have their own
"extended" rules for what is considered "valid headers." Many just look for
the basic requirements - a combo of To/CC, From and/or Date and then for the
double <crlf><crlf> to point to the body. So if there any junk in the
headers, it can be passed thru. We have four operational options here:
Strict 822 From, Date and to/cc
Strict 2822 From, Date
Strict {OurBrand} with header syntax checking
Relaxed {OurBrand} which includes a "Received" line (DEFAULT)
There are 20+ years in the making and years past attempts to go strict
(enforce by default) failed miserably in the support area. Regardless if it
was just a few people, it created a 'surprise' and support cost.
Recently I created a DATA filter script to check for multiple From: headers.
The script will immediately reject it if more than one From: is found. I
just added the logic to check for the last header line to see if its
complaint. No reject though, just logging to check numbers if any.
What will be useful is to also test the numerous MUAs. I know OE and
Thunderbird will hide, ignore, skip and not show the errant header lines.
IMO, With a few notable exceptions (e.g. submission servers, spam filters,
gateways to foreign systems), MTAs shouldn't be checking message headers at
all. The problem is that a message typically has to pass through several MTAs.
Every one of those MTAs is an opportunity for rejection of a valid message -
should that MTA's code either be buggy or deliberately reject something that
happens to be reasonable. Even if a message is malformed in some way
according to 822, 2822, and/or 5322, that does not mean it's not valuable to
the recipient. When MTAs check message headers, that's a layering violation.
Keith