Sieve forwarding loop destroys e-mail

[Joseph Brennan]

> I'm all for trying fix this if someone can come up with some logic to do
> so.  IMO, the code is correctly processing the script as written.  Here
> is the current code logic:
>
> - original message is sent to lmtpd
> - message is forwarded and a record is put in deliver.db stating as much
> - forwarded message comes back to lmtpd
> - lmtpd executes the script which tells it to forward to another address
> - lmtpd sees that it has already forwarded the message, so doesn't
> forward it again
>
> At what point should we decide to deliver the message?  The user hasn't
> asked us to do that, even though they think that they have.  How can
> lmtpd be intelligent enough to know that the forwarded address will
> cause the message to come back?


In case [1], user X forwards to an external address which forwards back
to user X.  This could be solved by not suppressing duplicates when
forwarding to external addresses.  Instead the loop would be stopped
by exceeding the hop count in the MTA, and the MTA would bounce.  This
emulates what happens with .forward or .procmailrc loops.

In case [2], user X forwards to user X.  If lmtpd hands this to the
MTA, it's like case [1].  Or does lmtpd handle this by itself?  In
that case the loop should be detectable, I imagine.

I'm probably missing something.

We might be smarter with case [1] if lmtpd inserted a "X-Been-Here"
type header as it hands off to the MTA, so that it could detect a
loop the first time the message comes back.


Joseph Brennan
Lead Email Systems Engineer
Columbia University Information Technology