[Top] [All Lists]

Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt

2008-07-22 05:15:12

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

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.

Kjetil T.