--On Tuesday, November 01, 2011 12:47 +0000 Tony Finch
I was thinking higher but not much higher, e.g. have a
starting interval of several minutes and increase it by a
small percentage each time. If a site is deliberately
deferring mail then prompt delivery is clearly less important
to them than some other consideration, so it doesn't make much
sense to bust a gut to deliver their mail asap.
The "retry strategy" text in RFC 5321 was written more on the
assumption that most cases would be connection failures, rather
than 4yz-induced retries. It does not differentiate between the
two because, when 4yz really meant "system down or going down"
or "no service right now" on a global, rather than
sender-selective basis, it was reasonable to assume that a retry
within a short period of time would get a connection failure.
Combined with Tony's observation, this suggests two things to me:
(1) The difference between "not able to accept any mail right
now" and "trying to manage traffic" (or greylist, or...) really
may justify a different reply code set.
(2) Maybe the 4yz- (or new code)-induced retries aren't as
different from the traditional case as we have been assuming.
What 5321 recommends is, essentially, "wait 30 minutes or so,
try a couple of times at that interval, then back off retry
times significantly because something more serious (or of
lasting duration) is probably going on". What Tony is
suggesting is much like that, only with a much shorter initial
retry time and a slower backoff rate. That feels like "just
about the same model, different parameters" rather than "new