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