[Top] [All Lists]

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

2008-07-22 05:14:29

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.