Re: We need an IETF BCP for GREY LISTING

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.