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.
+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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: We need an IETF BCP for GREY LISTING, (continued)
- RE: We need an IETF BCP for GREY LISTING, Murray S. Kucherawy
- RE: We need an IETF BCP for GREY LISTING, Murray S. Kucherawy
- Re: We need an IETF BCP for GREY LISTING, Hector
- RE: We need an IETF BCP for GREY LISTING, John C Klensin
- Re: We need an IETF BCP for GREY LISTING,
Hector <=
- Re: We need an IETF BCP for GREY LISTING, Douglas Otis
- Trusted agency (was: We need an IETF BCP for GREY LISTING), SM
- Re: Trusted agency (was: We need an IETF BCP for GREY LISTING), John Leslie
- Re: Trusted agency, Douglas Otis
- Re: Trusted agency, SM
- Re: Trusted agency, Douglas Otis
- Re: Trusted agency, SM
- Re: Trusted agency, Russ Allbery
- Re: Trusted agency (was: We need an IETF BCP for GREY LISTING), Richard Kulawiec
- Re: We need an IETF BCP for GREY LISTING, Richard Kulawiec
|
|
|