Inbound Email Bounces

If you have been directed to this page, it is likely because you have not provided the necessary information to make it possible for us to assist you, or you have questioned our policy regarding inbound email. Please read the information below, and submit your support request accordingly.

One of the most frequent types of support calls and emails we receive is related to problems with inbound email rejection. To provide you with the best service possible, we have created this page as a guide to how you may properly report an inbound email problem, and to provide reasonable, non-technical explanations of our email service policies.? Please Note:? This is NOT our official Terms of Service (TOS) document, which can be found elsewhere on our site.

If you are having trouble receiving email from a particular sender, and the sender has reported to you that their messages to you are bouncing, there are specific steps you must take, and specific information you must provide? in order for us to help you.

Steps to take first:

1. Be sure the sender has your current, correct email address.
2. Be sure the sender is not trying to send you an attachment that is too large to fit in your inbox.? Sending emails with attachments larger than 10MB is considered rude and a misuse of the Internet email protocol.? (Yes, people do it, but that doesn't make it a Good Thing To Do.)
3. Be sure your inbox is not full.? Use your webmail interface to confirm this.
4. If the sender is attaching any file(s), try having the sender send a plain-text, no-attachment message to you first and see if it gets through.
5. Run a DNS REPORT against the sender's domain (everything after the @ symbol in their email address).? If you see lots of warnings or errors related to the sender's DNS or email server configuration, rest assured that they must fix those problems before we can open a ticket, and certainly before we consider whitelisting.? If you don't run a DNS Report, we certainly will, with the same results.? More information on how to run this report is included below.
6. Obtain at least the text of the bounce message.? If 1-5 do not uncover a specific problem, you're going to need the bounce content.

Bare Minimum information we MUST HAVE in order to open a trouble ticket regarding inbound email problems:

1. FROM address
2. TO address
3. Send date/time
4. Existence and type of attachment
5. Text of bounce message
6. Confirmation from you that you HAVE performed steps 1-5 under "steps to take first", above, and the results you obtained.? You are one degree closer to the problem than we are -- please do your part!

Additional very helpful information that will "help us to help you":

1. IP address of sender's mail server
2. Subject line of the bounced message
3. Sender's email client (Outlook, Outlook Express, Eudora, etc.)
4. An actual copy of the bounce message, which can be sent as an attachment to advantexllc (at) hotmail (dot) com
5. An actual copy of the original message, which can be sent as an attachment to advantexllc (at) hotmail (dot) com

Without at least the bare minimum information, provided within 72 hours (3 days) of when the incident occurred, we simply cannot investigate the problem for you (and will probably just refer you to this page).? Don't get angry... just provide the proper information so we don't have to play "20 questions"... our time is valuable too!

Log files and mail archives are rotated off the server after about three days, after which the forensic/diagnostic information we may need to troubleshoot an inbound email problem is no longer available.? Please contact us with the requested information before 72 hours have elapsed.

How to run a DNS report

It's easy.? Simply visit www.dnsstuff.com, and find the form field on the left side (you may have to scroll down the page a bit).? It will look like this:

Type in the domain of the sender (everything after the @ symbol in their email address), and click "DSN Report".

If you see LOTS of red or yellow results in the "status" column, that's a good clue that the sender is using a mail server or domain configuration with a lot of problems.

We do not block messages based solely upon failure of different parts of the DNS Report -- some failures or warnings we can safely ignore.? If you are unsure, simply copy the URL of the report (after you run it), and send it to us, and we'll let you know which problems are most critical.

Tests that fail on the report in the following categories are usually a bad sign:

• Most NS tests
• MX tests
• Mail tests

While you are there, you might want to take a moment to use some of the other excellent tools available at www.dnsstuff.com to test the sender's domain -- including the Spam Database Lookup,? and perhaps the DNS Timing report.

These tests are all considered accurate and useful, and we rely on them first, even if you choose not to.

Reasons A Message May Bounce

Our mail system uses a variety of methods to determine whether an inbound message is to be considered spam, including use of common blacklists, rejection of messages from servers and/or domains that do not follow Internet RFC specifications, and virus scan results prior to delivery.

The Internet RFCs are the "rules" that are meant to hold the Internet together.

Our mail servers and domain DNS configurations all follow the RFCs -- it's what assures us that OUR client's outbound messages have the best potential for reaching their destination, without risk to the recipient.? We also work hard to ensure that we remain off all relevant blacklists, and that our mail servers are secured from spammers.? Finally, we have a very strict anti-spam policy.? Simply stated...

WE EXPECT ALL SERVERS THAT CONNECT TO OURS TO DO THE SAME WORK THAT WE HAVE BEEN EXPECTED TO DO, TO ENSURE DELIVERY.

This policy is NOT unusual -- many competent, well-versed email administrators and companies are adopting this same exact policy.?? We are not taking any USUAL or EXTREME steps; simply expecting all mail and DNS admins to know what they are doing before they decide to set up a mail server and start blasting out messages as they see fit.? In fact, we are actually somewhat more lenient than other mail services, in several areas.

If other mail admins wish to remain ignorant to the clear configuration rules of the Internet, and not police their networks and servers as we do, then the fault for non-delivery lies solely with them.? If we determine (usually via the DNS report) that a mail server or domain is misconfigured, we will NOT take any additional time to troubleshoot until those problems are resolved -- it's not our responsibility to teach someone how to send a valid message from a valid, properly configured domain, using a properly configured mail server.? We get paid for that type of consulting work.

Of the few email support calls we get each month regarding bouncing of inbound email, 99% of them are the result of an ignorant DNS or mail server admin that has an extremely poor DNS Report.? A few are on blacklists.? The rest are sending messages that are unusually "spammy" in content, or sending spammy or infected attachments.

FREQUENTLY ASKED QUESTIONS

"Can't you just whitelist xyz.com for me?"

In special cases, we have been willing to whitelist specific mail servers that, for whatever reason, simply cannot deliver to our server.? In most cases, it is a corporate mail server serving a single domain.? We will not under any circumstances blindly whitelist massive blocks or farms of mail servers, or all the mail servers of the free mail services available (i.e. AOL, Hotmail, Yahoo!, etc.).

Whitelisting is a last resort, and is always under a special circumstance, and is only done after the DNS Report and blacklist situation has been reviewed.

We cannot whitelist by FROM address either (spammers spoof the FROM address of their junk ALL THE TIME).? Users of free mail services are getting what they pay for, and a great deal of system-damaging spam has come from such services.

"Why can't we have a spam mailbox?"

Outright rejection of a message is both better for the system AND more reliable for the sender and recipient.? The sender is promptly made aware of the fact that their message did not reach the intended recipient, and our systems are not taxed with delivering thousands of messages that literally nobody will read.? In addition, all it would take is a single joe-job to fill up a spam mailbox very quickly.? Once this happens, our server would start bouncing any other spam destined to the full-mailbox, and those bounces are usually headed to a spoofed FROM address, and usually, to some poor soul that never sent the message in the first place.? In this situation, our server actually becomes part of the problem.? We cannot allow that to happen, lest we too be considered spammers... making your outbound mail undeliverable too.

Instead, we simply silently delete spam, or reject the inbound email at the envelope stage, which forces the CONNECTING server to generate a non-deliverable (NDR) message back to the actual sender.

"Why can't I have a catchall account?? And if no catchall account is available, why don't you bounce messages to incorrect addresses?"

The most common reason people give for wanting a catchall account is "in case someone mistypes my email address".? The benefits of a catchall account used for that one case is greatly overshadowed by the fact that you can be quickly inundated with box-filling SPAM when a spammer decides to execute a dictionary-style attack against your domain (in other words, sending to [email protected], all of which would be "caught" and dumped in your valid mailbox).

Further, if we were to bounce all the messages that are sent to incorrect or non-existing email addresses, those bounces would be going back to someone that probably never sent the message in the first place (again, since spammers usually spoof the FROM address).? Our "No catchalls" policy means no denial-of-service attacks that can fill up a mailbox, and our "no bad-recipient bounces" policy means that we're not inadvertently spamming someone with bounces... someone that never sent the bouncing message in the first place.

We are investigating a means of rejecting mail to bad-recipients at the SMTP Envelope stage (which means the connecting server would generate an accurate bounce to the sender, instead of our server generating a bounce to the potentially spoofed FROM address), but so far the implementation of such a feature would use much more processing time and require a greater amount of maintenance, with little return from the investment.

"You have all these policies, but I still get spam!"

Of course you do.? We all do.? Spammers rapidly change their tactics.? Our systems keeps up fairly well, but it is not perfect.? To block those few remaining messages that get through would probably mean a substantial increase in collateral damage.? It's a balancing act, at all times.? Please report substantial amounts of spam to us -- more than 20 per day might be considered excessive, unless you publish your email address directly on your website, have had it for a very long time, or have willingly provided your email address to lots of different sites.

History, or "How did things end up this way?"

There is ONLY one, two-part answer -- (1) Spammers have done all they can to ruin legitimate email traffic, and they've very nearly succeeded.? If more people demanded that their ISPs follow the RFCs, and have strict anti-spam policies, and police their networks, the problem of collateral damage would be significantly reduced.? (2)? The Internet mail delivery protocols themselves are inherently flawed.? And until the Internet adopts a completely new, more secure set of protocols (planet-wide), the problem is not going to go away.? There is no easy solution; weighing delivery of valid emails against the constant onslaught of SPAM is and will continue to be a balancing act (as stated above).

We have struck what we feel is a good balance through the use of spam-analysis algorhythms, use of blacklists, and enforcement of actual Internet policies and rules.? No email service is perfect, ours included.? But ours has a nearly 100% uptime and a relatively low amount of spam.

We have many clients using our email service.? They rely upon it for daily business, both between their employees as well as with third parties.? We have a commitment to making sure their email is secure, meets Internet standards, and is available as much as possible.

Our email system is fully customized, based upon the rock solid FreeBSD platform.? We have spent (and continue to spend) a great deal of time ensuring that mail delivery is as efficient as possible, while protecting our clients from the thousands of unsolicited SPAM and regular joe-job style attacks upon our systems.? There was a time, not so long ago, when our brand new, highly efficient systems would be brought down by the constant flood of joe-job bounces and spam attacks against several high-profile domains on our servers.

We have solved those problems in large part by simply expecting those servers that wish to deliver mail to us to "follow the rules".? When they do not, they are immediately rejected.? "The Rules" are too extensive to outline here, but every competent DNS and/or mail server admin should be fully aware of them.? If they don't want to understand the rules, then they shouldn't be "playing the game".? It's that simple.

Unfortunately, that leaves some legitimate messages to our clients undeliverable.? This "collateral damage" has been minimized by the rulesets we use... in other words, there's usually a good reason why a message is bounced, and a quick lookup in the DNS Report or a quick analysis of the original message will usually reveal why the sender was rejected.

If you deal with a great many senders that use mail servers or services that simply will never follow the Internet RFCs, do your part -- encourage them to vote with their dollars, and move to a mail service that has a clear commitment to reducing the amount of spam, viruses, and phishing we all face.? Network policing, RFC-following, spam-intolerant ISPs should be rewarded, while ISPs that do not reflect those values should be shunned.

"If you won't help, I'll go somewhere else..."

Larger clients have opted for fully customized mail servers specifically for their domain.? Smaller clients have worked with us to help the rejected sender either get their situation straight, or gently encourage them to go with a better mail service, or as mentioned above, whitelist servers with unusual or extreme circumstances.

Beyond those options, there's not much else we can do. Why?? While we value your business, we also value the business of our other clients as well.? Protection of our client mailboxes as a whole must take precedence.? Our policy is simple - we block spamming, blacklisted, virus-spewing or misconfigured servers, as part of our overall commitment to protecting our clients from some Very Bad Things that can end up in their email boxes.?

If you do decide to go with a more "lenient" email host, please consider that you are essentially letting ignorant mail admins and spammers win. While we understand that email bounces can be frustrating, allowing others to ignore the rules of the Internet without any consequences at all is much more damaging for all of us in the long run.? Be part of the solution, not part of the problem!

Reference Links

About Internet RFCs:??

http://www.irt.org/articles/js197/index.htm

http://en.wikipedia.org/wiki/Request_for_Comments

Properly Configuring Outlook or Outlook Express for your Advantex LLC account:

Outlook: http://www.advantex.net/index.cfm/fuseaction/Content.Display/Page/PD20060415a.cfm

Outlook Express:? http://www.advantex.net/index.cfm/fuseaction/Content.Display/Page/PD20060420a.cfm

?

?

?

?

?