On 4/12/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
> 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'?
We used this term as a shortcut to define operations done "in-protocol".
When you receive a message via SMTP you have a last-chance to tell the
client that the message cannot be delivered when replyint to the
"CRLF.CRLF" of the DATA content. Everything we do before that reply is
considered in-protocol processing (and often we referenced it as
fast-fail, as it mostly applies to fail early the delivery).
thanks :-)
>> 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.
I still don't agree on this point.
Imho it is not fetchmail-vs-smtp that change the correctness of
bouncing. A mail read with fetchmail should be treated exactly as a
message received via SMTP: they are mail injectors for the spool,
nothing else.
makes sense
I agree with you that a sieve script error should not result in a
bounce, but this applies to both smtp and fetchmail origined mails (imo).
Imho a solution could be not-to catch the script exception in the Sieve
mailet so that you can use the "onException" directive in config.xml and
decide what to do with errors (send them to a specific processor), or if
this is not feasible add a directive to the Sieve mailet to say what
processor to send the mails with sieve errors.
works for me
can anyone think of any reason for me not to patch SieveToMultiMailbox
as stefano suggests?
> 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.
Are you aware of this?
http://wiki.apache.org/james/HandlingExceptions
i am now :-)
thanks
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
