SpamStopsHere Support Related Questions
From Greenview Wiki
- SpamStopsHere FAQ
- General Questions about Spam
- General Questions about SpamStopsHere
- SpamStopsHere Support Related Questions
Why is your service not blocking 98% of my unwanted email?
It's typical for a lot of spam to bypass our email servers for the first 72 hours after the MX record changes to activate our service have been completed, and then a small percentage after that. You can determine if an email message bypassed our service by reviewing the full Internet headers. Click on the link below for more information:
After using our service for about a week, we recommend optimizing your MX records, which helps prevent bypasses. This is mentioned in the Domain Activation email that you receive when you sign up under the section "IMPORTANT: STOPPING EVEN MORE SPAM - Optimal MX records". Although many people forget to make these changes, they are crucial for good results.
Some domains unfortunately get more bypasses than others, as everyone's spam problem is a little different. You might find that you will want to go ahead and optimize your MX records before a week is over or even set up a firewall to prevent some of these bypasses if you notice that the majority of the spam you are still receiving is bypassing our service. You can click on the link below for more information:
Although bypasses are the biggest problem, there are other situations that are typically identified when new users sign up and don't get what they expect.
- The user's "spam" problem was actually a virus problem, but they have not signed up for our anti-virus service. Unfortunately we can't block viruses in the same way that we block spam, as they are blocked with completely different methods.
- The user's "spam" problem was actually a problem with receiving bounce messages where a spammer/virus was forging the user's email address and sending email. We can't block bounce messages globally, as we can't determine which ones are in reply to emails you actually sent. It's not typically a good idea to block these important diagnostic messages anyway. However, you can create your own custom content filters to block these. Please see our FAQ article on this.
- The user is on some spammers' lists that are unique and are not sending spam to our spam traps. As a result, these spammers aren't in our database. Additionally, the user is not reporting this spam to us for analysis. If you can report the spam you are getting to the email address provided for this in your Domain Activation email, we can investigate these spammers and take proactive measures to make sure that you no longer receive spam from these spammers. Additionally, you may be getting multiple copies of the same spam that is not yet in our database. Most multiple copies of the same spam occur when a user has a "catch all" email alias that forwards email sent to multiple addresses to one inbox. Disabling your catchall email alias can help eliminate this.
- The user is on mailing lists from companies known to have good subscription policies and known to not be spammers, but have forgotten that they signed up, think that it is unsafe to do so, or was subscribed maliciously.
- SpamStopsHere's filters are correctly identifying the spam, but the user either has the spam being forwarded indirectly to their inbox using the FORWARD action, or is using the MODIFY SUBJECT action for the spam instead of a filter that would REJECT or DELETE the spam.
- The user has whitelisted the spam. We don't recommend whitelisting your domain name. Not only is the majority of your intradomain email not going to leave the server in order to go through our filters, but many spammers now adays are forging an email address at your domain to get past your filters based on whitelist entries like this.
Because we have such a low false positive rate, you're more likely to let through spam with a whitelist entry than you are to prevent us from accidentally blocking your sender's email. That's why we recommend that you only do this for the most important senders, where even if you receive spam from their address or IP address, that you need to get it. Unless your senders send you spam, you shouldn't need to whitelist them. That's why the whitelists are generally used to correct problems, not as a preventive measure.
Whitelists are typically used if you take advantage of optional or custom filters to enforce policies but need to make exceptions, then we recommend that you do whitelist the sender, but whitelists should be done in the following order to open the smallest hole possible:
- By IP address of the sender's mail server if possible.
- Otherwise by email address.
- Otherwise by domain.
We believe that if you can provide us with more information as to the nature of your spam problem, provide us samples of spam if they are not bypassing our service, or take some measures on your end to prevent bypasses, that we can bring you to the 95% or even 98% or better level of spam being blocked.
Why is my outgoing email being blocked by AOL, Yahoo, and Hotmail, etc?
If you are using SpamStopsHere's outgoing filtering service, no email should be blocked by AOL, Yahoo or Hotmail for DNS-related reasons, as our DNS is properly configured.
However, users who choose not to use our outgoing filtering service need to be particularly careful when configuring their DNS SPF records. Specifically, when removing your email server from your MX records (one of the last steps in configuring your SpamStopsHere service) it is important to remember that your SPF records should not include any servers listed in your MX records, as those servers will not be sending mail out for your domain (their job is to handle inbound mail, not outgoing mail). Instead, make sure that your SPF records list your actual outgoing email server, ensuring that it is authorized to send email for your domain.
General Information (Not using SpamStopsHere's outgoing filtering) .
The most common reason for AOL, Yahoo and Hotmail to block an organization's email is based on simple DNS configuration issues. These ISPs require that DNS be configured to ensure the following:
1. The public IP address that connects to the ISP's mailserver has a DNS PTR record. This is suggested by informational RFC 1912.
2. The hostname that your outgoing email server advertises in its SMTP HELO resolves. Required by section 3.6 of RFC 2821, which is on the standards track.
3. Email is coming from a mailserver authorized by the domain’s DNS SPF records to send email for the domain listed in the sender's email address. This assumes that the domain has SPF records. Discussed in experimental RFC 4408.
4. The domain listed in the sender's email address has DNS MX or A records that resolve. Required by section 3.6 of RFC 2821, which is on the standards track.
AOL has policies and procedures in place that allow them to blacklist your mailserver if more than 1:1000 email messages from your server are reported as spam by AOL users. It is very difficult if not impossible to be removed from this blacklist. If your organization sends bulk email, it is strongly suggested that you take advantage of AOL's feedback loop and follow SpamStopsHere’s recommendations.
Hotmail has a tendency to put outgoing email into the recipient's junk folder if you don't include the recipient's email address in the To: header. It is recommended that you ask your Hotmail newsletter subscribers to whitelist your sending email address.
The following three ISPs each have whitelist request methods and information for senders available at:
http://help.yahoo.com/help/us/mail/defer/
AOL, Yahoo and Hotmail don't make these checks, but some recipient mailservers make the following checks which are often used to try to block spam in a very error prone manner:
- Does the hostname in the HELO resolve to the public IP address making the connection? Not mentioned in any RFC.
- Does the hostname advertised in the HELO appear in the DNS MX records for the domain in the sender's email address? Not mentioned in any RFC.
- Does the IP address making the connection match the IP address of one of the mail exchangers listed in the DNS MX records for the domain in the sender's email address? Not mentioned in any RFC.
- Does the PTR record for the public IP address making the connection resolve to a hostname that resolves to the public IP address making the connection? Not mentioned in any RFC.
Therefore, when possible, please try to configure your mail system to satisfy the above four checks to maximize delivery.
What is the Tarpit filter (filter rule #17)?
If you let us know what email addresses at your domain are valid, we can provide a certain level of protection against directory harvesting attacks.
For example, if an email message is sent to 10 different email addresses at your domain, and at least three of them are invalid, we reject the remaining 7, even if they were to valid email addresses. These 7 email messages were "tarpitted". This helps prevent the spammer from determining which of the 10 email addresses may have been valid, as we report to the spammer that all of them are invalid.
Why are some of my messages tagged with "[Blacklisted Sender]" and "[Foreign Sender]"?
By default, the IP address based filters (Country Blocking and Real-Time Blacklists), are enabled for users. These two filters are described below:
The Country Blocking is static. If a sender's email is coming from an IP address in a foreign country that you are subscribed to for the Country Blocking feature, the message will be tagged with "[Foreign Sender]". It doesn't matter whether the message is spam or not. However, if it may be coming from a country that is known for sending a lot of spam. If you only have contacts in the United States, it's possible that these messages are unwanted, but the email did not trigger any of our spam filters. The tag is informational only and it may help you to determine whether to look at the message.
The third party Real-Time Blacklists are maintained by third parties. These blacklists are of IP addresses that were reported to have sent spam to their users. If a sender's email is coming from an IP address on one of the blacklists that you are subscribed to, the message will be tagged with "[Blacklisted Sender]". We don't maintain these blacklists, and you will want to contact the list maintainer in order to determine why one of your senders was listed. The status of an IP address being listed does change, and it doesn't require any changes on your end to get more of your legitimate or spam email tagged by this filter from one day to the next. It just depends on who you receive email from, and whether they're listed in the real-time blacklist that day. Therefore results will vary. It's possible that these messages are unwanted, but the email did not trigger any of our spam filters. The tag is informational only and it may help you to determine whether to look at the message.
Many organizations get listed in a real-time blacklist because a workstation on their network is sending spam. This can be the result of a virus infection, or simply a malicious spamming user, or unsound mailing list policies. Many ISPs such as AOL or Comcast could also have their email servers listed temporarily for the same reason, causing all email from that ISP to be tagged for awhile.
These filters typically will only identify less than 1% of your email. If you don't find these tags useful, you can disable them by unsubscribing from these filters in the SpamStopsHere Control Panel. Note that many anti-spam products only use these types of IP address based filters, and it used to be common to block messages identified by them. Due to their inaccuracy, we don't recommend DELETING or REJECTING messages caught by these filters, so there is no need to QUARANTINE (an Enterprise Edition feature) the messages or whitelist the sender. These types of filters should simply be used to provide additional information about the source of the email message.
If you receive spam to your inbox that contains this tag, please report it to the email address provided to you for reporting spam that was not properly identified.
Please note that our accuracy was rated #1 in the industry by Network Computing magazine without using these IP address based filters.
Why is my third party anti-spam product identifying spam that you are not?
If you are using an additional anti-spam product along with the SpamStopsHere service, there are typically two reasons why the third party filter may be identifying spam messages that SpamStopsHere did not identify as spam.
- The message may have bypassed the SpamStopsHere service altogether (the message did not even pass through our filters). Please click here for more information on bypasses.
- Many anti-spam products rate all (or most) messages as possibly being spam. Please make sure that your anti-spam product determined that the message was absolutely spam and not just 10-90% likely to be spam.
Many of these products that use Bayesian and other heuristics will determine that most of your email is spam, including legitimate email. In these cases it's normal for most of your email to be identified as spam, especially mail from new senders (potential new clients). We do not recommend simply marking all email from new potential clients as spam, and recommend that SpamStopsHere not be used with other anti-spam products, as you will just encounter more false positives. If our service is not blocking 98% of your spam, we're happy to work with you to resolve any problem. Please click here for a list of the most common causes when not receiving expected service levels.
Although it is true that Bayesian and other filters that use heuristics are occasionally able to guess that some types of email are possibly spam when SpamStopsHere did not, you will find that in the long run our filtering will be more accurate. Bayesian and other heuristic filters have different weaknesses than content based filtering, but you should find that the weaknesses inherent in content based filtering are more acceptable.
In addition, Bayesian and other heuristics typically only tag such messages as "possibly spam". This means that you will still have to review the messages, since it’s just a guess as to whether the message is actually spam. You don't want to miss any important emails because your software guessed that an email from a new client was 51% likely to be spam.
The type of filtering we do is the next generation in anti-spam filtering - we actually determine for certain that a message is either spam or is displaying characteristics reminiscent of a spammer. A respected independent reviewer, Ron Anderson (of Network Computing), reviewed the top 30 anti-spam products in the industry and rated ours #1 for accuracy.
Please also see our article on challenge/response systems.
How do I add an additional domain name to my account?
Until we add the feature to the control panel to allow you to add it yourself, you can have a domain name added to your account by opening an "Account Changes" ticket in the SpamStopsHere Control Panel. Please include the following:
- The domain name you wish to add
- The number of additional mailboxes that you need to subscribe to for the new domain name (in increments of 5 mailboxes)
Please see the pricing page to see how much additional you will be charged based on your request.
Spam being sent to my domain has increased, so the 1-2% of spam that you don't identify has increased. What's going on?
Many people believe that solving a spam problem can be accomplished simply by subscribing to an anti-spam service. However, it's typical for most domain owners to actually notice an increase in their spam problem as time goes on. Subscribing to an anti-spam service simply deals with that problem for you. Once you unsubscribe from the anti-spam service, you'll likely notice that you're getting even more spam than before.
Your spam problem doesn't go away simply by subscribing to an anti-spam service. If your anti-spam service blocks 99% of your spam, if the spam being sent to your domain doubles, you will notice that the amount of spam that reaches your inbox will double. The anti-spam service is still as accurate as it was before. Your domain is simply getting more spam.
There are steps that you can take to help slow down your increasing spam problem, and it is very important that you take these measures.
- Subscribe to your domain name registrar's privacy service so that you don't have to list a public email address in your domain's WHOIS information. It's more important to do this for new domain name registrations than for existing ones.
- Don't list any email addresses on your web site in plain text. Use a contact form, or hide the email address in an image (readable by humans but not by computers), and don't use a mailto hyperlink unless it's obfuscated by Javascript. The CAN-SPAM act of 2003 only makes it illegal for spammers to harvest email addresses from your web site if your web site includes a notice that you don't grant them permission to do so. The notice should read "The operator of this website or online service will not give, sell, or otherwise transfer addresses maintained to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages".
- Do not confirm your email address to spammers by viewing sourced images in their HTML emails or by being vulnerable to other embedded tracking methods.
- Do not confirm your email address by replying or trying to unsubscribe from spam. Instead, report the spam to the spammer's ISP.
- Be careful about who you give your email address to. Do not use your email address to enter sweepstakes, and tell others not to share your email address with free greeting card sites and other "email this to a friend" forms.
- When asked for your email address by a new organization, make up an email alias just for them. For example, if your email address is john@yourdomain.com, you're signing up for an account with Walmart, and they ask you for your email address, create an email alias of walmartjohn@yourdomain.com that forwards to your email account. Then give them that address. If you start getting spam sent to that address, not only do you know who sold your email address, but you can remove that email alias to stop the spam.
- Make sure that your email server has the capability to stop directory harvesting attacks. As a SpamStopsHere customer, if you take advantage of our Mailboxes List feature, we can do this for you.
Why do I get email that is bypassing your filters and sent directly to my email server?
The DNS MX (Mail eXchanger) records for your domain are what indicates to the public where to send email for your domain. If you continue to use the initial DNS MX records that we suggest you use, you will start to get spam that bypasses our service. In this example, yourdomain.com is your domain name.
IN MX 10 yourdomain-com.relay1a.spamh.com. IN MX 20 yourdomain-com.relay1b.spamh.com. IN MX 25 mail.yourdomain.com. IN MX 30 yourdomain-com.relay1c.spamh.com.
SMTP clients that send email to you are supposed to look up all of these MX records and send their email to the MX with the highest priority (lowest number). Only if it fails should they move on and try to deliver their email to the next lowest priority server. Notice that your DNS MX record is "sandwiched" between ours. The actual numbers listed in the priorities are irrelevant. The only relevant thing is the numerical order of the numbers.
However, professional spammers will look up all of the MX records for your domain, and instead of starting with the highest priority one, they'll either select an MX at random, or select the MX that isn't a known anti-spam service. This can result in them sending email for your domain directly to your email server instead of to us. Additionally, spammers tend to target the lowest priority MX record because these are often just "store and forward" email servers that queue email for the primary mail server and don't have any anti-spam system in place. You can determine if an email message bypassed our service by reviewing the Internet headers.
To prevent this, we recommend that you optimize your MX records by removing your email server from your DNS MX records.
IN MX 10 yourdomain-com.relay1a.spamh.com. IN MX 20 yourdomain-com.relay1b.spamh.com. IN MX 30 yourdomain-com.relay1c.spamh.com.
You still receive your email, because we don't look at your DNS MX records to determine where to send email after it is filtered. We use the "Customer Mailserver" setting in the SpamStopsHere Control Panel for your domain name to determine the email server that handles email for your domain.
Additionally, any backup mail exchangers can safely be removed from your MX records because SpamStopsHere's redundant mail exchangers now act as your backups.
This step is very important and is mentioned in the Domain Activation email that you receive when you first sign up. We recommend that you do this a few days after making the first DNS MX record changes. Although many people forget to make this change, it is very important that you follow up a few days later and ensure that it gets done.
When removing the DNS MX record for mail.yourdomain.com, it is very important to leave the A record (the record that resolves mail.yourdomain.com to an IP address) if you are using the name mail.yourdomain.com to connect to your email server to retrieve email, are using it to send email, or if you have us sending your email there.
There are three other reasons why spammers may not honor the MX record priority:
- The spammers that have your email address in their mailing list also have the IP address of your email server cached in their mailing list database. This saves them having to look up the MX records for the domain name when they want to send you email. Because they don't have to do this DNS query which can take a couple seconds, they can send spam about three times as fast. Even though you have signed up for our service and are using optimized DNS MX records, hiding your actual mail server's IP address from the public, the spammers may still have your mail server's IP address from before you signed up.
- The spammers that have your email address on their mailing list aren't looking up DNS MX records at all, but are just sending to the IP address that yourdomain.com resolves to without a hostname in front of it. You can sometimes prevent this by making sure that yourdomain.com doesn't resolve to the IP address of your email server, but perhaps to your web server instead.
- The spammers that have your email address on their mailing list aren't looking up DNS MX records at all, but are just sending to mail.yourdomain.com. You can sometimes prevent this by using a different name for your email server, and making sure that common names for your email server (smtp.yourdomain.com, mail.yourdomain.com, etc) do not resolve to the IP address of your email server.
This is all speculation though, as no spammers have come forward and told us exactly why they are not honoring the MX records and are sending their email directly to your email server.
Firewall
The best way to ensure that email can not bypass our service is by making sure that your actual email server is not listed in the DNS MX records for your domain, and then by firewalling your email server so that only our email servers can connect to it. Since all of your legitimate email will be relayed from our email servers and not from anywhere else on the Internet, you can prevent anyone else on the Internet from being able to directly connect to it. This forces all senders to honor the MX records. Please see the documentation for the Firewall feature of the SpamStopsHere Control Panel for more information.
What is the difference between an unwanted virus email and an unwanted bulk email message?
UBE (Unsolicited Bulk Email)/Spam is blocked by the anti-spam service, and viruses are blocked by the anti-virus service.
Beyond that, spam is blocked based on it coming from spammers or advertising known spammer contact methods. These blocking methods can't be used for viruses. Virus emails typically come from innocent but infected hosts and not spammers. Additionally, they don't advertise known spammer contact methods. Usually the only way to determine that a virus infected email is a virus (and hence, unwanted) is by determining whether it contains a virus. As a result, the only way to block virus infected emails is by scanning it for viruses with the anti-virus service.
As a result, although virus email messages may be unwanted, they are not considered spam, and can typically only be blocked by signing up for our anti-virus service.
It is common in the anti-spam/anti-virus industry that they are separate services. Anti-virus service is typically billed separately as it does require more server resources and licensing fees for anti-virus software must be recouped.
Why does somone trying to send me email get a "Domain of sender address does not exist" error?
That usually means that the sender's domain (the part after the "@" symbol) isn't capable of receiving email.
This error message usually will only occur if the nameservers for this domain are reachable and answering queries but clearly announce that the domain doesn't have any MX records and doesn't resolve to an IP address (NXDOMAIN).
This makes any bounce or reply messages impossible, and the sender's email address is considered invalid.
If the DNS servers are having temporary problems, and aren't answering for the domain, the message would only be delayed. It's only when the DNS servers for the domain authoritatively state that the domain can't receive email that one will get this message.
The sender should be specifying a valid email address when sending an email message. If the message doesn't require a reply (such as a Delivery Status Report), it should be sent from a null sender address. It is quite normal for recipient mail servers to reject messages if a reply can not be sent.
It is considered better to require the sender to correct any problems on their end and resend the message than to receive a message and not be able to reply to it.
This check is done prior to any whitelisting/filtering.
For how long do you queue my email messages, if my mail server is down?
Our servers will queue your email for up to 120 hours (5 days). The senders will get their first bounce message after the message has been in the queue for 4 hours, saying that the message has not yet been delivered but that we will keep trying.
If your mail server is going to be down for longer than 5 days, please contact us so that we can backup your queued mail so that it is not lost.
The default behavior is for the servers to try redelivering each message every 30 minutes. As a result, half an hour after your mail server is back up, you should have recevied all of your queued email.
There are two unique circumstances where your email will not be queued, because you have directed our mail server not to queue it:
- SMTP 5.x ERROR: Queing will result if your mail server is completey unavailable, or replying with a temporary SMTP (4.x) error. However, if your mail server is responding fine and someone has directed your mail server to reject a message at the SMTP level and tell our mail server to not try delivering the message again (5.x error), then this is seen as a permanent error. Our mail server will do what it's told and not try again, deleting the message from the queue. A Delivery Status Notification (DSN) will be "returned" to the sender. As a result, if you find that you have to "reinstall" your mail server, please ensure that it is fully configured and tested to accept email before putting it back online at the same IP address to prevent losing email once the mailserver goes back online.
- NXDOMAIN: Queing will result if you have specified a hostname as your Customer Mail Server under Mail Server Settings, and the hostname is temporarily not resolving. This happens when the authoritative nameservers for the domain are either completely unavailable, or replying with a temporary error. However, if the authoritative nameservers are responding fine, and someone has directed them to say that the hostname doesn't exist (NXDOMAIN), then this is seen as a permanent error. You have told the public that this hostname doesn't exist. As a result, our mail server will not continue trying to send anything there, resulting in any messages to this host being removed from the queue. A Delivery Status Notification will be "returned" to the sender.
In either of the above circumstances, our Email Continuity service will allow you to re-send the messages once your mail server is back online, as well as sending and receiving messages while your server is offline.
What characters are allowed when specifying custom REJECT messages?
Letters a through z, A through Z and spaces hyphens (-) periods (.) exclamation marks (!) and at symbols (@)
I've changed email hosting providers or my email server has changed, what do I need to do to use SpamStopsHere with these changes?
Using SpamStopsHere actually makes it easier to change your email server, or your email server's IP address.
When making any changes, make sure that you leave the SpamStopsHere load balancers listed in your domain's DNS MX records. This will ensure that mail sent to your domain continues to be delivered to the SpamStopsHere service.
You will also want to enable the Spool and Suspend Email feature within the SpamStopsHere control panel. This will ensure that your email is queued on our servers, and we do not attempt to deliver to a mailserver that is not currently online.
Once the new email service is configured (and tested) to accept email for your domain and users, simply change the "Customer Mailserver" setting in the SpamStopsHere Control Panel for your domain to the new email server. This is the setting that tells SpamStopsHere where to send your email after it is filtered. Changes take effect within 10 minutes. At this time you can disable the Spool and Suspend Email feature. Your email will now start to deliver to your new mailserver within 10-15 minutes.
If you have the "Customer Mailserver" set to an IP address and are just changing the IP address of your email server, you don't have to worry about DNS caching issues. You can simply change the "Customer Mailserver" setting to the new IP address and we will deliver your email to the new IP address within 10 minutes. No need to worry about your domain record's TTL (Time To Live).
Important note: If you have the "Customer Mailserver" set to a hostname and change the IP address that the hostname resolves to in your DNS (rather than changing the "Customer Mailserver" setting), you will encounter DNS caching issues. In this situation, our servers will continue to deliver email to the old IP address for the hostname for at least as long as your domain record's TTL or up to 72 hours.
Depending on your email transition strategy, changing email servers can be quite problematic, as your users may need to check their email on two different email servers during the transition. The SpamStopsHere service doesn't make this part any easier, and it can take quite a bit of planning on your part for a smooth transition to a new email server.
We recommend that you leave the SpamStopsHere load balancers in your domain's DNS MX records. Sometimes, however, when switching to an email hosting service that also administers your domain’s DNS, the new provider will make changes to your MX records. It is important to follow up with them to ensure that they keep SpamStopsHere’s load balancers in your domain's DNS MX records. If you should lose the DNS configuration, you can find the recommended DNS MX settings for your domain in the SpamStopsHere Control Panel under "View Recommended MX Records for your domain".
I lost or did not receive my domain activation email, how can I retrieve this information?
It's possible that the email was never sent because the domain wasn't added successfully to our system. Please send us an email at our support address letting us know that you didn't get the email and also the email address that you expected it to be mailed to. That way we can investigate any problem and send/resend the domain activation email to you.
I received a spam that made it through your filters, what can I do to block it?
Please don't try to block it.
There is a personal blacklist in the Control Panel, but please do not use this to block any bulk spam that is making it past our filters. That's our job. Instead, send a plain text message including the complete headers and message source of the bulk spam to the email address specified for this purpose in your Domain Activation email. That will allow us to investigate why the email made it past our filters and find the best way to prevent it from happening again for not only you, but for the rest of our customers.
More information on the personal blacklist and what it should be used for is in the help file for the Control Panel, available after logging into it.
Why do some messages say that they're to/from "invalid" or someone at one of Greenview Data's domains?
Our software requires "To:" and "From:" headers in email messages to be processed properly. Because some messages sent to lists or via carbon copy won't have this header, our software will add one containing the server's name (for instance youremail@server.spamh.com). This is normal and just means that the email message was missing a header when we processed it. This is to satisfy SMTP requirements outlined in RFC 2821, as described below:
3.8.4 Other Header Fields in Gatewaying
The gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail. In particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC 822 syntax, MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies. The translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field (or other fields) of the RFC 822 message.
How do I see the route of an email in the headers?
The routing of the email section is reasonably straightforward if you keep in mind that they are backwards.
- Look for lines in the headers that say "Received: from".
- Look for the last "Received: from" line and read upwards.
For instance, let’s assume we’re tracing an email with the following headers:
Received: from unknown (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com with SMTP; 13 Feb 2009 23:23:29 +0200 Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNSS7000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Feb 2009 16:23:28 -0500 Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNQgX009122 for ; Fri, 13 Feb 2009 16:23:26 -0500 Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 21:23:21 +0000
When read from bottom to top says it went from 10.0.0.100 to mail.sendingdomain.com in the first line: “Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1])”
- From mail.sendingdomain.com to inbound.spamstopshere.com in the second line: “Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com “
- From inbound.spamstopshere.com to outbound.spamstopshere.com in the third line: “Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com”
- And finally it's delivered from outbound.spamstopshere.com to mail.MyDomain.com in the last (topmost) line: “Received: from unknown (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com”
Please see the supplemental FAQ How do I determine delays in my email via the message headers for additional information.
How do I determine delays in my email via the message headers?.
If we understand reading the route of the email in the headers it's easy to see where any delays might have occurred.
Each “Received: from” line will have a corresponding timestamp. Since email (and the internet in general) is global, the timestamps will frequently include GMT values to indicate what time zone the server is in. The timestamps are added by the recipient server, so if it says “Received: from some.server.com by my.mailserver.com 13 Feb 2009 24:53:29 +0200”, the timestamp is my.mailserver.com’s time.
In the below headers I have included a delay. Can you see which line has the delay? Hint: when the time zones are different, often you can simply check the minute field to look for a discrepancy instead of adding/subtracting the GMT values for each one.
Received: from outbound.spamstopshere.com (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com with SMTP; 13 Feb 2009 24:53:29 +0200 Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNSS7000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Feb 2009 16:23:28 -0500 Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNQgX009122 for ; Fri, 13 Feb 2009 16:23:26 -0500 Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 21:23:21 +0000
It’s the top line, or last “hop” in the email. Now, how do I troubleshoot the issue?
You might have noticed that each intermediary server is listed twice in the headers. When the server receives the message it says “by some.server.com” and then when it sends it on it says “Received: from some.server.com” in the next line. Often this is enough to tell where the delay occurred. If a server accepted the message and didn’t deliver it for many minutes, hours, days, etc. it frequently indicates that the recipient’s mail server was unavailable, deferring connections or “greylisting” the sending server. In that case, the logs you’ll want to read are on the recipient’s mail server (or possibly their firewall especially if it’s a connection issue or if it has a MTA built in). If this server does not have pertinent log files, then contact the sending server’s administrator to see if their logs show any additional information.
Sometimes the sending server may have issues sending an email that are outside of the recipient mail server’s control. A few examples would be retrieving the DNS information of the domain or recipient server, issues with connectivity or specific routing due to ISP issues, or any number of other issues. In these situations you’ll have to contact the sending server to determine the issue. Because the message never left the sending server, there will not be any logs on the recipient mail server. This is often the best place to start when troubleshooting home built or custom email applications such as bulk mailing software/vendors, website forms etc.
