Kjetil Torgrim Homme writes:
On Tue, 2008-07-22 at 12:47 +0200, Arnt Gulbrandsen wrote:
These are two of the three (or four) options I'm aware of. The third
is to accept that mail loops happen, but make them less harmful by
slowing them down. A thousand messages per day isn't so bad, at
least not compared to 100,000.
It's also possible to combine. The document could say "If the
incoming message has an Auto-Submitted field, a return-path of <>,
or other signs that it was automatically generated, then the
outgoing notification MUST be delayed by at least two minutes",
with reference RFC 4865 informatively.
This is just too ugly. Users will be forcing implementers to add an
override for this behaviour.
Sure. I'd make the period configurable in my own code, down to 1 second.
What about it?
I'm not really in favour of such a rule. I like the simple
Auto-Submitted rule. I'm just mentioning this since it is a
possibility, since we need to find some compromise rule that
everyone can live with, and this is an area we haven't discussed.
Here's an alternative compromise: An implementation can not send a
notification in response to a message with "Auto-submitted: !no"
unless the number of Received headers in the notification messages is
higher than in the original message.
You mean by generating dummy fields?
Received: by <host> (dummy inserted by sieve); <date>
Received: by <host> (dummy inserted by sieve); <date>
Received: by <host> (dummy inserted by sieve); <date>
I'm not in favour, but I can live with that too if that's what it takes
to get WG consensus, IESG blessing and an RFC.
Arnt