Michael Menge 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. > > 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. This is unacceptable as the user will never get a local copy of the message. > 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. Cyrus already keeps track of redirects to prevent mail loops. This option makes the most sense. BTW, the latest Sieve documents are RFC 5228-5235 -- 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
