As many of you are aware, we are experiencing major delays in delivering mail to yahoo.com addresses, verizon.net addresses, and some other large providers. We are not alone in this problem, but we've been doing a lot of investigation into it and believe we have an explanation, if not yet a solution.

First, as you can see from this post on Open Tech Support, other people are struggling with the same issue. Basically, if a large provider feels that they're receiving a lot of spam from a given server, they block that server automatically for a brief period, during which time no mail can be delivered from that server to that provider.

What seems to have changed recently is how those services are deciding to block the sending server. Many of our customers use mail forwarding to handle their mail -- rather than using mailboxes on our server, they set up a forwarder that directs their mail to a mailbox on another server. For instance, if we host the domain "foo.com," bob@foo.com may be configured to forward to bob@yahoo.com.

Unfortunately, new schemes used to stop spam are breaking traditional methods of forwarding. Some of them are, as described in the above post, checking the sender's info to make sure that the return address is valid. Unfortunately, a failure on the part of the original sender's server to respond in a timely fashion, or to respond at all, or if it turns out the address is actually forged, results in our server being blocked -- not the original sender's -- because as far as the receiving server is concerned, we're the ones sending the bad mail. We're not, of course; we're simply acting as a middleman. But there's no way for them to tell that with the traditional method of forwarding.

Another method some servers are using is called "SPF," which attempts to identify whether a given server actually has permission to send mail for a given domain. So if joe@bar.com sends mail to bob@foo.com, which is then forwarded to bob@yahoo.com, Yahoo's mail server will check the SPF records to see if our mail server is authorized to send mail from the bar.com domain. Which, of course, it isn't, because it's only acting as a forwarder -- so they decide we're spamming and block our server for a while.

There is a way around this problem, which is to use something called "SRS," or Sender Rewrite Scheme. This rewrites the return path of the message so that the destination server can tell that it has been forwarded, and handle it appropriately. The problem is that SRS is extremely new, and has not been implemented in many mail servers yet -- including CommuniGate Pro, the one we use.

We've upgraded to the latest version of CommuniGate, and are investigating methods of working around this problem, but ultimately, it won't be entirely solved until SRS is implemented in CommuniGate. Because of the serious nature of the problem, we will consider (very carefully) installing a beta version of the software when it supports this feature. We will update this space when we have more info.

In the meantime, you can help: wherever possible, create mailboxes and collect your mail from our server instead of forwarding it to other providers. The less mail that is forwarded, the fewer blocks will be triggered, and the more mail will be successfully delivered to these providers. Please feel free to open a trouble ticket or call if you have any questions.