On Oct 11, 2011, at 11:16 AM, Murray S. Kucherawy wrote:
RFC3339 instead of ISO8601, perhaps?
Of course, abusers will only pay attention to this if it benefits them and
it’s cheap to do so.
Yup. But it's not the abusers that really matter here, it's the good actors who
are happy to play nice with the receivers, but don't have the information to do
so.
But they won’t be distinguishable from legitimate clients that just don’t
know about this extension and retry by their own schedules, so one can’t
penalize such clients for not respecting the request.
You can reward senders who do respect the request
If I don't want any more connections from a particular sender for the next five
minutes, I'll 4xx any connections from them for that period, then start letting
mail through. A sender that pays attention to my "… in five minutes" message to
them will simply go away, then come back in five minutes and be accepted.
A sender that didn't pay attention might retry after 15 minutes and get
delivered, or they might retry after one minute (and get deferred), after two
minutes (and get deferred), then four minutes (and get deferred), then eight
minutes and be delivered. They'll get worse latency than the cooperative
sender, even if the receiver pays no particular attention to their behaviour
(and if I were an ISP I'd probably reward those senders by giving them priority
over random bad senders when resources are constrained).
On the other hand, you might be able to identify “good” clients (for some
value thereof) by observing which ones do respect the request.
A lot of legitimate email is sent by legitimate bulk emailers. Mostly ESPs, but
also a lot of corporations sending mail to their customers. They expend quite a
lot of effort in traffic management already, so as to get their mail delivered
in a timely fashion while not getting throttled by the recipient ISP. If they
could check a box in their smarthost configuration that says "Do what the ISP
asks", they'd do it - as it would reduce their overheads considerably, and
likely lead to their email being delivered faster or within more predictable
bounds.
I think that the issue of real-time traffic control feedback from server to
client might be a bit broader than just this one example, but it's a simple
enough case to start thinking about.
Cheers,
Steve