[Mimedefang] Received headers in general

[kd6lvw at yahoo.com]

--- On Tue, 5/22/12, David F. Skoll <dfs at roaringpenguin.com> wrote:
> On Tue, 22 May 2012 17:41:05 -0700 (PDT) kd6lvw at yahoo.com wrote:
> > You completely missed what I said earlier.  That part applies to
> > NON-SMTP headers and says that we cannot and must not reject headers
> > from other transports on the grounds that they don't meet SMTP's
> > syntax. It doesn't apply to headers which fall under SMTP
> > environment or generation, nor do I enforce SMTP syntax compliance on
> > non-SMTP generated headers.
> 
> That's not how I read the RFC.
> 
> It says as one consequence of non-SMTP environments, there may be
> noncompliant Received: headers.  It says a receiver MUST NOT reject
> mail because of noncompliant trace headers.  It doesn't say you CAN
> reject noncompliant trace headers if you (somehow?) know they were
> inserted under SMTP.

Right, and if the message claims it came from a different (i.e. non-SMTP) environment, it is NOT rejected (nor tested further).  What it says is that we cannot reject messages by assuming that they must meet SMTP syntax because they could have come to us some other way.

> > 4.4.  Trace Information
> 
> Yes, I know what a sender MUST do.  You are ignoring what a receiver
> MUST NOT do.
 
Not at all.  Malformed messages may always be rejected.

> > Exchange and gmail claim SMTP transport but fail to follow the
> > required syntax.  RFC 5321 does not ban rejecting on that basis.
> 
> What part of:
> 
> "receiving systems MUST NOT reject mail based on the format of a trace
> header field" is unclear?  It doesn't say MUST NOT reject mail based
> on the format of a trace header field inserted by a non-SMTP
> protocol.  It says MUST NOT, period.

You're not understanding the premise of that paragraph of the RFC.  It says that because there may be messages which are transported in other ways and therefore may have different information recorded, one cannot expect for those to match the SMTP syntax for the header and therefore, they must not be rejected for failing to match that syntax.  This says nothing which forbids rejecting messages for failing to meet SMTP syntax when transported via SMTP (or when they claim such by stating "with SMTP" in the header data).

What it means is that when it says something other than "with SMTP", there is NO EXPECTATION that there will be "from", "by", "via", "id" or "for" clauses, or any future additional SMTP clause added by a later RFC, and rejection of the message for not having those when required is forbidden because the message isn't SMTP formatted.  It also means that when a "Received:" header does claim "with SMTP", the paragraph does not apply.  Checking a message for trace header syntax is actually required when the sender MUST generate the required syntax.

If you're saying that we can't check a required syntax when it MUST be generated, that denegrates the "MUST" to a "SHOULD" which contradicts the RFC's requirements, and is therefore nonsense.  When discretion is eliminated, it is eliminated on BOTH sides, sending and receiving, even when a document only explicitly states one side.