First a word about the database of forwarded message. I imaging the duplicate_db is just a list of tuple : (msg-id, mailbox) You could simply store your forwarded email in (msg-id, forwarded_address) format in this db! No need of a new one! You must worry to keep compatibility with existing configuration, then maybe add options in imapd.conf or improve the sieve language to answer the question: can I redirect an email even if the delivery fail. You could add a command "forwad" to the sieve language that will forward the email at all cost. For the error code to return, you have th choice between 25X, 55X and 45X when lmtp_over_quota_perm_failure is disabled in imapd.conf. The main problem when you duplicate and email, for example the local delivery and the forwarding, you have 2 two error code but can only return one! You dont know what the user want (except if you modify the sieve syntax to include error management and let the script writer the choice witch error code to return). And finally you dont know where the user will read his email, maybe he will never look in his INBOX or never check his forwarding address. And he could be surprised if the sender get a non delivery report while he received the email in his usual mailbox! When you cannot deliver an email you must send a NDR to the sender (return a 550 or 450) because it is better to warn the sender than let him thing his email will be read. For short : the sieve interpreter will have to do zero, one or multiple of these actions : - discard - keep - fileinto - redirect If only one fail, then return the error, if multiple fail, return the highest error code. Hope this help On Jan 31, 2008 3:37 PM, Michael Menge <michael.menge@xxxxxxxxxxxxxxxxxxxx> wrote: > Hi, > > I had a look at rfc2033. It is possible to send an individual returncode > after the DATA stage for each recipient. > > So befor I try to patch the lmtpd, i would like to discus, which is > the desired/expected behavior. To make discussion easier lets think about > common usecases. > > > 1. discard: > We use Spamassassin to mark spams. The user has the choise to discard > them or to sort them into a folder depending on the spam score. > So we don't want bounce-messages to faked email addresses if the > message would be discard. So if only the discard action is performd > we should return 250 2.1.5 Ok > > 2. redirect: > Some Users forward there Messages to other accounts. (They may be > over Quota as the sort some mails into other folders). If the only > action that would be performed on a message is "redirect" I would > forward the message and return 250 2.1.5 Ok > > 3. redirect+fileinto/keep: > This is a tricky case. If a fileinto/keep and a redirect action would > be performed i see the following options > a. perform redirect, but NOT fileinto/keep and return 250 2.1.5 Ok > This means the Message is not stored localy and if > redirections fails the recipient nor the sender are informed. > b. perform redirect, remember message id and redirection and return > 452 4.2.2 Over quota / 552 5.2.2 Over quota (remembering is not > needed in case of perm errors) > We need to implement an other Database for this. > c. perform NO action and return 452 4.2.2 Over quota > or 552 5.2.2 Over quota. > > 4. discard+fileinto/keep > I don't think this is a common usescase, but it may happen as a mail may > match multiple rules. I would like to handle this case in the same way as > Case 3. but I think in this case we can't return 250 2.1.5 Ok as we don't > keep a copy. > > Are there other Usescases/Options we should think of? > > I also had a look at the sieve rfc3028, but I'm not sure if it is helpfull. > rfc3028 mentions in section "2.10.6 Errors" > > Implementations MAY choose to do a full parse, then evaluate the > script, then do all actions. Implementations might even go so far as > to ensure that execution is atomic (either all actions are executed > or none are executed). > > Other implementations may choose to parse and run at the same time. > Such implementations are simpler, but have issues with partial > failure (some actions happen, others don't). > > ... > > This specification allows any of these approaches. Solving the > Halting Problem is considered extra credit. > > When an error happens, implementations MUST notify the user that an > error occurred, which actions (if any) were taken, and do an implicit > keep. > > Is "Over Quota" a runtime error? And if how can we notify the user or > sender without using more space? > > > -------------------------------------------------------------------------------- > M.Menge Tel.: (49) 7071/29-70316 > Universitaet Tuebingen Fax.: (49) 7071/29-5912 > Zentrum fuer Datenverarbeitung mail: > michael.menge@xxxxxxxxxxxxxxxxxxxx > Waechterstrasse 76 > 72074 Tuebingen > > > > > ---- > 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
