Murray S. Kucherawy wrote:
The intended status of this document doesn't give any kind
of standard status to malformations. It recommends the safest
way of handling them if you're in an environment where you have
to do so rather than simply rejecting them. And the reality is
that we (the industry) usually have to do that, so it seems like
a good idea to share the collected wisdom about the best/safest
way to do so.
and cheapest too. As you implied, the cheapest route maybe to white
list these "good" but malformed messages.
Off the top of my head:
A missing Date:, technically a RFC5322 requirement, may arrived
missing, so many packages offer an AddDateIfMissing=YES/NO option.
Another area that has always been sensitive and evolved over time, was
detecting what was a valid message.
Some SMTP systems will allow you to enter a DATA payload without any
RFC 822/2822/5322 headers.
But for detecting it, it evolved over the years
822 - required FROM, DATE: TO/CC:
2822 - relaxed to required FROM, DATE:
5322 - same as 2822
I seem to recall an old I-D by Keith to even further relaxed From: :)
Our package added another check with a Received: line detection since
you need at least 1 to be a received message.
Anyway, a few years back a version defaulted on compliancy and also
adding the AddDateIfMissing option and almost immediately, we got some
valid mail Missing Dates complaints. Telling them to enable the
option fixed that. I don't recall many other complaints and that
reflect my theorem:
Most good systems are compliant, Most bad systems are not.
which strongly correlates to:
All good systems complain, ALL bad systems do not.
which tells me its cheapest to just deal with it manually and don't
try to automate it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com