> > I think that we should first improve (add) delivery status
> tracking in
> every
> > james part, then we can simply add the "in-protocol"
> handler or make
> > the root processor synchronized with the smtphandler (so that it
> > returns SMTP errorcodes instead of bounces).
>
> I think you're confusing two things here.
>
> 1/ "fast fail" should examine the envelope and the messages
> as they are streamed and respon with an SMTP reponse code
>
> 2/ asynchronous message processing/routeing, which should
> result in a DSN bounce message.
No, i'm not confusing the two issues: i really thing that we need a better
way to handle delivery status tracking in the asynchronous message
processing/routing and that this new "working" method will help us also in
the fast failing mechanism (or at least in the last response to the DATA
command).
I'm referring to the thing that Noel calls "in-protocol processor".
> I agree that there is an issue with DSN for delayed messages
> per your defect.
>
> I think IIRC that JavaMail provides an event model for
> transport events which could reasonably be used to trigger
> DSN bounces, particularly in response to delayed. But that
> will require an implementation of JavaMail as the reference
> implementation doesn't initiate any events.
>
> > Is there an extensible way to provide this feature? Any idea?
> see above, some kind of out-of-channel event framework for
> triggering DSN messages.
I think that you are wrong when you talk of triggering a "dsn bounce": DSN
is (imho) more complicated than adding a bounceProcessor to the
remoteDelivery.
I think the current way to handle this is a limit to this and we should
agree on a solution: I only would like to agree on a solution, if I like the
solution you will have my time and my patches on jira.
To handle DSN correctly you should make DSN-aware most of the james
components:
- SMTPHandler should correctly handle ESMTP-DSN commands
- LinearProcessor should handle DSN requests when splitting an email due to
partial recipient matching
- LocalDelivery/RemoteDelivery and any other mailet that will complete the
lifecycle of out mails should handle specific DSN requests (local delivery
should issue a 2.1.5/delivered, remote delivery could issue a 2.0.0/relayed,
and more).
- RemoteDelivery should try to understand (i already implemented this)
wether remote server supports DSN extension or not and behave differently.
- Virtusertable, forward, redirect and any other mailet should handle DSN
correctly adding Original/Final recipients informations or sending back a
"relay" or "expanded" action when changing the return-path.
Remember that a mail with multiple recipient should return a DSN containing
heterogeneous delivery status per recipient and that an SMTP client could
have asked different notification option per each recipient.
Use case:
MAIL FROM: <[EMAIL PROTECTED]> ENVID=testenvid
1) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS,DELAY,FAILURE
2) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=FAILURE
3) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS
4) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS,FAILURE
5) RCPT TO: <[EMAIL PROTECTED]>
NOTIFY=DELAY,FAILURE ORCPT=rfc822;[EMAIL PROTECTED]
6) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS,FAILURE
7) RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS
This mail should return this informations:
1)
Final-Recipient: rfc822; [EMAIL PROTECTED]
Action: delivered
Status: 2.1.5
2)
Final-Recipient: rfc822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.1
3)
NO INFORMATIONS ABOUT THE [EMAIL PROTECTED] because this failed
and the sender only wants SUCCESS notifications.
4)
NO INFORMATIONS ABOUT THE [EMAIL PROTECTED] because RemoteDelivery will
pass the NOTIFY=SUCCESS,FAILURE to the remote server and silently GHOST the
local copy.
5)
RemoteDelivery should create one or more of this DSN while attempting
delivery to the temporary unavailable host:
Final-Recipient: rfc822; [EMAIL PROTECTED]
Original-Recipient: rfc822; [EMAIL PROTECTED]
Action: delay
Status: 4.4.7
And finally send a:
Final-Recipient: rfc822; [EMAIL PROTECTED]
Original-Recipient: rfc822; [EMAIL PROTECTED]
Action: failed
Status: 4.4.7
If it GHOST the mail before a successfull delivery.
6) This notification is only due because remote server does not support DSN
and we must inform the sender of the last SUCCESS operation.
Final-Recipient: rfc822; [EMAIL PROTECTED]
Action: relay
Status: 2.0.0
7)
Final-Recipient: rfc822; [EMAIL PROTECTED]
Action: expanded
Status: 2.x.x (I don't remember the correct status for the expanded)
Please note that 1,2 and 3 will be handled from a single LocalDelivery call
that should provide enough informations to differentiate the 3 responses.
A possible solution would be to have mailetcontext callbacks that are called
by the mailets to update the mail "delivery status" so that it can decide
wethere to create DSNBounces (standard behaviour) or to inform the
SMTPHandler of the status update ("in-protocol processor" behaviour).
Did you get the problem? Have you understood why I think a solution to this
problem would help also the synchronous reply to the DATA SMTP command?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
