[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-17 09:53:15

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.


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.