Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
--- On Fri, 5/29/09, Richard Laager wrote: > On Thu, 2009-05-28 at 13:17 -0700, - wrote: > > Then again, I kill messages that have improperly formatted "Received:" > > header lines. (Those that claim "with *smtp*"(wildcarded) ... > > Would you be willing to share this code? Message sent directly since it uses M4 code (i.e. sendmail rulesets), not perl and MimeDefang. ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
On Thu, 2009-05-28 at 13:17 -0700, - wrote: > Then again, I kill messages that have improperly formatted "Received:" > header lines. (Those that claim "with *smtp*"(wildcarded) must > conform to 5321 instead of the looser syntax in 5322 and as such, they > must have "from" and "by" clauses that are domain names (or address > literals). If they don't, I reject them as malformed spam. Would you be willing to share this code? Thanks, Richard ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
--- On Thu, 5/28/09, David F. Skoll wrote: > Date: Thursday, May 28, 2009, 7:26 AM Jeff Rife wrote: > ... > > What text, exactly, leads you to that conclusion? > > [RFC 5321] Section 4.3.2: > ... > > Based on the indentation, I see the 4xx codes as acceptable only after > "data" (ie, the final dot), while 421 is an always-available escape hatch. > It's not very clear, though, and it's too bad that we on the RFC2821-bis > mailing list missed that. :-( I did not really note any change regarding this across RFCs 2821 -> 5321. > > But all of the following make sense after "DATA", even > though they aren't specifically listed: > > I agree, and an SMTP client SHOULD cope with them. What the sum-total of the RFC means (at least to me) is that the only temp-error code that should ever be generated after a "DATA" command but before headers/body are transmitted is 421. That means that a client program should have an expectation that no other code will ever be generated by a PROPERLY-BEHAVING server, but it should be prepared to handle anything. A server that does generate something else does so because: 1) It is misconfigured. 2) It does not adhere to the standard. 3) It is malware (includes spamware). Regardless of the reason, detection of a different code (in my opinion) is cause to upgrade the error to fatal and generate an NDR for noncompliance (perhaps DSN 5.5.5 = "Wrong protocol version"). The NDR is proper in that, as the message passed any/all spam/forgery checks of the host that holds the message, it's not going to be (or should not be) backscatter. If a future RFC/standard were to dictate another possibility to 421, then the version of the protocol has in fact changed and thus the 5.5.5 DSN would be accurate. I think that only the extremely paranoid would care. Then again, I kill messages that have improperly formatted "Received:" header lines. (Those that claim "with *smtp*"(wildcarded) must conform to 5321 instead of the looser syntax in 5322 and as such, they must have "from" and "by" clauses that are domain names (or address literals). If they don't, I reject them as malformed spam. The only "false" positive (I don't really consider it false as it is noncompliant) is from some versions of Micro$oft Exchange which likes to say: 'from mail pickup service' or 'with microsoft smtpsvc'. Within the permitted syntax, 'from "mail pickup service"' (note the double quotes) is the correct ABNF statement. As much virusware tends to inhabit Micro$oft OS-based systems, I don't consider that a significant loss. No reason not to punish those who can't follow the standards since many are spammers anyway. ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
Jeff Rife wrote: Based on the full text of the RFCs and not just the examples, "450" seems to be a perfectly acceptable temporary failure. I read them differently. I see 450, 451 and 452 as acceptable after the final dot, but only 421 in direct response to DATA. (I'm basing my interpretation on RFC 5321.) What text, exactly, leads you to that conclusion? Section 4.3.2: DATA I: 354 -> data -> S: 250 E: 552, 554, 451, 452 E: 450, 550 (rejections for policy reasons) E: 503, 554 Based on the indentation, I see the 4xx codes as acceptable only after "data" (ie, the final dot), while 421 is an always-available escape hatch. It's not very clear, though, and it's too bad that we on the RFC2821-bis mailing list missed that. :-( But all of the following make sense after "DATA", even though they aren't specifically listed: I agree, and an SMTP client SHOULD cope with them. 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 MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
On 28 May 2009 at 9:40, David F. Skoll wrote: > Jeff Rife wrote: > > > Based on the full text of the RFCs and not just the examples, "450" > > seems to be a perfectly acceptable temporary failure. > > I read them differently. I see 450, 451 and 452 as acceptable after > the final dot, but only 421 in direct response to DATA. (I'm basing > my interpretation on RFC 5321.) What text, exactly, leads you to that conclusion? To be honest, based on the text, the only acceptable responses to "DATA" are "354", "503", or "554", since there is never an example of any temporary fail code being valid. Even the "421...may be a reply to any command if the service knows it must shut down" is only a slight "out", since you aren't really "shutting down". But all of the following make sense after "DATA", even though they aren't specifically listed: 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons) 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage All are acceptable on the premise that although the "RCPT TO:" all had acceptable values, now that we know that a real e-mail is coming through, we can't complete the action at this time. -- Jeff Rife | "I have a question that could affect our entire | relationship...did you kill Coach Mattay?" | "No!" | "But, you did dress him up like a woman...?" | "Yeah." | "Just checking." | -- Alex Lambert and Brian Hackett, "Wings" ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
Following up on myself: I read them differently. I see 450, 451 and 452 as acceptable after the final dot, but only 421 in direct response to DATA. (I'm basing my interpretation on RFC 5321.) That being said, the RFC does say: "SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only." -- 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 MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
Jeff Rife wrote: Based on the full text of the RFCs and not just the examples, "450" seems to be a perfectly acceptable temporary failure. I read them differently. I see 450, 451 and 452 as acceptable after the final dot, but only 421 in direct response to DATA. (I'm basing my interpretation on RFC 5321.) 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 MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
On 27 May 2009 at 19:01, - wrote: > Perhaps so, but in RFC 5321 (and predecessors, 2821 and 821), the > ONLY tempfail code valid at that point is 421, so if these programs > didn't plan for it, they failed to follow the historical design for > an SMTP client, and are thus completely broken. I see nothing that indicates that 421 is the only acceptable temporary fail code after "DATA". Based on the full text of the RFCs and not just the examples, "450" seems to be a perfectly acceptable temporary failure. In addition, the enhanced system status code (RFC 3463) returned should likely be "4.7.0" or "4.7.1". -- Jeff Rife | | http://www.nabs.net/Cartoons/OverTheHedge/AmericaOnline.gif ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
--- On Wed, 5/27/09, David F. Skoll wrote: > Date: Wednesday, May 27, 2009, 6:17 PM - wrote: > ... > > However, if subject were not part of your mix, then greylisting > > (with a "421" as that's really the only temp-error code that should > > occur in response to DATA) would work. > > 421 responses to DATA probably cause seldom-tested code to > execute. :-) Many SMTP implementations don't handle edge > cases in the SMTP state machine very well. Perhaps so, but in RFC 5321 (and predecessors, 2821 and 821), the ONLY tempfail code valid at that point is 421, so if these programs didn't plan for it, they failed to follow the historical design for an SMTP client, and are thus completely broken. As spamware is also broken, perhaps we should assume that such a client is hostile? ___ 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
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
- wrote: >> 1) To make greylisting work with marginal SMTP servers that don't handle >> 4xx responses to RCPT properly. > I can accept that - although I've never knowingly observed it. Old versions of Novell Groupwise failed to handle this properly (though it has been fixed for a long time.) I believe the same applies to old versions of Lotus Notes. > However, if subject were not part of your mix, then greylisting > (with a "421" as that's really the only temp-error code that should > occur in response to DATA) would work. 421 responses to DATA probably cause seldom-tested code to execute. :-) Many SMTP implementations don't handle edge cases in the SMTP state machine very well. 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 MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
--- On Wed, 5/27/09, David F. Skoll wrote: > Martin Blapp wrote: > > Ask David, AFAIK he's using such a post DATA graylisting > > implementation, but at filter_begin() instead of filter_data(). > > Yes, we filter post-DATA for two reasons: > > 1) To make greylisting work with marginal SMTP servers that don't handle > 4xx responses to RCPT properly. I can accept that - although I've never knowingly observed it. > 2) We greylist on: HASHFUNC(sender, recipient, sending_ip, subject) > because some spammers got around greylisting by sticking to the same > IP address, but mutating the subject header. Because we include the > subject line in our greylisting mix, we couldn't greylist in filter_data > even if it were available. However, if subject were not part of your mix, then greylisting (with a "421" as that's really the only temp-error code that should occur in response to DATA) would work. I was just looking for a potential use. Looks like there is one. ___ 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
[Mimedefang] Greylisting post-data (was Re: [PATCH] filter_data implementation)
Martin Blapp wrote: Ask David, AFAIK he's using such a post DATA graylisting implementation, but at filter_begin() instead of filter_data(). Yes, we filter post-DATA for two reasons: 1) To make greylisting work with marginal SMTP servers that don't handle 4xx responses to RCPT properly. 2) We greylist on: HASHFUNC(sender, recipient, sending_ip, subject) because some spammers got around greylisting by sticking to the same IP address, but mutating the subject header. Because we include the subject line in our greylisting mix, we couldn't greylist in filter_data even if it were available. Regards, David. PS: To make our greylisting tolerable, we mark a host that successfully makes it past greylisting as not-to-be-greylisted for 40 days. ___ 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
