On 4/12/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
> if fetchmail cannot process an incoming message it should leave the
> message on the upstream server by not marking it for deletion.
Fetchmail is able to process the mail and send it to the James Spooler,
so it deletes the message.
There is no link from the spool back to fetchmail and IMHO we should not
add this.
ok
Your needs seems to similar to the "fast-fail" vs "mailet" operations:
'fast-fail'?
imho we will never be able to do all the processing "in-protocol"
(either smtp or fetchmail), and something will always be done in mailets
in the spooler, so I don't see how to implement what you want.
yes - i see this now
this raises the general issue of mixed spools
consider a mixed spool contain messages which have not necessarily
arrived by SMTP. the mail could have arrived by fetchmail, be pushed
onto the spool after being generated programmatically or loaded from a
local folder. bouncing is right for mail which arrives from SMTP but
wrong for these other examples.
maybe an exception handling strategy could be associated with the
spool. mailets would then delegate the handling of exceptions to the
container. this would allow fetchmail to feed onto a spool which did
not bounce (perhaps feeding failures onto a different spool instead)
whereas SMTP could feed to a spool that just bounced on error.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
