We have typical bussiness webapp that allows our users send e-mails with offerings to their clients. We set user e-mail in FROM field so the client can replay directly to te user. The problem is that because of SMTP protocol undeliverd e-mail notification is returned to our e-mail adress(the address of the account we send e-mails from).
Do you know elegant way to handle this undelivered emails? I mean the easiest way to let the sender know that his mail was not delivered.
Exactly which routine are you using to send the Email? We send emails via raw SMTP using HTTP put_lines and the replies bounce back to the address we nominate in the FROM: field.
See if your SMTP API wrapper has a Reply To: field
Some APIs might not provide that functionality because it increases the possibility of spamming.
There are 3 "Headers" that emails have.
You probably want to be setting the 3rd :)
( Note, some servers don't reply to these lost messages at all, becuase recently spammers have been putting addresses there that are not their own, doing a 3rd part bounce attack using the automated reply system to turn email servers into an open relay! )
See Section 4.4 of this document for further details: http://www.faqs.org/rfcs/rfc822.html
First, it's important to understand the difference between the "From:" header (which the recipient sees in their email client) and the sender address (which is also called the envelope return path, or the argument to the SMTP "MAIL FROM" command). The sender address is where bounce messages go when the email can't be delivered, hence the other name return path.
SMTP doesn't restrict what address you use as the sender address (except that it must by syntactically valid), but whatever SMTP client library you use might, so you'll need to check that out.
Changing the sender address is where you can do clever things to help detect email bounces and report them back to the webapp or sender. The most common thing you'll see is to encode the recipient address in the sender address, e.g. with a sender address like this: [email protected]. The MTA responsible for senderdomain.com needs to know to deliver all emails for [email protected] to [email protected] -- but that's a fairly common requirement. Then you take the email that is received, and instead of trying to work out from the bounce message in the contents (which could be in any format) who the recipient was, you can get it right from the recipient address.
You can do more complex things as well, like hashing the recipient address so it's not visible directly in the sender address, e.g. [email protected]. And you could include some identifier for the email that was sent, in case you're sending multiple emails to the same address and want to know which one bounced.
These tricks are called Variable Envelope Return Path or VERP, and are commonly implemented by mailing list software.