[Mimedefang] Received headers in general

[Kevin A. McGrail]

On 5/23/2012 3:06 PM, David F. Skoll wrote:
> Yes, I see your comment, but you dismissed
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6781#c9  with
> a rather ingeneous redefinition of spam ("If it violates the RFC, it's
> not a valid message.")
Since we have stepped into SA territory, I should probably weigh in that 
I am not really sure I like this new definition.  But I think you are 
referring more to Comment 10.

The way I view it, if we equate this to snail mail, if my young nephew 
writes me a letter and messes up how to write the address on the 
envelope but the postal carrier delivers it, is it illegitimate or is it 
an efficient system doing it's best to deliver everything even those 
that don't quite follow things to the letter (pun intended)?

Taking this further, if my envelope is ripped up during transit, should 
it be thrown out as illegitimate?

The concept that an email could be damaged during transit isn't too 
extreme and I think the RFC is written in the light of promoting 
interoperability not the ability to refuse emails.  IMO, minor problems 
should not be used to reject emails.  However, if it's a sign of 
Ratware, etc., I'll use it to tag it as Spam.

I'll think more on this but I don't want the definition of spam from 
SA's perspective broaden to include RFC ignorance.  I feel that RFCs 
need to followed with flexibility given to maximize delivery of 
legitimate emails.

Of course, other people are entitle to run their systems how they please 
but it's a reason I work with a lot of business customers who get 
annoyed at anti-spam systems blocking more than they should.

In the end, Email is an ecosystem and assisting people in properly 
administering their servers and promoting the flow of email is best.

To horribly quote Dune, the email must flow.

regards,
KAM