Ned Freed writes:
> The main issue with using Auto-submitted: is that it would block all
> cases of notifications sent in response to other notifications.
Not necessarily.
The rule could be phrased so that a simple implementation does just
that, but a more complex one can use persistent storage to allow
one-interation "loops" and remain safe and compliant.
I don't see how this can work. The problem with notification loops is that in
general each notification in turn may have _nothing_ in common with any
previous message, not even the address of the sender or recipient. So your
persistant storage lets you catch the loop... how exactly? When the messages
have nothing in common, there's nothing in common to put in your persistent
storage for comparison purposes.
And even if you assume that, say, the sender address is going to be the same
each time around (all it takes is the presence of something like per-message
subaddressing or SRS for this not to be true) so there's something to store,
the heuristic has to include some sort of rate measuring since the indicators
are not unique to any particular message. The resulting heuristics are going to
be far more brittle than Received: line counting: With Received: line counting
a limit that's set too high simply allows the loop to go on a little bit longer
than it should, but with a rate-based scheme setting the limit too high breaks
loop detection completely.
I _might_ decide to implement a rule like "don't notify if incoming
message is auto-submitted and the notification would go to an address
I've recently notifified while processing this sieve script". (Sharing
code with "don't notify if I've recently sent umpteen notifications to
the same address while running this sieve script".)
This assumes that the recipient address of the notification is the same every
time. It may not be - people like to do stuff like embed current time
information in a subaddress. Indeed, the need to do these types of operations
is one of the primary motivators for having the currentdate test as part of
Sieve - right now people who want to do this sort of thing are forced to use
some other mechanism like procmail.
I'm also quite uncomfortable with the storeage requirements this sort of thing
imposes on notification implementations. One of the characteristics I've
observed with notifications is that when they are used at all the usage is much
heavier than otherother mechanisms with storage requirements like vacation.
Ned