Re: We need an IETF BCP for GREY LISTING

Richard Kulawiec wrote:
> On Thu, Oct 13, 2011 at 10:25:35PM +0100, Paul Smith wrote:
> > 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!
> Many MTAs are (apparently) using a different retry schedule, and that's a
> good thing.  (Well...provided those retry schedules are reasonably sane,
> that is, not way too fast.)  I say that it's good because it helps scatter
> retries rather than concentrating them.
>
> (Consider, as a counter-example, if there were a way to communicate retry
> availability back to client MTAs.  Suppose an MX says "Please try again
> at 10 AM".  Suppose that client MTAs pay attention to this.  ALL of them.
> Then at 10:00:01 AM we might expect that the MX might find itself on
> the receiving end of quite a few connection attempts.  This may turn out
> to be much worse for all concerned than just letting client MTAs retry
> on their own varied schedules.)
Good point Richard, however, speaking for our MTA, we already deal 
with such similar resultant grouping issues when the MTA implements a 
retry granularity (i.e. reschedule by the min or hour) factor. 
Coupled with a Queue-By-Domain strategy, it help gathers future 
attempts as multi-transaction sessions when rejected attempts come in 
at spread out times.  The problem I have observed here is when many 
different domains all post to the same MX/IP host.  Not having a 
granularity can reduce this issue.
Nonetheless, I support a proposed concept for a 4yz retry=hint because 
a supportive client will most likely factor all this as part of its 
overall rescheduling/queuing algorithm, along with other possible 
factors it may already consider.  I do think, there is a different 
between 421 and 450 and maybe a BCP can help here.
Here is the thing, IMO, the prize at the end of the day is:

      Fastest, less waste in Delivery and High Throughput

For many, an email today has "No Value" tomorrow, especially in the 
business world.  I'm sure that is the normal expectation for most 
systems and people expecting timely emails.
While we can't do anything about legacy software, I think active SMTP 
systems and the network can benefit greatly with a sound BCP to better 
coordinate SMTP client/server traffic and to help alleviate the 
increasing delays, wasted retries, DNS overheads and IMO, new, complex 
queuing strategy considerations to address the issues.
--
HLS