Re: We need an IETF BCP for GREY LISTING

On 10/18/11 11:12 AM, Tim Kehres wrote:
> > > Keith Moore wrote:
> > > > On Oct 17, 2011, at 12:25 PM, Hector wrote:
> > > > > It seems there is a majority consensus that a IETF document for 
> > > > > Greylisting would be a worthy effort.
> > > > I'm still unconvinced.  I haven't seen any evidence to support this 
> > > > at all.
> > > hmmm,  unless I mis-read people's input, many people contributing to 
> > > the thread recognized there are issues and most have indicated a 
> > > note that a IETF document for greylisting would be a good thing.
> > > I believe you cited an interest in an SMTP extension for a retry hint.
> > I mentioned how it could be done, but also expressed concern that it 
> > might not be worth the trouble... also I said that greylisting wasn't 
> > the reason for such an extension.
> I am in complete agreement with Keith's observations.   To further 
> elaborate the issue of formalizing 4xx return codes is NOT an issue 
> with Greylisting, and this is not the context to address such 
> extensions.   If SMTP were to include such extensions, it should be a 
> general feature, and not something perceived to be tied with GL.
> Now, with respect to Greylisting - precisely what existing problem are 
> we trying to solve?  4xx return codes are not a greylisting issue.  
> The few problems that were mentioned to me seem to be configuration 
> related, and really not subject to an RFC.  Sites that either run too 
> short MTA retry times (30 seconds for a retry for example) will always 
> run into problems, regardless if they are trying to connect to a 
> remote server that has them on a temporary greylist, or any other site 
> that is inaccessible for some period of time.  Progressive backoff 
> strategies were put in place precisely for this reason - but some care 
> needs to be taken to choose reasonable timing values.
> Greylisting sites that configure timeout windows that greatly exceed 
> the norm for remote MTA retry times (hours or more for instance) are 
> also improperly configured and will not play well with MTA's with 
> reasonable backoff times.
> A BCP that describes various queuing strategies in terms of retry 
> times, and the relationship between MTA timing and Greylist delay 
> windows might be a good thing for a BCP.   It's really not all that 
> difficult, however sometimes putting these things into writing can 
> help new administrators. The BCP can then formalize what the community 
> considers "reasonable" values for MTA's and GL running servers.
> Anything else I'm really at a loss to understand what we are trying to 
> fix. Greylisting for the most part works and other than the queue 
> timing issues above seems largely to be a non-issue.
and let's now move the BCP part of this discussion to another venue, 
like ASRG. GL just uses ordinary SMTP technology and with respect to GL 
there's nothing to be fixed in SMTP, so I fail to see why this BCP work 
has to be discussed on ietf-smtp.
/rolf