| Author |
|
agp
Newbie
Joined: 22 April 2008
Location: Romania
Online Status: Offline
Posts: 3
|
| Posted: 22 April 2008 at 5:23pm | IP Logged
|
|
|
Hi,
is it possible to control the bounced emails if we send the emails from ASP.NET with MailBee.Objects via the MailBee.Queue?
Regards,
AGP
|
| Back to Top |
|
| |
Andrew
AfterLogic Support
Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189
|
| Posted: 23 April 2008 at 1:47am | IP Logged
|
|
|
Yes it's possible and doesn't matter how you send e-mail messages. Here is a sketch of tutorial for bounce messages which will be a part of future versions of MailBee.NET Objects documentation:
Introduction To Bounced Messages
When e-mail cannot be delivered for some reasons such as full mailbox, blocked domain or non-existent account, bounced e-mail is sent to the original sender. Probably, if you are sending a few mails every day delivery errors won't be a big deal to you. In case when you are sending a lot of mails every day you need to know potential problems. Server can block all mails from you if you are repeatedly sending messages to a bad address on some popular domain. Also, if you have low bandwidth connection it's also necessary not to waste traffic. But if you are repeatedly sending e-mail to bad addresses, it wastes your bandwidth. Even if your connection has high bandwidth capability, this problem will grow in scale with time.
It is obvious that you have to identify bad addresses and delete them from your address database if you want to improve your work. Sometimes, it is necessary not to delete bad addresses but to mark them as "bad" and then try to send message to them one more time. But how will we know which address is bad? The simplest solution is address verifying. Sometimes, users make misprints in email addresses. Thus, your program should check the email address for syntactical errors and for non-existent domains. But unfortunately, syntactical check won't tell you whether the user's part of the address is valid.
Most of all SMTP servers will accept mail addresses to anyone in their domain. The problem is that such servers figure out that accepted mail address does not exist a few minutes later (time can vary). For example, if you send a message to 12345@domain.com, while you have valid addresses in the same domain (jdoe@doamain.com), you will get a bounce a bit later. Server accepts all mails that going to a valid domain. That's why you can determine if an address is bad only if your message returned with undeliverable mark (so-called bounced message). The SMTP protocol provides a notification mechanism when a message can not be delivered. This notification mechanism works by creating a new e-mail message which is sent to the original sender to inform him that their message was not delivered.
Part 1 - Smtp Part
It is often more convenient to have some sort of central location for bounced messages. All returned mails should arrive to a single mailbox which is meant for bounce e-mails. Let's name our bounce message box - bounce@domain.com. Obviously, you need to be sure that returned messages will find their way to the bounce box.
Let's see how these messages are routed by SMTP servers. When a message is submitted to an SMTP server it is tagged with a return-path. The return-path is the path that the server should use to communicate with the original sender of the message, and therefore the return-path is typically the e-mail address of the sender (the "From" address). The return-path is recorded in the message. "From" header is used to display the sender address. The return-path and the address in the field "From" don't need to be the same. Hence, you can send email which will use "From" field to display sender (jdoe@domain.com) but return-path will contain bounce box address (bounce@domain.com). With this trick, all bounce messages will be returned to special mailbox.
Part 2 - Pop3 Part
In SMTP part of this sample we made bounce e-mails to arrive to specified single e-mail account.
Each bounced e-mail contains (along with other info) failed e-mail address. This failed address is what we want to know. The task looks pretty simple – all you have to do is to scan bounced body for typical words that would point to the bad address. But there is a pitfall: each mail server uses its own bounce message format. While they have almost the same "From" and "Subject" fields, the bad address can be at any place of the message. Typical bounced message form of MailEnable server looks like:
From: POSTMASTER@domain.com
To: jdoe@domain.com
Subject: Message Delivery Failure
MailEnable: Message Delivery Failure.
The following recipient(s) could not be reached:
Recipient: [SMTP: bill@domain.com]
Reason: The message could not be delivered because the domain name (domain.com) does not appear to be registered.
Part 3 - Wildcard Bounce Box Method
The advanced way to manage bounce messages is to use wildcard addresses. Let's explain what is it. Wildcard box allows you to send mail at bounce*@domain.com but messages would come to bounce@domain.com. Thus, you can append some custom data to the end of the account name of the return-path and it will still be delivered to the bounce@domain.com account. It can be very helpful if you are working with a big database (mailing list) and each e-mail address in the database has unique id. You can use this id to operate with bounce mails. For example, suppose that the recipient address is bill@domain2.com, and the id of this address in your database is 10. Using this information, you can build an address such as bounce_10@domain.com.
You can send a message to bill@domain2.com and set bounce_10@domain.com as a return-path. Of course, you can fill the "From" field with your address of a sender, for example let's use jdoe@domain.com address. If the message is delivered successfully, Bill will think that Joe is the real sender, but if for some reason the message is undeliverable, bounce message will be sent to bounce_10@domain.com. This message should be delivered in your bounce box because you've configured your mail server to deliver all messages for bounce*@domain.com to bounce@domain.com. After that, you can easily find which address is bad. Each of bounce messages should have custom bounce address in "To" header. If there were some problems with Bill address, "To" field of the bounce message will look like bounce_10@domain.com. 10 is the id of the e-mail address in your database which is related to the bounce. Thus, you don't have to search bad email in the text of the message. Of course, if your mail server does not support wildcard addresses, you have to use single bounce box and scan messages for bad addresses.
Note: Some mail servers use the "From" address of the original message as the "To" address of its resulting bounce. You can scan the message "From" header and find your bounce address there.
Best regards,
Andrew
|
| Back to Top |
|
| |
MailBee.NET Objects 
MailBee.NET Queue 
MailBee Objects 
WebMail Pro PHP 
AfterLogic Aurora 
MailSuite Pro for Linux 
Unified Messaging Solution 
Search
Register
Login
Topic: Checking bounce demails
Privacy policy |
Refund policy