TODO: Bounce Messages

[acoliver]

Presently we silently fail all mail deliveries. Configurable bounce messages are essential for M1. Please include unit tests of some type!

estimated time 8-16 hours

[kabirkhan]

I intend to be looking at this. The only problem is that due to the mailboxes not requiring authentication local messages will never bounce.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=46907 (Still need to get back to you on this)

I will add my stuff to the Exception bits of the XXXDeliveryMessageDrivenBEan classes. For remote delivery I guess i will need to trap the error somehow so I can report what went wrong.

I'm not sure about the best format to use, but I reckon a small mail containing the subject, and a list of failed receivers with reason for each should be a good start. Since remote and local delivery are separated they might end up with two error reports.

Do you reckon that the message should be sent to the sender in Mail.From, or that it should look at the mail headers and look for stuff like Reply-To etc.?

[kabirkhan]

I am currently looking at understanding the unit testing framework so that I can test the changes I made to JMSMailListener. I have no idea how long it will take, and don't want to hold you guys up so if anybody wants to go ahead with implementing bounce messages feel free!

Cheers,

Kab

[spiritualmechanic]

What is the status of this? I just downloaded the 3.2.4rc1 so the unit tests run. I've been busy lately so I hadn't had time to download/build it, but now I'm looking through the code and unit tests again.

Steve

[kabirkhan]

Go ahead if you like! A few things that I have found worth bearing in mind, which may or may not help you on your way, are:

From what I gather bounce messages should have the From header set to 'empty' (i.e. From <>), Im not sure what the status in MailAddress is for allowing this, but the changes shouldn't be too big. Also, we need to see if CmdMAIL will allow for receiving this, so that we can receive bounce messages from other places. Regarding the sending failure we have local delivery which can fail and remote delivery which can fail. My initial thoughts were to put the error handing for local delivery in LocalDeliveryMessageDriven Bean and for remote delivery in RemoteDeliveryMessageDrivenBean. IF(!!) you choose to go with that a lot of the local stuff will not fail since there is no authentication of localmailboxes yet, and SMTPSender.send() used to send the remote mails returns false if failed, it does not include the cause of the error.

Hope this helps a bit.

Cheers,

Kab

[spiritualmechanic]

"SMTPSender.send() used to send the remote mails returns false if failed, it does not include the cause of the error"

Is this something that I can look at? I'm not sure how much time I'll have but I know jbossmail will need to be able to do this eventually?

Steve

[kabirkhan]

The below is just my gut feeling, and I could be very wrong! What do you think is best.

I think the most important thing right now is:

1) Get the bounced message sent to the sender with the original subject and a list of the failed email addresses in the message body.

Nice haves (which I think should be in place in a full release) would be:
2) Include the reason for the failure, i.e. the stuff you mention below

3) The original message attached to the bounce mail

I think we can leave 3) for now... If you like we can split 1) and 2) between us, or you can have it all and I can do something else.

Regarding 1) I thought the format should be to send a message with an 'empty' From header to the address in the From header of the original mail, probably with a subject (so that the sender knows which email we are talking about along with the address(es) that failed. As far as I can tell this empty From header is defined by (I think it was) RFC 2821 and RFC 1123. I might remember wrong though, as looking at a few bounced emails in my inbox I have seen the headers look like:

From: [e-mail]
Subject: Delivery Status Notification (Failure)
Return-Path: <>
<rest of headers here>

AND
From: CompuServe Postmaster <[e-mail]>
Subject: Undeliverable Message
Return-Path: [e-mail]
<rest of headers here>

AND
Return-Path:
Subject: Undeliverable:From dev to receivers
From: "System Administrator" <[e-mail]>
<rest of headers here>

AND
From: Systemadministrator <[e-mail]>
Subject: Unzustellbar: RE: Software AG Receipt Acknowledgement for Return-Path: <>
<rest of headers here>

They all have the From header set, but most have the Return-Path header empty, so not sure what is correct. Whoever does 1) will need to look at this in the specs to make sure we do the right thing.

KIab

[spiritualmechanic]

It's RFC 2821, right? I don't want to start suggesting things and not be using the latest RFC.

http://www.faqs.org/rfcs/rfc2821.html

Steve

[kabirkhan]

Yep, RFC2821 (the up to date SMTP one). The bit you need is section 6.1:

If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. Obviously, nothing in this section can or should
prohibit local decisions (i.e., as part of the same system
environment as the receiver-SMTP) to log or otherwise transmit
information about null address events locally if that is desired. If
the address is an explicit source route, it MUST be stripped down to
its final hop.

Section 5.3.3 in RFC 1123 ('Requirements for Internet hosts') says exactly the same. Seems I remembered wrong about this. I think this means that we can set the From and Return-Path headers to be <[e-mail]>, but that the from attribute in org.jboss.mail.message.Mail needs to be empty (or null or whatever). Sorry about the confusion!

Cheers,

Kab

[spiritualmechanic]

Okay, let me look at it and see what I can figure out. I don't really have a test environment for this, though. How do you typically test this stuff? Two jboss-mail servers? Or do you actually have another mail server to try JBoss against?

Steve

[kabirkhan]

For unit tests I'm not really sure, but one test could be to see if you can construct a Mail object with an empty from address and if SMTPSender can send that.

For real-world testing I think you would need two machines running smtp servers on port 25. At least one of them would need to be running JBoss.

My setup for testing the addition of standard headers was:

a) Our dev server at work has a live IP address
b) My home adsl line has a live IP address

I modified the hosts file of a) to point kabathome.com to the IP of b), and set up an smtp server (the one that comes with IIS, but it could have been JBoss too) on a). On b) I am running JBoss SMTP on standard port 25. When connecting to a) with a client and sending mails to [e-mail] it goes to b). I had to set up JBoss Mail on a) to have kabathome.com as one of the local domains.

If you are sending from a) to b) and want to bounce back to a), I think you could expand this a bit, something along the lines of:

Make b)'s hosts file point the domain of the senders address back to a) to resolve the return IP address. In my setup there is no POP server on a), but you could use a protocol analyzer to see what is sent on port 25. This one is free: http://analyzer.polito.it

Cheers,

Kab

PS If you find an easier way let me know.... :-)

[kabirkhan]

Has anybody started this or can I give it a go?

[spiritualmechanic]

Yeah, I'm still getting used to things, go ahead.
Steve

[kabirkhan]

Sorry to keep on doing this... I am really stuck in the testing of the JBossSX stuff. I originally thought it would take about an hour, but ages later I have still not cracked it. If anybody wants this task jot your name down, and I won't hog this task again until I am ready to start it...

[kabirkhan]

I'm ready to start this now. Is anybody doing this?