SPF prohibits pre-delivery forwarding


Well duh.

Anyone who reads that title and immediately knows what it means will find this post to be verbose – since I sum up the entire thing with those words.

“Back in the day…” when I was a partner at FiestaNet, one of the services we offered was something we called “Exchange Relay”. This was in the mid-late-90’s when dedicated Internet connections were still too expensive for many small businesses. Companies with Exchange 5.0 and 5.5 servers were primarily using them for internal e-mail, and tended to have separate external e-mail. We saw this as an opportunity.

As opposed to trying to sell a 5 person office a fractional t-1, or maybe ISDN, we sold them dialup. Why dialup, you ask? Wasn’t that horrible? Well, it was, and we occasionally sold bonded dialup to mitigate that somewhat, but what made our dialup special was we also provided a static IP address.

Companies could use their Exchange server for internal mail – and if someone sent a message out to the Internet, it would dial up and send it out over the phone line. If there were no outbound messages, it would dial out at predefined intervals and download anything incoming queued by ETRN.

We got quite a bit of business out of it. We provided companies that had an Exchange server with a method to use it for e-mail without added the expense of dedicated connectivity. Most ISPs at that time were very anti-Microsoft and either couldn’t or wouldn’t provide assistance to an Exchange customer. We, on the other hand provided Exchange support. If a customer had Exchange installed we could walk them through the configuration and initial connection over the phone. They usually found this to be very impressive – and now we had a dedicated customer who was paying 5x the going monthly rate for dialup.

Anyway, my point is that I used to do quite a bit of pre-delivery forwarding, which is harder to do now with SPF.

The point behind SPF (“sender permitted from” or “sender policy framework”) is that sender mail servers are verified, in an attempt to prevent forgery of e-mail and combat spam.

It’s a little klunky, but it does prevent a hijacked PC on a cable modem from being able to send out e-mail claiming to be from @aol.com.

Usually, I like it – because I hate spam. I haven’t had reason to try and do much pre-delivery forwarding in a while, but yesterday I did.

I had a client call in who needed to forward e-mail offsite. They had purchased another company and taken control of that company’s domain. We made the necessary changes to DNS, their anti-spam appliance (Sendio) and their mail server (Exchange 2003) to accommodate their new domain for inbound e-mail.

That’s when they had one more request. One of the employees of the old company had been promised that his e-mail would be forwarded to an external e-mail address. No problem. Create a contact, forward to the contact, and done, right?

Not so fast. The destination domain uses SPF, and the original sender e-mail address seems to come from the relaying server, and is rejected. In my case, say, joseph.king@joking.net sending to bob@domain1.com, which relays to bob@domain2.com. Mailserver.domain2.com sees @joking.net e-mail coming from mailserver.domain1.com, and drops it as unauthorized. In Exchange 2007 or later I could rewrite the sender address with an edge server, and with Exchange 2003 I could use the address rewrite tool – EXARCFG.EXE (if I wanted to rewrite everything in a specific virtual server). Neither of these are particularly helpful, because while the messages would be delivered, now the recipient cannot reply to the messages because they no longer see the point of origin e-mail address – @joking.net is now converted to @domain1.com.

Unfortunately, there really is no way to overcome this from our end. Since we’re trying to be sending email that’s both from and to external domains we are essentially acting as a relay. The external user will need to arrange for our client’s Exchange server to be whitelisted on his side to overcome SPF. (Or, I suppose we could ask the owner of every domain that may send to this user to add our client’s Exchange server into their SPF record).

But I think that would be a little more work.

4 thoughts on “SPF prohibits pre-delivery forwarding

  1. All servers that do mail forwarding to external address, must do SRS.
    If the server can´t do it, it´s not a mail server designed for the Internet nowadays (and for nowadays I mean since SPF/SRS were created).

  2. You´re kidding.
    You have a mail server that forwards mail to external users and it does not do SRS and you just say you can do nothing ? Your mail server aren´t ready for the Internet so, or you should not allow forwarding to external users.

    • Well, if you note from the article, it wasn’t MY mail server. Sometimes you don’t have the option of telling a customer to “rip everything out that you love and start over”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s