[Top] [All Lists]

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

2008-07-22 04:07:32

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.