[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an IETF BCP for GREY LISTING
John C Klensin wrote:
--On Sunday, October 16, 2011 22:57 -0700 "Murray S. Kucherawy"
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.
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.