[Mimedefang] Received headers in general
David F. Skoll
dfs at roaringpenguin.com
Tue May 22 21:30:03 EDT 2012
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.
> 4.4. Trace Information
Yes, I know what a sender MUST do. You are ignoring what a receiver
MUST NOT do.
> 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
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
> Where "MUST" is given, such means that there is something to
> enforce. I enforce it and get much less spam as a result. You don't
> and you get spammed. That's your problem.
But I don't get spammed, so it's not my problem. I use actual working
anti-spam techniques to combat spam rather than fascist RFC
interpretations that might let me giggle with glee over the ignorance
of Microsoft but actually stop hardly any spam.
I also happen to receive lots of legitimate mail that makes my company
quite a bit of money that would be lost were I to be as pedantic as
you, so... who has the problem, again?
(As per another poster's request for disclosure: I run servers that
process about 600K messages/day. Across our entire customer base, our
software processes probably 60M messages/day. How many messages/day
do you place at risk with your policies?)
More information about the MIMEDefang