Actually you should get rid of SPF entirely. SPF does nothing to control spam and it breaks email forwarding. It invites false positives. If someone uses SPF an my spam filtering service then your email WILL BOUNCE when I forward it on to the recipient.

If someone has a front end spam filtering service or is forwarding email then the mail will be coming from a server other than a freshbooks server and you'll have a false positive. SPF is a seriously broken technology and should never be used. I'm in the spam filtering business.

Hey Micksta, welcome to the forums.

Basically, what it boils down to is that SPF is a seriously broken technology, and we don't want to support it. If folks want to use it, that's totally their choice, but we're not going to create an SPF record on our servers. Not only would it encourage a small minority to continue using it, it would also be something we'd need to remember (and know how) to keep updated if our configuration ever changed.

We don't have our own e-mail server either, so we don't know what IPs the e-mails would be generated from, and we wouldn't know when new IPs were added.

I'm sure you can take a look at the MX record on freshbooks.com to see what mail servers we use. And can't you just include that MX record or something?

At any rate, this conversation just serves to illustrate why SPF doesn't work. If you want to use it with FreshBooks e-mails, you'll have to keep the record updated at your end, because we won't be implementing a record at this end.

Have you looked at alternate technologies like Certified Server Validation?

mperkel wrote:

Actually you should get rid of SPF entirely. SPF does nothing to control spam and it breaks email forwarding. It invites false positives.

That's just FUD.

An SPF record is a DNS record that tells interested receiving email servers which other email servers on the Internet are allowed to send email for the domain of any given incoming email. The presence of an SPF record ensures that email from, say, jonwatson.ca can only be delivered by servers that I specifically authorize to send email for it. Other servers sending email purporting to be from jonwatson.ca are lying and that can be verified by consulting my SPF record.

Therefore, SPF does indeed assist in controlling spam and it does not break email forwarding that is done properly.

If you send me an email and I forward it to my friend, then my friend will receive it because regardless of the fact that the email originated from you, it is still 'from' me and I will send it to him via a server authorized to send email for my domain.

Sounds to me like you're trying to forward email with a spoofed 'from' address which is exactly the sort of behaviour that spammers employ and is thus effectively caught by the SPF framework.

Domain owners getting rid of their SPF records only ensure that their email will not get delivered to an increasingly broader range of providers. Whether you like it or not, more and more providers are using the SPF process and those domains without an SPF record are finding more and more of their email is not being delivered.

mperkel wrote:

If someone uses SPF an my spam filtering service then your email WILL BOUNCE when I forward it on to the recipient.

As I noted above, if SPF is stopping you, then you're probably spoofing the from address. The solution is to not forward or change the 'from' address to something from your domain and move the original 'from' address to the 'reply to' field. I haven't bothered to look, but I'm sure if you consult the email RFC, you'll find that's the correct use of those fields.

Alternatively, your users can POPemail from your server. SPF will definitely mess up the system you have in place, but telling people to get rid of their SPF records won't help.

Consider if I send an email to someone using your service from my jonwatson.ca domain to one of your customers who uses a provider that enforces SPF. If I have an SPF record, they will not receive my email because my SPF record does not authorize your servers to deliver email from my domain. If I take your advice and get rid of my SPF record, then the user will still not receive my email because...well....I have no SPF record and their server is looking for one. Your advice would only serve to not only ensure that my email is not delivered to your user, but also to many other email users on the Internet at large.

Whether my email gets delivered to one of your users does not depend on whether or not I have an SPF record, it depends on the fact that the system you've put in place is now obsolete because of the SPF framework. While I can appreciate that probably makes you angry, telling people to remove their SPF records doesn't help them use your system at all and in fact degrades their overall email delivery rate Internet-wide.

Fresh Aaron wrote:

Jon, I think you misunderstand what "e-mail forwarding" is; it isn't the act of clicking "forward" and sending a message to a friend. It's like call forwarding; similar to "if somebody calls this number, pipe it to this number instead," it does the same thing with your e-mails. Mail to one place is simply redirected to another place, and it's perfectly valid to do so.

Hi Aaron,

The fact that SPF breaks email forwarding is just a symptom of the root cause which is the RFC for email. There was no such provision build into the RFC yet it became, as you say, a common practice. Spammers thought so too, so one of the many tools brought into play was the SPF which banks on the RFC and thus breaks this practice. You say it's valid, but it's not. It's just something that people have been doing and while SPF stops that practice, it doesnt' means SPF is broken. I would submit that the email RFC is broken if the world at large wants to do this email but cannot.

Alternatively, receivers that use SPF should configure their machines properly as per the OpenSPF FAQ whch confirms, as I've said, that spoofing the from address is not a valid practice. This is the purpose of the reply-to field, but I guess some people feel that configuring their servers to spoof the sender is a better idea.

http://www.openspf.org/FAQ/Forwarding

Fresh Aaron wrote:

For instance, if you send an e-mail from the jonwatson.ca domain to somebody with e-mail forwarding set up, when they eventually receive the message from you, it didn't arrive from your server; it was forwarded from their server. If they check the SPF record, it's going to reject the message. The solution: they disable SPF. Which then means if somebody else sends a message claiming to be from you, well, they'll get it.

I'm not sure you understand who has control over the SPF checks. Unless the person I am sending email to actually has configuration control over their incoming email server, they're not going to be able to disable SPF.

Further, and more importantly, as the jonwatson.ca domain owner, I control whether email coming from a server I have not authorized will be accepted by the receving server. The receiving server does not make that decision (at least it doesn't based soley on SPF). Investigate the use of ?all, -all, and ~all in an SPF record.

Fresh Aaron wrote:

That's the nature of the "from" address; it's like the return address on an envelope. You can write anything you want there. That's the way it's designed, and it's never a piece of information you can trust.

That is not the nature of the 'from' address. If the person actually sending the email isn't the 'from' addressee, then the 'sender' field exists for this purpose. If the reply is to go somewhere else, the reply-to field exists for this reason. You see, just because the correct use of email has fallen out of vogue doesn't mean what we are doing is correct. The current day usage of email begs to be broken because it is not used correctly by the vast majority of users. Blaming SPF for stopping us from violating the email RFCs doesn't make a lot of sense.

Fresh Aaron wrote:

That's not true; if you don't have an SPF record, all mail from your domain gets delivered. Since SPF records aren't a mandatory part of the DNS record, and over 80% of domains don't have one, rejecting e-mail on that basis would result in getting, well, just about nothing.

That is true. I misspoke. I thought an email server could be configured to trounce email from a domain without an SPF record, but that is not supported in the spec.

Fresh Aaron wrote:

So, the basic argument against SPF is that it only works when you check the SPF record, AND the sender has an SPF record, AND you don't use e-mail forwarding. If either of the first two are false, you get unverified e-mail; if the third is false, you lose e-mail.

I think the disagreement here stems from the fact that you think that SPF is designed to protect the receiver. It's not. It's designed to protect me, the domain owner, from having my domain hijacked to send spam. There's no way SPF is going to stop spam, but it will stop spam from my domain. If I care about my domain, I will SPF it to ensure that only authorized servers can send email from it (or forward email through it). I will also keep that SPF record updated. If I don't care, then I won't and I run the risk of having spam sent from my domain. It's a tool for domain owners, not recipients.

I will agree that ISPs and other providers that offer email services to their end users should not use SPF records because they have no control over how their users are forwarding email. However, the vast majority of domains are not serving email to end users so that's not a huge hole.

In any case, a properly configured forwarding service would make use of the available fields in the email RFCs rather than spoofing the from address anyhow and this would all be moot.

Fresh Aaron wrote:

At any rate, if you want to use SPF, you're still free to add our server to your SPF record, and we may provide an SPF record for inclusion in the future now that we actually have someone who administrates these things. But since so-called "e-mail spoofing" remains a common and valid practice, there's no real emergency here.

That's fine, I'm happy to just add your server to my SPF record. However, when searching around for the server name or IP, I can't seem to find it. I even opened a support ticket today and Corey told me that it would change all the time so there's no sense adding it. So, if I am going to allow Freshbooks to send email from my domain, I have to set my SPF record to soft-fail. That's how I run it anyhow, so no big deal for me, but by not maintaining an SPF record, you are effectively taking some of the control of my domain away from me and forcing me to allow spammers to use my domain for spam. I cannot run a hard-fail SPF record when using Freshbooks because you're blaise about providing an SPF record or a consistent server name (come on, an IP address I can see changing, but do you really have so many servers sending email that you can't give out the a records for them?).

Anyhow, to sum up (too late, I know), despite appearances I am not advocating SPF. I too believe that it has implementation problems but they stem from incorrect use of email format and misconfigured servers, not from SPF itself. Perhaps it was naive of the SPF creators to build the framework against an RFC suite that is so obviously disregarded, but it's no more broken than older spam control methods such as sender callout verify and reverse DNS lookups. The important difference with SPF is that it puts some control into the domain owners hands about which servers can send email for them. All of the other tools to date do not allow the domain owner any control over their email delivery on the remote end.

Jon

Fresh Aaron wrote:

Sorry if we didn't provide that address, we should have; it's relatively easy to find, too, just by looking at the e-mails we send. It's server1.freshbooks.com, 72.32.48.26.)

Thanks for the server IP.

As for notification, may I suggest http://www.freshbooks.com/blog/?

Jon

Not "Amen".

Freshbook's unwillingness to maintain their own SPF record means that just plunking 'server1.fershbooks.com' into an SPF record isn't a good solution. As Aaron has already said - that server name will change and when it does, my SPF record will have to be updated but since Aaron has pointed out there is no way to notify users of changes, I really have no choice but to run a softfail SPF record.

Freshbooks has pretty much outright refused to do the right thing even though it is trivial to do so. Thus while the discussion has stopped, the issue remains unresolved.

Thanks for the update and the info.

Jon

Yes, that's why trying to guess our mailservers' addresses in advance isn't going to work well -- sometimes we need to change them. That's why I recommended soft-failing, above. We'll be publishing SPF records to <i>include:</i> shortly; I've decided that waiting until we're ready to do SPF <i>and</i> DKIM at once isn't worth it, because I know SPF well but little about DKIM.

(We did send an announcement by email to account owners detailing the IP address change, though!)

It's not specifically local to you, though -- all of FreshBooks is hosted with Rackspace in DFW.