[Mimedefang] X-Auto-Response-Suppress header

[kd6lvw at yahoo.com]

--- On Wed, 5/16/12, George Roberts <groberts at purity.net> wrote:
> If one looks carefully, RFC 5321 3.7.2 states:
> 
> "As another consequence  of trace header fields arising
> in non-SMTP environments, receiving  systems MUST NOT
> reject mail based on the format of a trace header field and
> SHOULD be extremely robust in the light of unexpected
> information or formats in those header fields."
> 
> I'm not going to quote the whole RFC to you, but from what
> I've read it's pretty clear that the Received: line is for
> debugging purposes ("...  the most important use of
> Received: lines is for debugging mail faults ...", Section
> 3.7.2). I'm hard-pressed to find any justification for
> blocking of mail generated or handled by Exchange. In fact,
> I think it's pretty clear the RFC states you MUST NOT block
> them.

It also states that the "Received:" header syntax is required (a MUST use) for SMTP.  The note about not rejecting is with regard to NON-SMTP transports and does not apply to SMTP transmissions.  How does one tell for message hops other than the current one?  Simple:  If the received header claims "with [[:alnum:]]*SMTP[[:alnum:]]*" (as a regex), then it was transported via SMTP and syntax checking is not only permitted but required since malformed messages are not acceptable under RFC 5321.  If there's no "with .*SMTP.*" clause, then the looser syntax in RFC 5322 applies -- which requires only the semicolon and date stamp and applies to ALL messages, even those originally transported via non-SMTP methods.

Considering that the large majority of malformed lines accompany spam, give me a good reason why I should not assume that EVERY malformed message is spam.  What RFC 5321 section 3.7.2 is telling us is not to assume that a SMTP-formatted "Received:" header is the only valid syntax.


Note also:
- "With" requires an IANA-registered atom element.  If what follows "with" is not on the list, the message is malformed.  I do recognize the following exceptions by regex:  "(HT|NN)TPS?A?" to permit messages via webmail or Usenet gateways.  Yahoo's "NNFMP" transport is not accepted especially since Yahoo's helpdesk in 2009 informed me that any message using that transport is a forgery when I queried them about it.  [The answer was subsequently posted to Usenet.]

- When "with *SMTP*" is present, the "from" and "by" clauses are also required.  Google's Gmail fails this part of the standard by omitting the "from" clause (which is supposed to be followed by the HELO hostname parameter).


In enforcing this, the first thing I check is the "with" clause.  If it declares a flavor of SMTP, only then do I check for the other elements ("from", "by", and the optional "via", "id", and "for", all which must occur in that order).  The "with" clause may be absent, in which case, I check only the datestamp.  If present, I check the list of alternative protocols and the datestamp, but nothing else.

The authority to reject bad-datestamped "Received:" headers is in RFC 5322, not 5321.