Sieve forwarding loop destroys e-mail

[Ken Murchison]

Joseph Brennan wrote:
>> 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.

Just to be clear, its not duplicate suppression as is normally used that 
prevents local delivery.  The message never gets delivered locally 
because the script tells us otherwise.  The deliver.db record prevents 
us from forwarding the same message more than once.

The same processing would take place if the sieve script forwarded to an 
address that forwarded it back to us.


> 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.

lmtpd hands this off to a local MTA.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University