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 
retries.
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" 
retry
      that is a compromise in lowering attempts and timely delivery,

   2) For a new intelligent GL MTA/MDA supporting retry=hints, it 
CAN|SHOULD
      benefit the client, server and the network with reduced 
overhead and
      transfer.

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 
concern.
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.

--
HLS