Ned Freed writes:
FWIW, my suggestion was to add a parameter to auto-submitted that
uniquely identifies the auto-submitter so that that can be checked
and loops detected that way. But this got shot down for some reason I
no longer recall.
If we could trust that Auto-submitted doesn't get clobbered, it would
suffice to say that a message containing an "Auto-submitted:
auto-notified" header should be silently ignored.
Unfortunately, I don't think we can trust that Auto-submitted is truly
handled as a trace header (ie. multiple instance header) in the
multitude of homegrown applications out there sending automatic
responses.
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.
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.
--
regards,
Kjetil T.