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:
- Be sure the sender has your current, correct email address.
- 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.)
- Be sure your inbox is not full.? Use your webmail interface to confirm
this.
- 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.
- 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.
- 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:
- FROM address
- TO address
- Send date/time
- Existence and type of attachment
- Text of bounce message
- 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":
- IP address of sender's mail server
- Subject line of the bounced message
- Sender's email client (Outlook, Outlook Express, Eudora, etc.)
- An actual copy of the bounce message, which can be sent as an
attachment to advantexllc (at) hotmail (dot)
com
- 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
?
?
?
?
?