[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: We need an IETF BCP for GREY LISTING
Murray S. Kucherawy wrote:
In light of this thread, I polled several large mailbox providers. None of them say
they do greylisting. One of them (Hotmail) replied that they don't do greylisting
because they just don't see enough benefit from it. None of our large customers do it either.
Murray, I'm sure you are aware, this doesn't mean that a) it isn't so,
and b) they are not "feeling" the Greylisting in their outbound mail
for which more than likely, its a pure guessing game for them on the
As I stated before, even if a system hasn't implemented it yet, GL is
widely supported and they are feeling it in greater numbers. For
some, they haven't feel it yet. For many, they may never see an issue.
For others, like for our MTA and customers, we see a pending issue
that needs to be addressed before it gets worst. The more of an
anonymous sender (Direct Marketers, Trade Newsletters, etc) when you
may not have pre-arrangements, no whitelisting, no authentication,
etc, the greater the issue. And as I also stated, when volume to
different email domains are centralized MX hosted with a GL frontend,
the delays are applies as a whole to all the different email domains.
So a MTA Queue-By-Email-Domain strategy is now more complicated.
Its good to get feed back from your peers if you don't have the direct
experiences yourself in the actual product coding, field testing, fine
tunning and seeing how it has evolved over the last 8 years, but at
some point you are going to have some to accept there are issues being
felt and pending issues that waiting to happen as GL frontends grows.
It may all comes down to two things:
1) For the non-intelligent GL MTA, it needs to use a "Best Guess"
that is a compromise in lowering attempts and timely delivery,
2) For a new intelligent GL MTA/MDA supporting retry=hints, it
benefit the client, server and the network with reduced
You need to understand that initial delays by an MTA such as 1 minute
is done for a reason - they can't afford the negative business
operation with untimely deliveries, especially when a customer is
trying to contact you. This is a REAL issue.
Yet, a customer doesn't wish to get delayed in sending its own mail.
So if blocked, our GL setup has the short delay to help alleviate that
The issue is that with the GL growth over the past 8 years, they are
hitting more servers where the rejects are more common place and
delays are more wide spread and longer in blocking times.
So sure, we can come up with a BCP with a recommended delay, but what
is that? 1, 5, 10, 15, 30, 1 hour? While one can reasonable suggest
that a statistic average suggest 5 minutes is the most appropriate, I
technically believe that is not good enough for active MTAs who see
CLIENT/SERVER intelligence is possible and they don't have to wait
that long for many GL servers who issues responses like:
451 Greylisting enabled, try again in 1 minutes
451 Greylisting enabled, try again in 30 seconds
and if a response that
451 4.7.1 Greylisting in action, please come back in 00:10:00
then a possible BCP recommendation of 5 minutes retry would be a waste.