Re: A little sieve help

[Ned Freed <[e-mail]>]

> Is there some other way I should be trying to use sieve to prevent a
> possible mail loop?

First of all, sieve implementations are required to check for redirect loops
and break them if necessary. This means that accidental redirection loops
should be a nonissue - if they are an issue something is broken in your Sieve
implementation.

This leaves two other cases: intentional loops, such as when want both A and B
to get a copy of every message no matter where it was originally sent, and
bounce loops.

Adding headers and checking for them later does break loops in this case, but
unless you're able to add the header on both A and B it won't break the loop
until one duplicate is received. You're much better off finding a header or
some other telltake that's added naturally by either side and checking for it
in the other side. Received: fields are often a useful place to look for such
telltales.

Bounce loops are a nastier bit of business. A true bounce loop should not be
able to form because of the requirement on redirect that it not change
empty envelope from addresses. But this means that a bounce will be redirected
and then dropped by the other end, which breaks the loop but adds overhead
you'd probably like to avoid.

The other problem with bounce loops is that not all MTAs or filtering
mechanisms are standards compliant, and you may find cases where envelope from
addresses get filled in by forwarders (bad) or bounces are sent to header From:
fields (also bad). Again, if your Sieve implementation does any of these
things, it's broken.

Probably the most effective way to deal with them is to simply not forward
messages with an empty envelope address, e.g.

    if not envelope :is "from" "" { redirect "a@b"; }

But that will prevent forwarding of all bounces, which may not be what you
want. If that's unworkable, you're back to looking for telltales the other
system inserts into the DSNs it generates. Find one of those, test for it,
and if it is present don't redirect the message.

				Ned