[Top] [All Lists]

Re: We need an IETF BCP for GREY LISTING

2011-10-16 12:57:14

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.