SMTP server pools at odds with the RFC?
I was just thinking surely resending from a different IP breaks the RFC for SMTP? Then I did some googling, and found this. http://bsdly.blogspot.com.au/2008/10/ietf-failed-to-account-for-greylisting.html Thanks, Peter. So now it is 4 years later, has anything happened?
Re: SMTP server pools at odds with the RFC?
On 2012-06-04, David Diggles da...@elven.com.au wrote: I was just thinking surely resending from a different IP breaks the RFC for SMTP? Then I did some googling, and found this. http://bsdly.blogspot.com.au/2008/10/ietf-failed-to-account-for-greylisting.html Thanks, Peter. So now it is 4 years later, has anything happened? No. It is perfectly valid, and even somewhat normal, to resend from different addresses. Whether this is by pools of senders with shared queues, or whether it's by pools of internal MXes behind NAT boxes, it definitely happens. The majority of such senders try and keep within the same /24. The greylisting.org/puremagic.com whitelist was specifically only for senders which did not follow this (they refused to add sender pools to the list if they stuck within /24). Though that's largely irrelevant as their list hasn't been updated in 6 years..
Re: SMTP server pools at odds with the RFC?
On Mon, Jun 04, 2012 at 12:34:04PM +, Stuart Henderson wrote: On 2012-06-04, David Diggles da...@elven.com.au wrote: I was just thinking surely resending from a different IP breaks the RFC for SMTP? Then I did some googling, and found this. http://bsdly.blogspot.com.au/2008/10/ietf-failed-to-account-for-greylisting.html Thanks, Peter. So now it is 4 years later, has anything happened? No. It is perfectly valid, and even somewhat normal, to resend from different addresses. Whether this is by pools of senders with shared queues, or whether it's by pools of internal MXes behind NAT boxes, it definitely happens. The majority of such senders try and keep within the same /24. The greylisting.org/puremagic.com whitelist was specifically only for senders which did not follow this (they refused to add sender pools to the list if they stuck within /24). Though that's largely irrelevant as their list hasn't been updated in 6 years.. So I guess this Wikipedia entry is incorrect, Re: breaks SMTP protocol rules? http://en.wikipedia.org/wiki/Greylisting Greylisting will cause longer delivery delays if the sender has a large infrastructure and is sending from a different IP when it retries. However this technically breaks SMTP protocol rules, since delivery is the responsibility of the sending server and its associated IP address, and tossing it back into a pool for retry by a different server in the group breaks this continuity, and will quite correctly and legitimately restart the greylisting process over again, since delivery is being retried from a different server. A past battle lost by greylisters, and the world has since moved on, or something?
Re: SMTP server pools at odds with the RFC?
On Mon, 4 Jun 2012 22:53:54 +1000 David Diggles wrote: Greylisting will cause longer delivery delays if the sender has a large infrastructure and is sending from a different IP when it retries. Most pooling Services like Yahoo and Google seem to get through eventually these days without whitelisting. I haven't found the time and analysed why (retry from same IP after three attempts or something? etc..)
Re: SMTP server pools at odds with the RFC?
On 2012-06-04 06:06, David Diggles wrote: I was just thinking surely resending from a different IP breaks the RFC for SMTP? Then I did some googling, and found this. http://bsdly.blogspot.com.au/2008/10/ietf-failed-to-account-for-greylisting.html Not only is greylisting fine from a protocol point of view (as others have pointed out), the IETF is also well aware of it. This is about to become an RFC: http://tools.ietf.org/html/draft-ietf-appsawg-greylisting Abstract This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. Simon
Re: SMTP server pools at odds with the RFC?
Simon Perreault simon.perrea...@viagenie.ca writes: Not only is greylisting fine from a protocol point of view (as others have pointed out), the IETF is also well aware of it. This is about to become an RFC: http://tools.ietf.org/html/draft-ietf-appsawg-greylisting That's a marked improvement over what appeared to be the status only a few years back. I still don't quite see why they left the crucial parts of RFC5321 as ambigous as they had been in the predecessor, but a greylisting RFC on the standards track is a very welcome development. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SMTP server pools at odds with the RFC?
Not only is greylisting fine from a protocol point of view (as others have pointed out), the IETF is also well aware of it. This is about to become an RFC: http://tools.ietf.org/html/draft-ietf-appsawg-greylisting That's a marked improvement over what appeared to be the status only a few years back. I still don't quite see why they left the crucial parts of RFC5321 as ambigous as they had been in the predecessor, but a greylisting RFC on the standards track is a very welcome development. whatever. it is still false to say that greylisting wasn't permitted by the original RFC's. it was, and it is.
Re: SMTP server pools at odds with the RFC?
Theo de Raadt dera...@cvs.openbsd.org writes: it is still false to say that greylisting wasn't permitted by the original RFC's. it was, and it is. Any reasonable interpretation (IMO) of the relevant parts of RFC5321 and RFC2821 means that greylisting is well within the protocol specs. That did however not stop people from claiming otherwise, and it was a bit disappointing back in 2008 to find that the update did not provide even clearer language. All water under the bridge soonish now, it seems. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SMTP server pools at odds with the RFC?
Theo de Raadt dera...@cvs.openbsd.org writes: it is still false to say that greylisting wasn't permitted by the original RFC's. it was, and it is. Any reasonable interpretation (IMO) of the relevant parts of RFC5321 and RFC2821 means that greylisting is well within the protocol specs. That did however not stop people from claiming otherwise, and it was a bit disappointing back in 2008 to find that the update did not provide even clearer language. I do not agree with your assessment. All water under the bridge soonish now, it seems. Yeah, it is all water under the bridge until, at the last moment, IETF allows someone to add an IPR statement to the end of this new RFC. It is very naive of you of you to think that new document is coming for free. Companies are paying for this to be clarified, and they will want to build a path so that their silver comes to them.
