On Mon, Mar 31, 2008 at 11:52:10AM -0400, Ken Murchison wrote: > Gary Mills wrote: > >Once again, we had somebody use the sieve facility to redirect e-mail > >back to the same mailbox and then go on vacation. This sets up a > >forwarding loop which cyrus breaks by discarding the e-mail. During > >this vacation, all of the person's e-mail disappeared. > > > >Shouldn't we have a better solution to this problem? Some people > >expect that forwarding e-mail to yourself should work; nobody expects > >the messages to vanish without a trace. > > 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? Yes, it's difficult to do this correctly and still maintain a separation between the delivery process, with duplicate suppression, and the sieve facility. To begin with, the forwarding mechanism of sieve would have to mark a forwarded message in some manner so that it can be identified later. This could be something in the message header, or something associated with the message in a database. It would be a guarantee that it wasn't going to forward it again. Next, the delivery mechanism would have to bypass duplicate suppression for such a marked message. That way, it would be delivered again, and the sieve facility would be responsible for breaking the loop. It would have to do something other than forwarding at that point. `keep' is the simplest option. Perhaps there could be others. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking- ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
