[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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.