[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-13 16:45:47

On 13/10/2011 15:51, John Levine wrote:
So, if the server says 'retry in 1 hour', and the client retries every 5
minutes, that's no crisis, just a wasted bit of effort for the client
and the server. ....
Since the number of MTAs vastly exceeds the number of greylisters,
don't you think it would be better for greylisters to work with the
existing retry schedules that MTAs use than to try to persuade a
million MTAs to implement a new feature that is of at best marginal
use to them?
Well, it's not just greylisters, it could be a general load management hint. eg a site which normally has 3 MX servers has one down for maintenance for a couple of hours, and the other two are very busy, they could say 'try again at the time when we expect the system to be back at full strength'. This wouldn't necessarily be able to tie in to 'normal' retry schedules.

If a sender retries at 5 minutes, 30 minutes, then 2 hours, being able to say 'try again in 1 hour because I'm not going to accept new messages until then' means the message could be delivered in 60 minutes rather than in 155 minutes if the sender heeds that response. If it doesn't, then it will still be delivered in 155 minutes as it would have been without the hint.

Anyway, what are 'the existing retry schedules that MTAs use'? If they were standardised then it would be a great idea to work with them, but they're not, and every MTA could be using a different retry schedule!

I suppose I'm biased because I can see how this would help a little bit, and it would take about 10 minutes to implement the client and greylisting server parts of it in our server, so even if it only helps with 0.0001% of connections, it might be worth doing...

The only reason I can see for not specifying a mechanism to allow a retry hint it is that it won't help very much, I can't see any realistic interoperability or security risks or excess complexity.