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

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.
> I also object somewhat to copying Received: fields over that in fact 
> correspond to hops that a totally different message took. The 
> relationship between the notification message and the message that 
> triggered it is just too tenuous. This is a kluge, and IMO not a 
> terribly good one.
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.
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.
Arnt