On Tue, 22 May 2012 17:41:05 -0700 (PDT) [email protected] 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 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. > 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?) Regards, David. _______________________________________________ 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
