--- On Tue, 5/22/12, David F. Skoll <d...@roaringpenguin.com> wrote:
> On Tue, 22 May 2012 17:41:05 -0700 (PDT) kd6...@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.
_______________________________________________
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 MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Reply via email to