Sent e-mail blocked by recipient, for various reasons
Email sent is no guarantee that it will be accepted. Emails can be rejected by the local spam policy running at the recipient's mailserver. This FAQ attempts to help troubleshoot the problem, however with so many possible variables this can only be understood through examples. If you are not certain or this FAQ uses unfamiliar terms, TZO customers may contact TZO Support for assistance.
This description covers a broad range of examples, each with their own underlying cause (and solution). When appropriate, examples will be specific (specific RBLs, specific mailserver hosts such as TZO OMR, etc). Otherwise, these are general email FAQs which could apply to any mailserver.
This overview applies to mail you send regardless of whose server it is (self hosted email vs. TZO hosting of email). For readability purposes, this FAQ will link out to another FAQ when regarding additional details and the TZO mailservers (such as TZO Outbound Mail Relay, or OMR).
- Recipient's content filtering (Spamassassin, etc.)
- Recipient's 'RBL' checking (Spamhaus, Spamcop, Barracuda etc.)
- Improper use of Spamhaus Zen or Spamhaus PBL (deep header parsing)
Recipient's content filtering
Recipient's content filtering will 'scan' the contents of your message, then reject it. Typically the rejection looks like this:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
someone@example.com
SMTP error from remote mail server after end of DATA:
host mail2.example.com [1.2.3.4]:
554 Service unavailable; Looks like spam.
You might not get specific information about the rejection without somehow contacting the recipient (or recipient's admin), but there are some clues here. The message was rejected AFTER "end of data", which suggests "content filtering" - something in your message.
When content filters are suspected, try the following test emails:
- PLAIN TEXT (not HTML, not Word-formatted) message formatting
(Perhaps their filters apply a large spam score for this, when a 'low' spam score is more commonplace)
- Disable your "default Signature" in email.
(Your signature may contain text, URLs and images. Images could be scored as such, and text in the signature may contain HTML, or a domain name. Some spam rules add 'points' for domain names, especially newly-registered domains.)
- Users on the recipient's server have flagged your messages as Spam (unwanted) email
(If you are conducting a 'mailing' with addresses you 'purchased' somewhere, please note this is considered Spamming and a violation of TZO usage guidelines. Mailings are OK if they use verified opt-in subscription methods. This applies to both TZO-router email such as OMR, and also self-hosted email)
- Try another email client
(Just as a test, try sending a simple test email to the recipient using Microsoft Outlook or Mozilla Thunderbird. This may demonstrate a problem in the original mailer client's message headers, or a problem in the recipient's spam filters
Other possible causes exist, but these suggestions cover the majority of problems occurring during the content phase of email delivery.
Recipient server peforming 'RBL' (blacklist) checking
'RBL' checks look at mailserver IP addresses, and then look up the reputation of those IP(s) using 'RBL' (or 'DNSBL') servers which track such reputations. The RBL issues a response if the IP address is 'listed', and that response indicates a qualifying reason for the listing. Typically these IP checks are only done against the IP address directly involved in the current connection (not Received header parsing, see last section).
All TZO servers which route email are monitored against the standard RBLs (including Spamhaus and SpamCop) to ensure such a problem is never overlooked. TZO also maintains usage conditions and spam monitoring to protect against any spam issues from ever becoming escalated to the point of an RBL listing. If you route your email through TZO, you can rest easy that we are keeping the bad guys off our servers.
RBL listing which appears after HELO, MAIL FROM, or RCPT TO
HELO, MAIL FROM, or RCPT TO are early steps in email delivery, taking place before any message "content" or any message "headers" have been sent. Sometimes the error message contains a link which can be followed for more information, for example:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
someone@example.com
SMTP error from remote mail server after RCPT TO:
host mail.example.com [1.2.3.4]:
554 Service unavailable; Client host [the.sending.server] blocked by
zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=[IP address of the.sending.server]
In this case the message was 'self-hosted' email (it showed the IP address of your sending server), and the recipient chooses to block using Spamhaus. The most likely reason you are listed in this case is you are sending email from an a "dynamic" or "non-commercial" IP address which will generate a Spamhaus PBL listing. As the sender admin, you should always research the listing, as a more serious listing on the Spamhaus XBL listing would suggest a virus or network security issue at your location.
If your IP was listed on the Spamhaus PBL, most of the time it means your ISP does not want your IP sending mail, and they use a virtual block in the PBL database instead of physically blocking your outbound port 25. Your solution to this is to route your mailserver's outgoing email 'through' a valid mailserver, which is a practice called "smarthosting". You can get this service from TZO by ordering our 'OMR' service, or your ISP may allow you to conduct authenticated SMTP through their mailservers. Either approach will cause your mail connections to be 'seen' as coming from a known and allowable mailserver IP address.
RBLs must be used according to the RBL provider guidelines and FAQs, as not doing so can jeopardize valid incoming email email (this is more of a point for the admin of the recipient mailserver). Some RBLs become unmaintained and should NOT be used (ordb.org usage still causes people to lose email).
Other RBLs are good but can be mis-used. Spamhaus Zen is a well-designed and maintained RBL, but can be misused if an admin overlooks the Spamhaus Zen Usage Guidelines and FAQ and use it with 'deep inspection' or 'header parsing'. This will Spamhaus state it should only be used on the incoming (socket) connection and NOT ,
RBL listing which appears after 'end of DATA'
'after end of DATA' means that the entire message was sent, but was rejected by the recipient policy. This type of RBL rejection requires a bit more work to confirm, but can be done.
Sometimes the error message contains a link which can be followed for more information, for example:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
someone@example.com
SMTP error from remote mail server after RCPT TO:
host mail.example.com [1.2.3.4]:
554 Service unavailable; Client host [the.sending.server] blocked by
xbl.spamhaus.org; http://www.spamhaus.org/query/bl?ip=[IP address of the.sending.server]
The way to diagnose a RBL block "after end of DATA" is to carefully check rejection message - the detected "Client host" and any IP address shown in the URL, and verify BOTH of these addresses at the website of the blocklist.
The above example used xbl.spamhaus.org, but it advice is generic to any RBL. Usually the rejection message will contain a URL for more information. For example, the CBL will provide a URL that when clicked will document if the sending server was an 'open relay', infected with a virus somehow, or otherwise sending spam in some respect.
A review of RBLs and intended use is outside the scope of this FAQ, however Al Iverson's blog at http://www.dnsbl.com/ is a great resource). RBL providers typically document how and (most importantly) how not to use their RBL services, which leads to the next section...
Improper use of Spamhaus Zen or Spamhaus PBL (deep header parsing)
This is a problem we occasionally see with email forwarded through TZO OMR: the recipient email server is using the Spamhaus PBL (or Spamhaus Zen) RBL to test not just the mail connection (SMTP adddress) of the mail connection itself - but they are also testing all IP addresses found in the message's Received: header trail.
Using the Spamhaus Zen or PBL lists with 'header parsing' is incorrect, according to Spamhaus documentation:
- "Caution: Do not use ZEN in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers."
-- source: http://www.spamhaus.org/zen/
- "Caution: ...Do not use PBL in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers."
-- source: http://www.spamhaus.org/pbl/
- "The PBL concept is to include only IP address ranges that would never directly send email."
-- source: http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20PBL#188
- "WARNING! Some post-delivery filters use "full Received line traversal" or "deep parsing", where the filter reads all the IPs in the Received lines. Legitimate users, correctly sending good mail out through their ISP's smarthost, will have PBL-listed IPs show up in the first (lowest) Received header where their ISP picks it up. Such mail should not be blocked! So, you should tell your filters to stop comparing IPs against PBL at the IP which hands off to your mail server! That last hand-off IP is the one which PBL is designed to check. If you cannot configure your filters that way, then do not use PBL to filter your mail. Instead, you may wish to use sbl-xbl.spamhaus.org, but even that may have unacceptable "false positive" filtering, for example when a an exploited end-user machine sends legitimate mail out through the ISP smarthost, or when the dynamic assignment changes the IP to an uninfected machine. Do not use PBL or XBL if you do not understand the issues of "deep parsing"."
[TZO FAQ edit: Emphasis added only]
-- source: http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20PBL#185
Most likely the email error or bounce will read as follows:
554 Service unavailable; Client host [omr.tzo.com] blocked by
zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=[the ORIGINAL SENDER IP not the OMR IP]
In the above example, the error message proves that the recipient site is actually using mis-using Zen (or the PBL): The IP address shown in the URL (ORIGINAL SENDER IP) can only have come from the headers, and this is easy to confirm. Additionally, the IP address omr.tzo.com uses is actually 209.67.242.151 (and this IP address is not listed on any of the Spamhaus lists).
Please note this is not a problem with TZO OMR, nor is it a problem with Spamhaus Zen or the PBL.
A site with this misconfiguration may be challenging to contact from any mailserver. They may be getting just enough email to not be aware of a problem. If you manage to contact someone at the site, while TZO can not provide direct support you may feel free to reference this FAQ http://helpdesk.tzo.com/cgi-bin/kb.cgi?view=360#spamhauspbl-and-header-parsing
All documentation for this section can be found on the Spamhaus website. Additional searching Google will uncover additional third-party FAQs and articles on header parsing with PBL/Zen.