[ http://issues.apache.org/jira/browse/JAMES-322?page=comments#action_64492 ] Stefano Bagnara commented on JAMES-322: ---------------------------------------
I worked on this but I need to make changes to a lot of core code to implement per recipient NOTIFY/ORCPT requests. Here is an email I sent to the developer list: ------ The steps to implement this are: 1) change the SMTPServer to handle ESMTP-DSN requests. 2) change the RemoteDelivery/LocalDelivery and other mailets to support delivery notifications 3) change the DSNBounce mailet to handle "delivered", "relayed" and "delayed" notifications. I already create a first implementation of the steps 2 and 3 but, before to spend a lot of time at my own implementations, I would like to know what do you think on these issues: A. "per Recipients Attributes": ESMTP protocol allow to add per recipient informations in the RCPT SMTP command. In particular the NOTIFY and ORCPT keywords. Both are needed for DSN notifications and are per recipient. So I need to add this per recipient information in the "Mail" object. I think that the best thing would be to have "recipient attributes" (as like as mail.attributes) but this would need a lot of changes to core classes. An alternative could be to have mail.attributes whose names depends on the specific recipient. This mean a lot of additional work while duplicatin/splitting email due to partial recipient matches and less clean design. B. <bounceProcessor> problems: Currently the DSNBounce can be added to a bounceProcessor that can be invoked from the remoteDelivery before GHOSTing the mail. This can work for "relayed" or "failed" results but will not work for "delayed" (because the mail is not ghosted and cannot be put in the bounceProcessor because we still need it in the outgoing spool). Currently I create clone of the delayed email to be sent to the bounceProcessor. I think that the best thing would be to: 1) add a DSNrequest object as a mail attribute containing per recipient informations inside the mail.attribute 1b) SMTPServer would fill the DSNrequest according to received protocol commands. 2) duplicate will never clone that object, and duplicate will never clone the return-path automatically. 3) we automatically handle DSN notifications when a mail becomes GHOST: if there are no DSNrequest in the mail.attributes then james will not send notifications. 4) we can add a Mailet (PreventDSNnotify) to remove DSNrequests from a mail (or use the RemoveAttribute). 5) we improve Mailets that impact on delivery to support the DSNrequest attributes: 5a) RemoteDelivery should check remote server to see if it support ESMTP-DSN (already coded) and if the remote server supports DSN then use DSNrequest informations to enrich the SMTP conversations leaving further notifications to the receiving server and removing the DSNrequest attribute from the mail object. 5b) If the remote server does not support DSN then RemoteDelivery should notify "relayed", "failed" and "delayed" notifications as requested. The best thing would be allow RemoteDelivery to add error/delay informations directly to the DSNrequest mail attribute and add a handleDsnRequest to the MailetContext (instead of using a processor: see the "delayed" problem in B.) 5c) Aliasing mailet should handle notifications when they expand the email: there is a specific "expanded" status in DSN. 6) If mailets doesn't support the DSNrequest objects then james should send success notifications for mail that reach the Mail.GHOST status and generic failure notifications for mails that reach the Mail.ERROR status. -------------- > please support Delivery Status Notifcations as per rfc3461 > ----------------------------------------------------------- > > Key: JAMES-322 > URL: http://issues.apache.org/jira/browse/JAMES-322 > Project: James > Type: New Feature > Components: SMTPServer > Environment: any > Reporter: Ralf Hauser > > http://www.ietf.org/rfc/rfc3461.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
