Last updated 26-Jun-2016[Copyright 2001,2002,2003,2004,2005,2006,2007,2008,2009,2012,2016 Frank Durda IV, All Rights Reserved. Mirroring of any material on this site in any form is expressly prohibited. The official web site for this material is: http://nemesis.lonestar.org Contact this address for use clearances: clearance at nemesis.lonestar.org Comments and queries to this address: web_reference at nemesis.lonestar.org]
If you have tried to send e-mail to a valid e-mail address and the mail comes back as being rejected, the most common causes are:
Some details of configuration errors and junk-mail-block problems are described below. If most of your mail suddenly started being rejected to a variety of recipients at different mail providers and you really really really haven't changed ANYTHING on your computer, your computer may have been hacked or infected and has sent junk mail, along with the hundreds of millions of other Windows personal computers that have viruses or spy-ware or backdoors installed. See the "Mail Blocked due to Junk Mail Controls" section below to see if the errors your mail are getting indicate a junk mail issue.
Modern mail server systems require that certain information agree before mail is accepted. These checks exist in EXIM, SENDMAIL, SMAIL and other mail server software packages. As more and more systems upgrade their mail software or turn on these features to stop spammers who forge the message source, you may find yourself running into this problem more frequently.
If you are sending mail to your ISP and then they are sending it to the destination, contact your ISP and ask them to make sure that their mail servers and the ISP DNS configuration are compliant with RFC 2821. Any reputable ISP should be eager to correct this easy-to-fix compliance problem.
RFCs are a large group of documents developed over the past 30 years that describe how all aspects of the Internet will communicate and cooperate with one another.
If you are using your own mail client (or localhost mail server) to send mail to a destination system directly via SMTP, then you likely have a setting wrong in your mail software or the DNS for that IP address is incorrect, or both. If this is the case and you are trying to send mail directly to destinations from your computer, try sending the mail via your ISPs mail servers first, and those servers should be able to deliver the mail correctly. Sending your mail via your ISP is the preferred method for people using dial-up, cable or DSL service. Or, you can correct the settings on your local mail software and DNS as follows.
To be RFC 2821 compliant, the system name your computer transmits in the EHLO handshake (this occurs when two systems are about to exchange mail with one another) must be identical to the DNS name of the IP address that your computer is currently attached to. For example, if the DNS name for the IP address your mail server is on says "mailserver2.bobsbox.com", then the EHLO handshake must state that exact name. Just saying "mailserver2" or "bobsbox.com" will not be accepted by a server strictly following the rules. You will need to refer to the documentation for your mail server software to find out how to set this value. The forward DNS "A" record should also agree with the reverse DNS for that IP address.
Depending on the software that a given mail server is running, the error messages that can be returned will vary, but almost all return a 550 response code, followed by a brief explanation. Some known messages for this particular mis-match of settings are:
550 Host domain literal A name does not match any reverse DNS PTR
550 Hostname '%s' (from reverse DNS PTR record) does not have an address
matching [%s]! Is this a DNS spoofing attack, or just badly
mis-configured DNS?
550 No reverse DNS PTR for the remote address [%s] has a hostname
matching '%s'
550 is in breach of RFC2821
550 Helo command rejected HELO Domain is not RFC2821 compliant
550 This message has been blocked because the HELO/EHLO domain is invalid
550 Can't verify your host name
550 verifying mx record reverse
550 HELO/EHLO must not be an IP address
(Note: an IP address *is* allowed per RFC 2821 so this rejection
reason is improper and the receiving mail server is not compliant
as long as the IP address given is the one of the interface
on the sending server that opened the TCP connection.)
550 fix reverse DNS
550 Your DNS is broken. Forward != Reverse. Fix or stop using EHLO.
550 HELO/EHLO domain invalid exchange.
550 Illegal HELO/EHLO greeting
550 HELO/EHLO greeting is not RFC2821 compliant
550 HELO name rejected
550 Sender rejected - your domain part is not good
550 Mail refused by local domain enforcement policy (Exchange 2007)
550 rejected because rdns
This requirement of RFC 2821 does make it difficult for people on Internet connections with IP addresses that change (like dial-up service) to send mail directly to remote mail servers from their dial-up computer client mail software. This is because any server that does accept such mail (where the EHLO and DNS do not agree) is not compliant with current Internet standards, with the exception of the host ISP mailserver, which obviously must make an exception and accept the mail from their own dial-up/DHCP customers. However, the mail servers at your ISP likely know what IP addresses belong to the ISP, and can grant access to mail software running on those IP addresses no matter what the IP address DNS values may be.
If being on a dynamic IP address (one that changes each time you re-connect to the Internet) is your situation, please configure your mail programs to always send the mail to your ISPs SMTP mail server first (which is also known as the "smarthost" or "mail server proxy"), or to the system that your ISP specifies. Since the mail server at the ISP will be at an IP address that does not change, the DNS and EHLO settings that server uses can be made to match at all times and that server will not run into this restriction, once the server has been configured correctly.
Due to a number of viruses in circulation that send mail from infected Windows computers, more and more ISPs now enforce the requirement that mail be sent to the ISPs mail servers first, by not allowing SMTP traffic to pass from dial-up, cable or ADSL pools directly to the Internet. All mail from customers must be delivered to the ISPs mail servers first, and those servers have the ability to send the mail on to places out on the Internet, usually following an automated scan of the messages that checks for junk mail or viruses.
RFC 2821 also requires that the DNS for the mail server point to an "A" DNS Resource Record (RR). No other record types can be used, which basically means your domain name must be a A record and not a CNAME record. (CNAMES are a type of alias, which points a second name at some other record, usually an A record.) If you are not controlling your own DNS, contact the ISP or service that is handling your DNS, and they should be able to check and correct this setting fairly quickly. If for some reason you cannot get this changed, your only option is to use your ISP MX mail server as your "smarthost", sending all mail there first.
For more information, you can read the full RFC on the Simple Mail Transport Protocol (SMTP) at http://www.ietf.org/rfc/rfc2821.txt , but the key statement is:
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.(RFC 2821 was introduced in April of 2001 as an updated version of RFC 821, which was introduced in August of 1982.)
There is an increasing number of Internet software programs that have recently started enforcing a rule that is over 20 years old. The characters used in domain names, such as bobsbox.com, are limited to a particular set. The first character of each section of the name (such as "bobsbox" or "com") must be a letter. The last letter of the section must be a letter or a numeric digit. The characters in the middle must be a letter, numeric digit OR a minus sign, also known as a dash "-". No other characters are allowed.
However, for many years Internet software, including key programs (like BIND) allowed the underline ("_") and some other disallowed characters to be used anyway, and this frequently caused interaction problems.
BIND (aka "named") is a universally-used program that runs on computers to handle Domain Name Service (DNS) queries. When you use a domain name instead of the IP address to refer to a given computer, several different computers worldwide will work to translate that domain name into an IP address, and virtually all of those systems are running the BIND package.
The latest major release of BIND (9) now enforces strict naming of domains, and underlines and other disallowed characters are rejected. Quite a few sites have had to change domain names like mail_1.bobsbox.com to mail-1.bobsbox.com or something similar that is valid. However, when they do this, they frequently forget to also reset the configuration of the mail software running on that computer, which continues to issue the greeting "mail_1.bobsbox.com" in the HELO or EHLO commands. Newer versions of SENDMAIL, SMAIL and EXIM will reject such mail, for two reasons. First, the name in the HELO/EHLO does not exactly match the sending computers domain name, and secondly, because of the use of the now-enforced illegal character "_" in the domain name that was stated.
Correcting this is typically an easy configuration adjustment, and if you see your mail rejected from some system for this reason, you must get the administrator of the local mail MX server that you are using to correct these easy-to-fix RFC compliancy issues.
You can refer to RFC 1035 at http://www.ietf.org/rfc/rfc1035.txt for more information on this rule, but the key statement on page 7 is:
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.(RFC 1035 was released in November of 1987.)
Some mail servers check the headers of the message for validity and other procedural errors. Messages can be rejected based on the content of the headers alone, never mind what was in the actual body of the message. Some examples are:
550 Mail is very old or from the distant future 550 Senders clock is broken - fix and resend 550 Date is not RFC2822 2.2/3/4 compliant 550 Message-ID is not RFC2822 2.2/3/4 compliant 550 Headers unacceptable - rejected NNNNN 550-5.7.1 [IPaddress] Our system has detected that this message is 550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please review 550 5.7.1 RFC 5322 specifications for more information. kxxxxxxxxxxxxxxx.183 - gsmtpIn these situations, an adjustment to the sending server software settings is usually required to remedy the problem. The errors could range from the use of characters that are not permitted in headers, to excessive header line length, or impossible values.
In general, common mail server software generates compliant headers, and so non-compliant headers are a strong indicator of the presence of mail whose headers are forged and that usually means they are produced by a virus or spamming software.
A related set of messages pertain to SMTP command sequences that are non-natural and their use suggest a brute-force attempt to find valid mailboxes or other abusive activity.
550 Too many RSETs
(Subsequent connections may also be blocked entirely.)
550 Sending system changed during session
550 Too many bad addresses
550 Too many errors from your IP
It is highly unlikely that standard mail server software would
trigger any of these rejection messages. If you are getting
any of these messages in response to sending the infrequent
e-mail, your computer likely has been compromised or infected
and is sending e-mails in addition to the ones you think you
are sending, OR perhaps you happened to be assigned the IP address
of a computer which just recently had those problems. If you
are running Windows, assume that your computer is the one with
problems, and start doing worm/virus/spyware/adware scans of your
system.
550 Blocked - see http://www.spamcop.net/bl.shtml?10.5.6.7
550 Mail handled by an open relay - visit http://someURLofaRBL
550 Administrative Prohibition - see http://someURLofaRBL
550 Rule is believed to be an open relay
550 SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM - Rejected from 10.5.6.7
550 SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
(This text is repeated until the sending software closes the SMTP TCP
connection and/or the sending software - or Windows - crashes due to
a buffer overflow condition)
550 Administrative prohibition exchange dynamic
550 sendmail dynamic ip address Domain of sender address not exists
550 sender IP address listed as being infected or compromised
550 sending mails with dynamic IP
550 SPAM == Business Suicide. All mail rejected coming from this address
due to spamming.
550 sendmail dynamic ip blocked isp
550 Your ISP won't address spam complaints so no mail is accepted from
that ISP or its customers.
550 dynamic mail rejected
550 mail rejected dynamic address
550 mail being rejected because of dynamic IP address
550 Your IP address appears to be dynamically assigned. Please smarthost
your mail though your ISP
550 cannot accept mail from dynamic mail server
550 Blocked for abuse. Please contact the administrator of your ISP or
sending mail service.
550 This message was rejected due to the current administrative policy by
the destination server.
550 This message was rejected due to the current administrative policy of
the destination server.
550 Access from ip address blocked
550 blocked
550 Appears to be dynamically assigned. Please smarthost your mail
through your Isp mail server
550 The sending IP address has recently sent junk mail, a virus, or mail
with falsified headers, is an open relay, is infected with a virus or
worm, is dynamically assigned with insufficient credentials, or is
controlled by an entity that will not address abuse issues. Send your
mail through your ISPs smarthost or some other route.
550 Mail from this IP address blocked due to DNS black list
550 This computer is currently blocked from sending messages
550 You are spamming or your computer is compromised or infected
550 RBL rejection
550 rbl restriction blacklisted
550 Message not sent - New domain not yet verified
554 Message not allowed - UP Email not accepted for policy reasons.
Please visit (some web page link) [number]
550 Rejected mail from address
550 Sender envelope address is locally blacklisted here.
550 If you think this is wrong get in touch with postmaster.
(One of these messages or a similar one may be returned during the
SMTP transfer, or the mail may be bounced later containing the message.)
In such situations, the mail server that you are trying to send the mail
to will refuse to accept mail from the sending server that appears on a RBL
list. Mail can likely be sent from another place, but until the RBL
entry is removed, communication between those two mail systems has ceased.
Some servers will accept mail for certain mailboxes regardless of what the RBL that is being tested has to say. For example, the RFCs dictate that the "postmaster" mailbox must always exist and must always accept mail for every domain, so that mailbox must not be restricted by a listing on a RBL. Reputable ISPs also allow all mail to reach their abuse-reporting mailboxes in all situations. Support group mailboxes may also accept mail regardless of what a RBL says. Further, some customers of that ISP may also have their mailboxes configured to receive mail regardless of what indications exist that suggest that the mail may be junk or undesirable mail.
If your mail is blocked by a RBL listing, the error message usually indicates the location of a web page where an explanation can be found about why this particular RBL block exists. That web site usually has instructions on how to get the RBL listing removed.
An IP address appears on some RBLs because of tests performed on the IP address that was attempting to send the mail, and those tests showed that the computer has been compromised or hacked, has been infected with a worm or virus, or allows third-party relaying (accidentally or by intent). In all of these situations, the security problem with the computer at that IP address must be completely corrected before the RBL listing will be removed. Most RBLs re-test on request, and if the problem has been corrected, that IP address will be removed from the list.
Another situation is cases where the IP address that is blocked was dynamically assigned, such as those assigned to dial-up customers, wireless Internet users, and some cable and DSL Internet users. Some ISPs simply have a policy of not accepting mail directly from dynamic IP addresses. Some RBLs exist that have identified (or been provided with) the blocks of IP addresses used for dynamic assignments, and they will not ever accept mail directly from these locations. If you use PPP, DHCP, PPPoA or PPPoE, or any wireless device, you are likely being assigned a dynamic IP address.
For this situation, the thing to do is to send always send your mail to the mail system at your ISP first, and let that system forward it to the destination. This will ensure that the mail will be accepted by these more-restrictive destinations.
If mail servers at the ISP itself are being blocked by a RBL, contact your ISP and let them know, although they have probably heard about it from other customers already. If the ISPs employees can not get the issue cleaned up, this likely means that the ISP is hosting spammers that they are not willing to dispose of, and until the spammers go away, the mail server IP addresses may remain on RBL lists. In these situations, you may be better off changing ISPs. Unfortunately, there are some ISPs that will refuse to dump a known spammer because they make so much money from having the spammer as their customer, even if it causes some of the less valuable individual subscribers to leave.
Because it is well-known that spammers create hundreds of new domain names every day knowing that they will be useless within hours, some mail systems now reject mail if the domain name mentioned in the mail is simply too new. Depending on the rules being used, a domain may be considered too new to be a trustworthy entity for weeks or even months after its creation date.
Usually in the case of sender verification, the bounced mail will indicate that the verification attempt failed. The only solution is to use your real working return address on mail you send to this more-selective mail server. For example, if you sent mail out with the "From:" address of "MegaSalesbob" or "REMOVEbob" instead of your real mailbox name of just "bob", that could cause sender verification to fail. Always use your real return address in e-mails if you want them delivered.
Because some mail systems accept all mail, including mail that is for non-existent mail boxes, sender verification systems will usually test to see if the other mail server returns accurate answers. It does this by starting to send mail to a mailbox address on the claimed source system that is extremely unlikely to exist. It then looks to see if that mail server rejects the made-up address or not. If the made-up address is rejected, then the original mail address is tested to see if it is accepted or rejected.
When a Sender Verification attempt fails, the message is usually never accepted by the destination system. It is rejected with messages like these:
550 Sender verify failed 550 sender verify rejected exim 550 verify validity 550 administrative prohibition "mailserver verify address" 550 message to verify they are valid 550 Sender verify failed - upgrade your firewall firmware or settings 550 Not sent - no reverse lookup 550 The destination mail system rejected your return address 550 Sender must exist 550 You must use a working From: address in your e-mail. 550 Domain not found 550 Sender-Rejected mdaemon 550 Sender address rejected: Blocked 550 Sending address not accepted due to spam filter 550 No Such User Here Sender Verify Failed 550 Rejecting spoofed messageNote that some systems now store and check a list of sender addresses with a past history of spamming or other e-mail abuse, and reject their mail without actually performing sender verification.
Getting upset about Sender Verify tests is about as pointless as sending nasty letters to remote ISPs claiming that your firewall is being "attacked" on port 53 with UDP packets by that other ISPs DNS server, when what you really have (and own) is a rather stupid firewall.
Here is how the "DNS Attack" (as the stupid firewall calls it) happens: One of your own users did a DNS query that asked that "attacking" server a question, but the answer took longer to come back than the stupid firewalls patience allowed for. The previously expected DNS answer is then considered an "attack" by the time it arrived because the firewall has forgotten that it was expected. The user who now did not get a good answer the first time (because the firewall blocked the slow response) will likely ask the question again, and the cycle may repeat. Obtain a better firewall or ignore this stupid message.
Back to Sender Verification. If the administrator of the sending mail server reviews the incoming mail logs, he or she will typically see one verification connection for each unique mailbox name referred to in mail being sent out to that distant server that is doing sender verification. After the validity of a given mailbox is established or refuted, the answer is cached by the receiving server, and the query should not be immediately repeated, even if more mails are sent between the same two individuals. In other words, if your customer "bob" sends "sam" at a distant server (that does sender verify) 200 messages in a day, you will likely see a few sender verifies throughout that day, an insignificant burden.
Another issue that surfaces with Sender Verify is that it will inadvertently uncover flaws or other problems in the mail server or proxy firewall operated by the sender. ClearPoint is one such firewall product known to not accept valid RFC 822 handshakes, and subsequently people behind that firewall will not be able to send mail to a system that performs Sender Verify, unless they use a return address not located at that firewall. (Getting a better firewall product is recommended.)
The use of sender verification is now common at most mail providers, because it has proven effective at stopping some junk mail sent from compromised systems that send mail that claims to be from addresses at legit mail systems, but the mailbox names are frequently made-up, so sender verification is able to spot these fake return addresses, and reject the mail entirely. The site that can be verified also will get fewer junk mail complaints from other companies.
In some cases, the From: address on the piece of spam you receive from a spammer contains the To: address that was just used on another piece of spam the spammer sent. That earlier address gets re-used on your mail because the previous piece of spam was accepted for that address, so it might pass a sender-verification test at your mail server. So rnixon gets junk mail supposedly from ljohnson, then jcarter gets junk mail supposedly from rnixon, then rreagan gets junk mail supposedly from jcarter, and so on.
By using a wide variety of stolen return (From:) addresses, the spammer also avoids any pattern matching that a given mail server might be using to catch junk mail. (If all the junk mail from a given spammer claimed to be from ima-idiot-spammer@spam-it-all.com, chances are most mail server operators would filter such messages.)
SPF is basically the next escalation in the sender verification battle. SPF strives to address only one issue, and that is to deny the spammer the ability to select any random (but known to work) e-mail address and stick it on the From: line of spam messages that is mailed to a mailbox at a SPF-protected mail system.
When SPF is being used, if a piece of mail that comes in saying it is from bob@bobsbox.com, the receiving mail system can consult a list that says that mail claiming to be from "bobsbox.com" can only have come from these specific IP addresses, and these addresses are typically just the mail servers at "bobsbox.com". If the IP address that the mail is coming from is not one on the SPF list, the mail is considered spam and is rejected. (Any Sender-verify, RBL, virus and content scan checks may still be done even if the mail gets past the SPF check.)
SPF has some obvious drawbacks. First, the real "bob" of "bobsbox.com" will not be able to send mail directly from the McDonalds WiFi system while at lunch and expect it to be delivered directly to any destination like he used to be able to do, because the receiving machine will correctly note that the dynamic IP address his laptop was assigned by McDonalds (or some other business providing Internet access to their customers) is not one of those listed as being part of "bobsbox.com", and so the mail is rejected by receiving systems using SPF. Unless the ISP lists every IP address they own, you also can not send mail direct from your dial-up, DSL or cable Internet connection. To get around this, "bob" will be required to always send the mail back to the "bobsbox.com" corporate mail server first, and then those systems can send the mail on to the destination. That might seen clunky, but it is simple and completely workable. However, a lot of people were not using "hot spot" mail capability in this way before now, and as SPF is adopted, these on-the-go mail senders will have to be taught that the old rules on best mail handling practices are now being enforced.
Note: The originating ISP - in this case, "bobsbox.com" - actually has to participate in SPF before SPF verification is performed by any receiving mail server on mail claiming to be from "bobsbox.com". Some ISPs and companies may believe they can simply ignore the SPF bandwagon and not list their mail-sending systems for their domain(s). At one time, a few major ISPs threatened to reject all mail from smaller ISPs that do not adopt SPF by a certain date, so "bobsbox.com" may not have much choice but to join the SPF bandwagon. Having all your customers suddenly unable to correspond with clients at "yahoo.com" or some other large destination is probably sufficiently strong black-mail to force use of this system, regardless of its shortcomings.
However, the spammers are not sitting still. They are busily registering IP addresses in the SPF strategy as well, including listing thousands IP addresses they do not actually control. These extra addresses are usually those of the 400 million (per a recent estimate) infected Windows computers out there that have back-doors installed that the spammers use now to send spam from, also known as zombies or 'bots. Once listed, the spammers plan to continue sending spam from these IP addresses just like they do now. For big-time spammers, SPF has simply become some extra paperwork to do up-front. In some cases, there are "pro-spam" ISPs (mainly in China, South Korea, Russia and Argentina that are listing all of their IP addresses (and any others the spammers request) as being part of their authorized mail-source domains.
As an indicator of how quickly SPF has been defeated by spammers, within three months of the first significant deployments of SPF, approximately 10% of spam was already coming from "SPF-listed" sources, a number that has rapidly increased, so the spammers already know how to work around this obstacle.
The response to that (and effectively the next escalation on this battle) is to add a RBL-like list that lists untrustworthy SPF listings, so that domains that are using SPF but are "cheating" can be blocked by domain, rather than individual IP address. However, spammers already change domains frequently - sometimes hourly - so re-registering the IP addresses of their spamming systems under a new domain under the SPF system is just a bit of extra effort they will have to go through, and probably will not slow them down much.
Since SPF is not and really cannot be a total solution to junk mail, it is pretty much doomed to be part of a perpetual arms race with the spammers, much like the mickey-mouse copy protection systems used on home video systems that slow down those who didn't simply buy the more expensive equipment that ignores the copy protection schemes. To date, SPF and other technical patches to SMTP mail to deter spammers have mainly managed to make mail transport more and more restrictive, only slightly bothering the professional spammer, but harming the innocent users of SMTP e-mail transport in the process.
[Copyright 2001,2002,2003,2004,2005,2006,2007,2008,2009,2012,2016 Frank Durda IV, All Rights Reserved. Mirroring of any material on this site in any form is expressly prohibited. The official web site for this material is: http://nemesis.lonestar.org Contact this address for use clearances: clearance at nemesis.lonestar.org Comments and queries to this address: web_reference at nemesis.lonestar.org]
Visit the nemesis.lonestar.org home page and index