On 4/11/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote: > > SieveToMultiMailbox contains the following snippet: > > // If there were errors, we redirect the email to the ERROR > // processor. > // In order for this server to meet the requirements of the SMTP > // specification, mails on the ERROR processor must be returned to > // the sender. <comments cut> > getMailetContext().sendMail(mail.getSender(), errors, > mail.getMessage(), Mail.ERROR); > > i plan to use sieve with fetchmail, not SMTP. though bouncing the > email sounds like the right thing to do with SMTP, i don't really want > this happening when i'm feeding sieve from fetchmail. > > is this solved by some other mechanism in fetchmail? > if not, what's the best approach to adding the behaviour i need? > > - robert I see Fetchmail as just a specialization of the the general SMTP case. Mails injected into James by Fetchmail should be treated exactly as those injected by SMTP or any other mechanism. By default we folllow the specs. Why would you differ "when i'm feeding sieve from fetchmail"?
it's at the end of a long uncoordinated processing chain it starts by an upstream SMTP server accepting the mail. the mail is then downloaded via POP3 by fetchmail and put on a spool. sieve then processes the mail and assigns it a destination. the JAMES IMAP server then attempts to store the mail. around 1 in 500 mails that i receive cannot be stored by the current IMAP implementation. if fetchmail cannot process an incoming message it should leave the message on the upstream server by not marking it for deletion. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
