Re: Sieve forwarding loop destroys e-mail
Matt Garretson [EMAIL PROTECTED] wrote: Along similar lines, any well-written Procmail recipe which redirects mail typically checks for, or adds, an X-Loop header before forwarding anything. Yes, it's an old solution. The crucial difference is that if one writes a bad procmail recipe, the message loops round and round until one of the MTAs considers the hop count exceeded and bounces it to sender, but if one writes a bad sieve rule, the message _is silently lost_. That's a much harsher penalty. And we stand a chance of here of doing _better_ than procmail. If we insert a header roughly like 'X-Sieve-Seen: user hostname' when we forward, we can look for it in incoming messages and say we won't forward again. So the penalty for writing a bad sieve forward rule would be that it doesn't forward. That's better than bounce to sender, and way better than losing the message. If the editheader Sieve extension gets implemented, then a well- written sieve script should be able to do the same type of thing. To me this seems a bit more sane than expecting lmtp or sieve to accomplish it automatically. I've been called crazy before! 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
Re: Sieve forwarding loop destroys e-mail
On 02 Apr 2008, at 09:00, Joseph Brennan wrote: The crucial difference is that if one writes a bad procmail recipe, the message loops round and round until one of the MTAs considers the hop count exceeded and bounces it to sender, but if one writes a bad sieve rule, the message _is silently lost_. That's a much harsher penalty. It's not really sieve that is losing the message, it's Cyrus LMTP duplicate suppression. This is why an internal implicit solution is appealing, rather than requiring a good sieve recipe using a sieve extension which is an internet draft at the moment. :wes 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
Re: Sieve forwarding loop destroys e-mail
On Mon, Mar 31, 2008 at 5:12 AM, Gary Mills [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 02:27:29PM +0100, Alain Spineux wrote: On Mon, Mar 17, 2008 at 5:39 PM, Gary Mills [EMAIL PROTECTED] 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. If you force a keep in your sieve script, the mail will be delivered at least once in the mailbox It's perfectly valid to have nothing but a `forward' in a sieve script. People do this all the time when they don't want to keep a copy for themselves. Unfortunately, some also forward e-mail to themselves, expecting that to work. sieve script is only a language. The language nor its interpreter nor its compiler dont need to be smart, because the script writer is supposed to be smart enough. If the user in unable to write such script, it must use a sieve script manager, (application written by a smarter developer) that will help him generating well suited script. redirect is a sieve command that forward an email to another address. redirect_and_keep is not a valid sieve command, but you can write such an extension. Regards. Once the message has been `seen' and is about to be forwarded again, it would be better to deliver the message into the mailbox, rather than deleting it. Is this possible with the current design of the duplicate delivery database? How can a message be 'seen' if it is not in the mailbox, and how can the mailbox owner read this message if he is in vacation ? Or you mean 'seen', already in the delivered db ? But then this is the job of the delivered db to drop the email to avoid loop. I suppose I mean `delivered'. Yes, it will be discarded the next time it's delivered. That's the problem. There needs to be some connection between delivery and the forwarding process. Of course, it's impossible to distinguish between a forwarding loop and a real duplicate unless another `Received' header is added to the message header. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- -- Alain Spineux aspineux gmail com May the sources be with you 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
Re: Sieve forwarding loop destroys e-mail
Jo Rhett [EMAIL PROTECTED] wrote: I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. You can tell me no one has time to fix it, and in an open source project I can respect that. But it is a bug. or back to sender (grounds: not deliverable as configured). Only if you want to become a source for backscatter. Losing mail is much worse than backscatter. With bounces limited to people who get a forward loop going, bounces are not a big issue. Gary Mills [EMAIL PROTECTED] wrote: Of course, it's impossible to distinguish between a forwarding loop and a real duplicate unless another `Received' header is added to the message header. Hm. What if duplicate suppression is turned off? Infinite loop? Hop count is the classic MTA method of detection, but here the very first time around the loop will hit dup suppression. This calls for something else that lets the system know the message already passed through a local sieve script. Joseph Brennan 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
Re: Sieve forwarding loop destroys e-mail
On Mon, Mar 31, 2008 at 02:04:29PM +0200, Alain Spineux wrote: On Mon, Mar 31, 2008 at 5:12 AM, Gary Mills [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 02:27:29PM +0100, Alain Spineux wrote: On Mon, Mar 17, 2008 at 5:39 PM, Gary Mills [EMAIL PROTECTED] 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. If you force a keep in your sieve script, the mail will be delivered at least once in the mailbox It's perfectly valid to have nothing but a `forward' in a sieve script. People do this all the time when they don't want to keep a copy for themselves. Unfortunately, some also forward e-mail to themselves, expecting that to work. sieve script is only a language. The language nor its interpreter nor its compiler dont need to be smart, because the script writer is supposed to be smart enough. If the user in unable to write such script, it must use a sieve script manager, (application written by a smarter developer) that will help him generating well suited script. There's no general solution to this problem in the script language, even with a generator like we use. Again, that's because even the generator can't tell what forwarding will cause a loop. I could, for example, forward e-mail to my @fastmail.fm address, from where it would come back to me. The generator could never know about my remote forwarding. In the simplest case, writing a sieve script to forward to yourself causes the e-mail to disappear. The script writer could be considered `smart' in expecting this to work. Calling the writer `stupid' doesn't solve the problem. -- -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
Re: Sieve forwarding loop destroys e-mail
On Mon, Mar 31, 2008 at 2:40 PM, Joseph Brennan [EMAIL PROTECTED] wrote: Jo Rhett [EMAIL PROTECTED] wrote: I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. You can tell me no one has time to fix it, and in an open source project I can respect that. But it is a bug. Look at this: If my script is redirect [EMAIL PROTECTED] I expect my mailbox to stay empty, because this is what redirect is supposed to do! If I found and email in my mailbox this is a BUG, because the script I wrote should never let an email come in! What you want is a smart_redirect command ! Write a new RFC to extend SIEVE, then write a patch for cyrus. or back to sender (grounds: not deliverable as configured). Only if you want to become a source for backscatter. Losing mail is much worse than backscatter. With bounces limited to people who get a forward loop going, bounces are not a big issue. Gary Mills [EMAIL PROTECTED] wrote: Of course, it's impossible to distinguish between a forwarding loop and a real duplicate unless another `Received' header is added to the message header. Hm. What if duplicate suppression is turned off? Infinite loop? Hop count is the classic MTA method of detection, but here the very first time around the loop will hit dup suppression. This calls for something else that lets the system know the message already passed through a local sieve script. Joseph Brennan 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 -- Alain Spineux aspineux gmail com May the sources be with you 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
Re: Sieve forwarding loop destroys e-mail
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? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Re: Sieve forwarding loop destroys e-mail
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
Re: Sieve forwarding loop destroys e-mail
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 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
Re: Sieve forwarding loop destroys e-mail
On 31 Mar 2008, at 11:52, Ken Murchison wrote: How can lmtpd be intelligent enough to know that the forwarded address will cause the message to come back? There's no way to do that, but one could insert a header, e.g, X- Sieve-Redirect. Maybe the value would be a random string which was also saved in the duplicate DB. :wes 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
Re: Sieve forwarding loop destroys e-mail
On Mon, Mar 31, 2008 at 04:21:20PM +0200, Alain Spineux wrote: On Mon, Mar 31, 2008 at 2:40 PM, Joseph Brennan [EMAIL PROTECTED] wrote: Jo Rhett [EMAIL PROTECTED] wrote: I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. You can tell me no one has time to fix it, and in an open source project I can respect that. But it is a bug. Look at this: If my script is redirect [EMAIL PROTECTED] I expect my mailbox to stay empty, because this is what redirect is supposed to do! If I found and email in my mailbox this is a BUG, because the script I wrote should never let an email come in! I know, I know - pick me. How about this one? discard; It turns out that a mail delivery system that has been configured in a way that loses mail has a bug _in_the_person_who_configured_it_. Now it may be that the language makes it easy to shoot yourself in the foot, but that's different from being buggy. Bron. 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
Re: Sieve forwarding loop destroys e-mail
On Tue, 1 Apr 2008, Bron Gondwana wrote: On Mon, Mar 31, 2008 at 04:21:20PM +0200, Alain Spineux wrote: On Mon, Mar 31, 2008 at 2:40 PM, Joseph Brennan [EMAIL PROTECTED] wrote: Jo Rhett [EMAIL PROTECTED] wrote: I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. You can tell me no one has time to fix it, and in an open source project I can respect that. But it is a bug. Look at this: If my script is redirect [EMAIL PROTECTED] I expect my mailbox to stay empty, because this is what redirect is supposed to do! If I found and email in my mailbox this is a BUG, because the script I wrote should never let an email come in! I know, I know - pick me. How about this one? discard; It turns out that a mail delivery system that has been configured in a way that loses mail has a bug _in_the_person_who_configured_it_. Now it may be that the language makes it easy to shoot yourself in the foot, but that's different from being buggy. Just for reference - we provide a web interface (custom, we wrote it) that provides the features most people want to configure in their sieve rules such as email forwarding, filtering based on From/To address, vacation messages, and spam blocking. Of course, they have no idea it is actually sieve behind the scenes. They just point and click the web interface. This web interface has sanity checks to prevent people from doing silly things like forwarding mail to themselves or the other common email aliases on their accounts. We also offer direct sieveshell access for users that ask if they can do more than the web interface offers. If these smart users shoot themselves in the foot, oh well. Andy 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
Re: Sieve forwarding loop destroys e-mail
On Mon, 31 Mar 2008 15:51:17 -0700 (PDT), Andrew Morgan [EMAIL PROTECTED] said: On Tue, 1 Apr 2008, Bron Gondwana wrote: On Mon, Mar 31, 2008 at 04:21:20PM +0200, Alain Spineux wrote: On Mon, Mar 31, 2008 at 2:40 PM, Joseph Brennan [EMAIL PROTECTED] wrote: Jo Rhett [EMAIL PROTECTED] wrote: I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. You can tell me no one has time to fix it, and in an open source project I can respect that. But it is a bug. Look at this: If my script is redirect [EMAIL PROTECTED] I expect my mailbox to stay empty, because this is what redirect is supposed to do! If I found and email in my mailbox this is a BUG, because the script I wrote should never let an email come in! I know, I know - pick me. How about this one? discard; It turns out that a mail delivery system that has been configured in a way that loses mail has a bug _in_the_person_who_configured_it_. Now it may be that the language makes it easy to shoot yourself in the foot, but that's different from being buggy. Just for reference - we provide a web interface (custom, we wrote it) that provides the features most people want to configure in their sieve rules such as email forwarding, filtering based on From/To address, vacation messages, and spam blocking. Of course, they have no idea it is actually sieve behind the scenes. They just point and click the web interface. This web interface has sanity checks to prevent people from doing silly things like forwarding mail to themselves or the other common email aliases on their accounts. We also offer direct sieveshell access for users that ask if they can do more than the web interface offers. If these smart users shoot themselves in the foot, oh well. Sounds remarkably like what we have, except we don't provide a timsieved that listens to the world - people have to paste their sieve scripts into a web interface that does syntax tests before uploading it. Mainly for proxying reasons, we don't have anything set up that can proxy the sieve protocol, and we don't allow direct connections to our backend servers. Yeah, sieve is a weird language in some ways, but it mostly gets the job done and it's the cyrus way. We could probably get much the same by delivering to plus addresses from our perl lmtp proxy, but why re-design the wheel? Bron. -- Bron Gondwana [EMAIL PROTECTED] 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
Re: Sieve forwarding loop destroys e-mail
On Mar 31, 2008, at 5:40 AM, Joseph Brennan wrote: A mail delivery system that loses mail is buggy. I don't need to look at the code to know that. And knives that cut people are bad. No matter how they are used. *whatever* plonk. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness 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
Re: Sieve forwarding loop destroys e-mail
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
Re: Sieve forwarding loop destroys e-mail
On Mon, Mar 17, 2008 at 5:39 PM, Gary Mills [EMAIL PROTECTED] 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. If you force a keep in your sieve script, the mail will be delivered at least once in the mailbox 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. You must enforce this at sieve script creation, because sieve and even cyrus dont know about yourself. They dont know if the forwarding address is not an alias or even an external address with a forwarding to the cyrus mailbox. Once the message has been `seen' and is about to be forwarded again, it would be better to deliver the message into the mailbox, rather than deleting it. Is this possible with the current design of the duplicate delivery database? How can a message be 'seen' if it is not in the mailbox, and how can the mailbox owner read this message if he is in vacation ? Or you mean 'seen', already in the delivered db ? But then this is the job of the delivered db to drop the email to avoid loop. enforce a keep in the sieve script is a good solution. Reagrds -- -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 -- Alain Spineux aspineux gmail com May the sources be with you 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
Re: Sieve forwarding loop destroys e-mail
--On Sunday, March 30, 2008 2:27 PM +0100 Alain Spineux [EMAIL PROTECTED] wrote: 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. You must enforce this at sieve script creation, No, it is just totally wrong that an action other than 'discard' will result in mail silently vanishing. Maybe this is what does happen, but it is not what _should_ happen as was asked. It _should_ either go to inbox (grounds: ignore a bad rule) or back to sender (grounds: not deliverable as configured). Joseph Brennan 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
Re: Sieve forwarding loop destroys e-mail
Joseph Brennan wrote: No, it is just totally wrong that an action other than 'discard' will result in mail silently vanishing. Maybe this is what does happen, but it is not what _should_ happen as was asked. It _should_ either go to inbox (grounds: ignore a bad rule) You are assuming that a bad rule is something a computer program can figured out. I would ask that you spend some time determining how the program could determine it is a bad rule, and provide a patch to fix this behavior. (in short -- it's harder than you think) or back to sender (grounds: not deliverable as configured). Only if you want to become a source for backscatter. -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness 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
Re: Sieve forwarding loop destroys e-mail
On Sun, Mar 30, 2008 at 02:27:29PM +0100, Alain Spineux wrote: On Mon, Mar 17, 2008 at 5:39 PM, Gary Mills [EMAIL PROTECTED] 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. If you force a keep in your sieve script, the mail will be delivered at least once in the mailbox It's perfectly valid to have nothing but a `forward' in a sieve script. People do this all the time when they don't want to keep a copy for themselves. Unfortunately, some also forward e-mail to themselves, expecting that to work. Once the message has been `seen' and is about to be forwarded again, it would be better to deliver the message into the mailbox, rather than deleting it. Is this possible with the current design of the duplicate delivery database? How can a message be 'seen' if it is not in the mailbox, and how can the mailbox owner read this message if he is in vacation ? Or you mean 'seen', already in the delivered db ? But then this is the job of the delivered db to drop the email to avoid loop. I suppose I mean `delivered'. Yes, it will be discarded the next time it's delivered. That's the problem. There needs to be some connection between delivery and the forwarding process. Of course, it's impossible to distinguish between a forwarding loop and a real duplicate unless another `Received' header is added to the message header. -- -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
