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