Re: We need an IETF BCP for GREY LISTING

John C Klensin wrote:
> --On Sunday, October 16, 2011 22:57 -0700 "Murray S. Kucherawy"
> <msk(_at_)cloudmark(_dot_)com> wrote:
>
> > > Maybe a shorter way to put that last paragraph is that if we
> > > agree that reasonably timely delivery of mail is a Good
> > > Thing, then I think we have many other problems to tackle
> > > before we turn our attention to greylisting.
> > Agree here too.
> +1
>
> And even more strongly agree if "delivery of all legitimate mail
> without forcing senders to use a small number of senders with
> bilateral arrangements" is added to the list.
Hello John,

I hope we are not losing focus here.

No one is talking (at least I wasn't) about the unrealistic 
expectation that any receiver/server should adhere to the demands of 
the "anonymous" clients to accept mail immediately.  We never worked 
that way, nor can one expect it and SMTP has enough robustness to 
allow delivery within a certain period.
But in my view, the retry concept was meant for operational issues for 
which GL has  leverage successfully.  However, with greater adoption 
over the years, I believe it has changed now to one where its is an 
automatic expectation where GL frontends are par for the course.
That in itself is not too bad, it actually works and the growth of it 
is the proof of how it helps to filter legacy "single shot" spamers.
But when it becomes where its used inconsistently among good systems 
and the retry attempts go beyond the first time and now the RFC5321 
recommendations for an initial short delay with a back off pattern 
begin to become less effective, then in my engineering opinion, this 
begins to add design pressure to consider new queuing strategies.
As we discussed offlist, when you also have a growing amount of 
Anti-Spam service bureaus hosting for many different email domains, a 
Queue-By-Email-Domain is less adequate when a centralized host is 
greylisting many different domains.
So its not about any client expecting that an email should be 
immediately accepted in short time, its more about controlling the 
unreasonable delays when its not necessary.  If a GL system goal is to 
test that you are a not a "Single Shot" random abuser, then rejecting 
multiple times after the client has agreed to delay it for X minutes 
is not reasonable.
If a receiver is doing this because it its a heavy loaded system and 
clients are unfortunately hitting it during high loads, then we should 
be able to add some client/server negotiated smarts to reduce all the 
increasing overhead for a client and also the network.
That said,  I don't think its a good idea, and I hope I am mis-reading 
this, that we begin to alter the mindset of industry that TIMELY 
DELIVERY is not to be expected.
--
HLS