Having Trouble Sending Mail?

[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]
Last updated 26-Jun-2016

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:

If these are not the cause of the mail delivery failure, then it could be due to a configuration problem with the mail server that you are using to send the mail to that destination in the first place, OR your mail or sending system is being blocked due to previous incidents of sending junk mail or other abusive messages. Read the returned messages carefully as they almost always will state the type of problem, although the reason given might be very general.

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.

Sending mail server does not correctly identify itself

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
(RFC 2821 was introduced in April of 2001 as an updated version of RFC 821, which was introduced in August of 1982.)

Sending mail server has an invalid character in the announced name

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.)

Sending mail server has sent non-compliant headers or performed an irregular SMTP handshake

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 - gsmtp

In 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.

Mail Blocked due to Junk Mail Controls

RBL Blocks

The following error messages and ones with similar wordings indicate that the server that you are attempting to send mail to is referencing one or more Real-time Black Lists, and that the IP address you are sending the mail from currently appears on at least the list that is mentioned.
  550 Blocked - see http://www.spamcop.net/bl.shtml?

  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


      (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.

Sender Verification

Some mail servers now attempt to confirm the sender of a given piece of mail by verifying that the From: address provided is a real one. For example, if you send a piece of mail claiming to be "From: bob@someisp.com", and you send that mail to "sam@someotherisp.com", the mail servers at "someotherisp.com", may contact the servers at "someisp.com", to confirm that "bob" really is a valid mailbox there. If the return address proves to be false, the mail may not be accepted by the "someotherisp.com" servers.

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 message
Note 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.

A note to Administrators about Sender Verify - It is NOT an attack

Sender verification has been around almost ten years, and yet a number of system administrators (novice and experienced) continue to mistake the sender verification tests performed on their servers (in response to a piece of mail that their own server is trying to send out at that very moment) as being some sort of security breach, hacker attack, door knob turner, etc, when it is nothing more than a server receiving mail (mail sometimes about to come from the very computer now being tested) that is trying to verify that the mail comes from the place it claims to be from. Administrators, please do not waste the time of the distant ISP complaining about SMTP "attacks", as that is not what they are. Your mail servers own logs should show an outbound mail delivery attempt at the same time the "test" inbound connection occurred.

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.


One of the obvious results of starting to do Sender Verification on many of the larger ISPs was that spammers are now unable to just make up fake From: e-mail addresses for the spam messages they send. So, the spammers simply started using the e-mail addresses of real mailboxes for the return address. Of course, they are not using their own working e-mail addresses. Instead, they use addresses that they are sending the spam to as From: addresses as well. So instead of having obviously fake names on the spam, the spam now has the e-mail addresses of innocent companies and individuals whose addresses the spammers obtained from somewhere, addresses that the spammer believes to be working e-mail addresses, and probably also sent or will send the same spam message to at some point.

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.

Other Junk Mail Detection

There are at least a dozen of other methods for detecting junk mail at the mail server level, and any given mail server may employ none or a variety of them. If only certain pieces of mail are being bounced, it probably indicates that those specific pieces of mail are triggering the junk mail detection system and are being rejected. The methods used to detect junk mail are usually proprietary information, and if you contact the ISP where the mail server is that will not accept your mail, they probably will not tell you what they do to detect junk mail. However, they should accept a sample of the mail that was improperly rejected, and either correct the problem with their system or tell you what you need to adjust in your messages to allow them to pass safely.

[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

Valid HTML 4.01!