[Mimedefang] Received headers in general
Kevin A. McGrail
KMcGrail at pccc.com
Wed May 23 15:35:16 EDT 2012
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
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.
More information about the MIMEDefang