[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 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