Notice regarding e-mail forwarders
Lately we have been experiencing problems with user's and their e-mail forwarders. The problem comes about because the server that the user is forwarding the e-mails to is rejecting the messages for various reasons. This has a result of filling up the mail queue on our server. The mail queue is where messages are stored on the server before they are delivered. The mail server runs through the queue every so often (usually every hour) and attempts to deliver messages that are in the queue. As the queue gets larger and larger, it takes more and more resources to run through the queue. Also, as the queue becomes larger, the time it takes for queue run to complete, becomes longer. This basically means that as the mail queue grows larger, overall server performance starts to degrade. Ideally, you would like to have an empty mail queue so that the mail server does not have to hold messages and do queue runs to take up server resources.
The issues involving e-mail forwarders have a lot to do with the spam that the server receives and then later forwards that to the e-mail address you are forwarding to. Consider the following image:
The main highlight of this article is that if you are forwarding mail off of the server you may be contributing to the ongoing spam problem. This may come across as being harsh, but this is also the truth of the matter. By forwarding mail off of the server, our server acts as a middle man, and all messages that are forwarded from our server on to their destination will appear to come from our server. This includes spam messages that are sent to your forwarded addresses. This leads to blacklisting and other problems. For example, if you have email@example.com forwarding to firstname.lastname@example.org, then Yahoo will block our server because too much spam is being sent to email@example.com and then on to firstname.lastname@example.org. Then whenever someone legitimately needs to write to email@example.com, that message will not be accepted by Yahoo because of the block on the server. There is very little that we can do, short of discouraging e-mail forwarders to be set up. This is a problem that is only going to get worse if e-mail is continued to be forwarded off of the server. I know this may seem harsh, but its also the reality of the situation.
Further, if the server becomes blacklisted by a remote mail server that you are forwarding your mail to, then you will not receive any of the e-mail that is being forwarded to this destination. This means that if the server becomes blacklisted due to forwarders set up on your account, then no mail from the server to that destination will reach the destination, including direct e-mails and forwarded e-mail. This also means that if you are forwarding your mail off of the server one of these blocks may already be in place and you may not be receiving all of your e-mail.
The three entities to notice are:
To explain what happens when you receive a spam message to an e-mail address that uses a forwarder, the spam message is sent from the Internet to Our Server. The mail service on Our Server then forwards that e-mail message to the Remote SMTP Server of wherever you have your forwarder set up to go. However, it is becoming increasingly likely that the Remote SMTP Server will reject the message. The following is a more detailed explanation.
- Internet - This is just the Internet, the collection of servers that exist through the entire network that is the Internet.
- Our Server - This is the server that your account is being hosted on by us. Where your web presence exists.
- Remote SMTP Server - This is where you are forwarding your e-mail to. Examples may include hotmail.com, aol.com, or your ISP.
When a spammer sends a spam message they usually use a fake e-mail address to send the message. This is because the spammer does not want to receive the bounced messages and does not want to identify who they really are. This is what you may consider a flaw in the SMTP system, but this is just the way the SMTP protocol was written and the issues inside the SMTP system go beyond the scope of our services so there really isn't anything we can do concerning this. So in short, a spam message set of headers might look like:
From: Address that does not exist
When the spammer sends this message, the message is sent to an e-mail address of a domain name that is set up on your account and reaches Our Server. Our mail server then looks up to see what to do with the message. Our mail server will do one of three things, it will either discard the message, deliver it locally, or forward it on to a Remote SMTP Server. In the case of using e-mail forwarders, the mail server forwards the message the Remote SMTP Server that is handling your forwarding address you have listed.
To: An e-mail address you have setup as a forwarder on Our Server
This is where the Remote SMTP Server is rejecting the e-mail. Why the Remote SMTP Server is rejecting the message really depends on that specific SMTP server. You may have received an e-mail from our support department concerning some forwarders and it may include the rejection error from the Remote SMTP Server. Because the Remote SMTP Server is rejecting the message, then the message is sent back to Our Server where a discard message is created. Our Server then tries to send this discarded message back to the original sender, but that message will never go out because the original sender (the spammer) used an e-mail address that does not exist. Because the message is never sent back to the original sender, the message just sits in our queue, trying to be sent. This in effect fills up our mail queue.
It is likely that the majority of the Remote SMTP Servers are rejecting the mail because of the high volume of spam they are receiving. These spam messages are not originating from Our Server, but the Remote SMTP Server is seeing the messages as being sent from Our Server. Consider the following images:
This is how Our Server sees the message
This is how the Remote SMTP Server sees the message
When the Remote SMTP Server receives the spam message, they see the message as being sent from Our Server. This is both true and false. The spam message is being sent by Our Server, but it is not originating from Our Server. However, the Remote SMTP Server does not know this and there isn't anyway for it to know. This can result in Our Server being blocked by many different Remote SMTP Servers just because our users have e-mail forwarders set up to forward their e-mail, including their spam, to these Remote SMTP Servers.
Really the best solution is to just not use forwarders at all, unless you are forwarding to addresses inside your account. Using e-mail boxes set up on Our Server is the best solution. By having your e-mail come to Our Server and delivered locally then you are bypassing the forwarding option. This is the best solution because if you are forwarding your e-mail then you are at the mercy of how the Remote SMTP Server will handle the forwarded message. If the Remote SMTP Server considers a specific message as spam, they may discard it and you will not receive it. If too much spam comes from Our Server (through forwarders) to their server, they may decide to block Our Server, in which case you will not receive any e-mail. By setting up e-mail accounts on Our Server and not using the forwarding option, then you are much more likely to receive messages sent to you, you will just need to check the e-mail account on Our Server. For information about setting up e-mail accounts as mailboxes on our server, please see our manual entry
The next best solution is to just use your third party e-mail address directly. For example, if you have a hotmail.com account, and that is the only e-mail address you are checking, then you should advertise this hotmail.com e-mail address as the address to write to contact you. Instead of creating an e-mail forwarder for @yourdomain.com that forwards to this hotmail.com address, just use the hotmail.com address directly. This may not have the professional look of using your domain name, but it is the only way to insure that you receive all of your e-mail. If you wish to use an e-mail address that is @yourdomain.com, then you should create an actual e-mail account for that e-mail address in your control panel.
Other solutions include only using Remote SMTP Server forwarding addresses that you know will receive all e-mail sent to it. You would need to contact the administrators of that server and have them whitelist our server or otherwise insure that all messages sent from our server are accepted by their mail server and delivered properly. This is an action that most SMTP administrators will not comply with and for good reason. By agreeing to accept all mail from our server they will be increasing their load on their mail server. The administrators of the Remote SMTP Server will probably want some assurance that our server will not directly send them spam. This is an assurance that we just cannot make. While we have a very strict anti-spam policy and we move very quickly to stop any type of spamming activity, spamming is generally a hindsight procedure. Generally, if spammers do get on our servers and use them to send out spam, we do not know about it until they have already sent spam messages. We are constantly monitoring the e-mail traffic that is being sent out, but we just cannot guarantee that any server on the Internet will not receive spam from our servers. This, along with the fact the spam is not truly defined (one administrator may view a message as spam, while another may not view the message as spam) we do not accept inquiries to be whitelisted by the major e-mail services (such as hotmail.com, aol.com, yahoo.com, etc). You may have better luck with a smaller ISP whitelisting our server, but this is a decision that they would need to make on their own. We feel that the better solution is to set up e-mail accounts, rather than using a forwarder.
Another solution that we can make is to be more aggressive in our use of RBL (Real-time Black List). An RBL is a service that will list potential spammer's addresses, IPs, servers, or other ways of identifying a spam message. When using an RBL on Our Server a message is scanned before it reaches the mail queue. If any of the headers in the message match any of the defined headers in the published RBL list, then that message is rejected and never reaches our mail queue. We do use some limited RBLs on some of our servers, but by using RBLs we run the risk that you may not receive legitimate messages. This may be an action that we eventually have to take, even though you may lose some legitimate messages. Because of the fact that these lists can sometimes be questionable, we are not very aggressive in our use of RBLs and we just do not view it as a complete solution but more as a co-solution when combined with other preventive measures.
Currently we have been experiencing a lot of problem regarding these above issues and AOL. When messages are forwarded to AOL addresses and the AOL user uses the Report Spam button, then this moves to having Our Server blocked by AOL. This is because as users click the Report Spam button, counters increment telling the AOL systems how much spam has been received from Our Server. Once this counter reaches a certain limit, Our Server becomes blocked. I am sure there are similar systems in place with e-mail services such as Yahoo! and Hotmail, but to my knowledge they do not move (at least not as fast as AOL) to block Our Server, but instead force those messages into their service's Bulk or Junk mailbox.
In short, if you are using e-mail forwarders on your account to forward e-mail to Remote SMTP Servers, please consider using actual e-mail accounts instead of using e-mail forwarders. If you are using e-mail forwarders to forward e-mails within your account, then there should be no problems because there are no Remote SMTP Servers involved in the transaction. If you are using your default/catchall account to forward to a Remote SMTP Server then you are greatly encouraged to change this. Information pertaining to your account's default/catchall account is available here.