--- On Wed, 5/16/12, George Roberts <[email protected]> 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.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
