Re: [apps-discuss] Comments on Malformed Message BCP draft

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