EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 20 Jul 2007, 03:30 PM   #1
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,686

Representative of:
Fastmail.fm
SPF for FastMail domains

One of the reasons we haven't been keen on SPF records is that we want out customers to be able to send their @fastmail.fm (or other domains) email via their own ISPs and SPF would cause a "lock in" which isn't what we're about.

However - I've been re-reading the SPF documentation (in particular: http://www.openspf.org/SPF_Record_Syntax) and it looks like we can get some of the benefits of SPF without causing any problems.

The syntax I'm proposing is:

Code:
v=spf1 include:spf.messagingengine.com ?all
We have been providing spf.messagingengine.com for a while, and I was re-reading about it to figure out what to add to our FAQ now that we're happy it's working correctly.

how this works:

the
Code:
include:spf.messagingengine.com
part means that our own IPs get a positive SPF "pass" response for all our domains. The
Code:
?all
part should theoretically mean that every other host out there gets no SPF benefit, but also no SPF rejection.

So - what do people think? Do you see any problems with this? I'm hoping it will help our outbound email for SMTP and web users avoid being incorrectly tagged as spam.

Bron.

Last edited by brong : 20 Jul 2007 at 03:33 PM. Reason: looks like pre doesn't work, code it is!
brong is offline   Reply With Quote

Old 25 Aug 2007, 07:31 AM   #2
digory
Junior Member
 
Join Date: Aug 2007
Posts: 1
Looks ok to me.

Do I understand correctly that you want to allow FM customers to be able to send using any SMTP server they wish, such as their ISP's? Maybe your customers require that, but to make SPF work, your customers should send on an FM SMTP server. I don't see why this would cause any trouble...
digory is offline   Reply With Quote
Old 25 Aug 2007, 10:50 PM   #3
lane
Cornerstone of the Community
 
Join Date: Dec 2005
Location: Kars, NB, Canada
Posts: 704
Quote:
Originally Posted by digory View Post
Do I understand correctly that you want to allow FM customers to be able to send using any SMTP server they wish, such as their ISP's? Maybe your customers require that, but to make SPF work, your customers should send on an FM SMTP server. I don't see why this would cause any trouble...
I am sure Fastmail does not care whether their customers send from Fastmail's smtp server, or another one such as their ISP's server.

But if you put in an SPF coding that requests that only Fastmail's servers are allowed to send email with your domain, you can run into trouble with recipients who forward their email, and you can't control that. If your recipient forwards your email to another account, and the first receiving account does not rewrite the headers, then his final receiving account will reject the email since it will not have come (directly) from Fastmail's servers. Some emails services like Tuffmail and Gmail do rewrite the headers, but this is not common practice. This is why "?all" works better than "-all" at the end of the SPF string.

I had a lot of trouble myself that way when I had Fastmail host my domain's email, but I did all reading and responding from Hotmail. I did this because it was easy to use Hotmail through my company's firewall. Hotmail would often discard incoming messages quietly with no indication to sender or receiver, and sometimes, I think, this was due to the sender's SPF settings. When I discovered ports on Fastmail's proxy servers where I could access my email there through the firewall, I dropped Hotmail like a HotPotato.
lane is offline   Reply With Quote
Old 26 Aug 2007, 12:36 AM   #4
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,677
Arrow No SPF yet for FM domains, but virtual domain SPF works well

Since this thread is over a month old, I'm a little confused. I don't think this has yet been implemented for FM domain aliases. When I send an email from a FM domain alias (sent.com) to a GMail account, I get the following headers at GMail:
Code:
Received-SPF: neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected])
And dnsstuff.com shows that no SPF records exist for sent.com.

---------------------

My virtual domain SPF record published by Fastmail appears to work well for GMail. Here is what the GMail received headers show for a message sent by a Fastmail virtual domain account with STANDARD_SPF set up:
Code:
Received-SPF: pass (google.com: domain of [email protected] designates 66.111.4.26 as permitted sender) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected]  designates 66.111.4.26 as permitted sender) [email protected]
For some reason, at dnsstuff.com the SPF shows properly for a full DNSreport, but not for a DNS Lookup of the SPF record. The DNSreport shows:
Code:
You have an SPF record. This is very good, as it will help prevent spammers from abusing your domain. Your SPF record (I don't check to see if it is well designed!) is:
"v=spf1 include:spf.messagingengine.com -all" [TTL=86400]
While the DNS Lookup for SPF returns:
Code:
Searching for mydomain.xxx SPF record at ns1.messagingengine.com. [66.111.4.2]: Reports that no SPF records exist. [took 39 ms] Response: No SPF records exist for mydomain.xxx. [Neg TTL=2560 seconds] Details: ns1.messagingengine.com. (an authoritative nameserver for mydomain.xxx.) says that there are no SPF records for mydomain.xxx. The E-mail address in charge of the mydomain.xxx. zone is: [email protected]
Bill
n5bb is offline   Reply With Quote
Old 27 Aug 2007, 09:34 AM   #5
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,686

Representative of:
Fastmail.fm
Sorry, I threw this idea out for discussion but didn't get back to implement it. I've just done it now...

Code:
spf.messagingengine.com. 86400  IN      TXT     "v=spf1 ip4:66.111.4.0/24 ip4:66.139.75.100 -all"

fastmail.fm.            86333   IN      TXT     "v=spf1 include:spf.messagingengine.com ?all"

sent.com.               86400   IN      TXT     "v=spf1 include:spf.messagingengine.com ?all"

... etc
brong is offline   Reply With Quote
Old 27 Aug 2007, 09:02 PM   #6
lane
Cornerstone of the Community
 
Join Date: Dec 2005
Location: Kars, NB, Canada
Posts: 704
Bron, I am not an expert in SPF, but doesn't the "-all" at the end of the include mean that the "?all" at the end of the others will never be reached?

-- Lane
lane is offline   Reply With Quote
Old 27 Aug 2007, 09:18 PM   #7
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,686

Representative of:
Fastmail.fm
Quote:
Originally Posted by lane View Post
Bron, I am not an expert in SPF, but doesn't the "-all" at the end of the include mean that the "?all" at the end of the others will never be reached?

-- Lane
I don't believe so, no:

http://www.openspf.org/SPF_Record_Syntax

Quote:
In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall Fail. (Better names for this mechanism would have been "if-pass", "on-pass", etc.)
brong is offline   Reply With Quote
Old 27 Aug 2007, 09:24 PM   #8
lane
Cornerstone of the Community
 
Join Date: Dec 2005
Location: Kars, NB, Canada
Posts: 704
Thanks for the reference. I read through it, and it certainly sounds as though you are correct. Pretty confusing, though.
lane is offline   Reply With Quote
Old 27 Aug 2007, 09:55 PM   #9
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,677
Arrow SPF working for FM domains, but fails for FM subdomains

Thanks, Bron. I have verified SPF is working for aliases I have at the following FM domains when sent to a GMail address:
  • fastmail.fm
  • sent.com
  • warpmail.net
  • eml.cc
  • mm.st
  • fastest.cc
  • fastmail.net
Plus addresses (such as [email protected]) also pass SPF when sent to GMail. For all of these, GMail rates the SPF as passing as follows:
Code:
Received-SPF: pass (google.com: domain of [email protected] designates 66.111.4.26 as permitted sender) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 66.111.4.26 as permitted sender) [email protected]
However, when I used subdomain addressing (such as [email protected]), GMail returned a neutral SPF rating:
Code:
Received-SPF: neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Bill
n5bb is offline   Reply With Quote
Old 27 Aug 2007, 09:58 PM   #10
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,686

Representative of:
Fastmail.fm
Quote:
Originally Posted by n5bb View Post
Thanks, Bron. I have verified SPF is working for aliases I have at the following FM domains when sent to a GMail address:
  • fastmail.fm
  • sent.com
  • warpmail.net
  • eml.cc
  • mm.st
  • fastest.cc
  • fastmail.net
Plus addresses (such as [email protected]) also pass SPF when sent to GMail. For all of these, GMail rates the SPF as passing as follows:
Code:
Received-SPF: pass (google.com: domain of [email protected] designates 66.111.4.26 as permitted sender) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 66.111.4.26 as permitted sender) [email protected]
However, when I used subdomain addressing (such as [email protected]), GMail returned a neutral SPF rating:
Code:
Received-SPF: neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=66.111.4.26;
Authentication-Results: mx.google.com; spf=neutral (google.com: 66.111.4.26 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Bill
Indeed!

I've added a record for *.<domain> as well. Looks fixed from a quick dig here.

Thanks for the quick feedback.

Bron.
brong is offline   Reply With Quote
Old 27 Aug 2007, 10:12 PM   #11
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,677
Cool Fixed: SPF now working for FM subdomains

You work fast, Bron! I have now verified that FM subdomains pass SPF when sent to GMail addresses. I tested the same FM subdomain address that failed 30 minutes ago, and it now passes.

So now we have SPF always available for Fastmail domains, subdomains of Fastmail domains, and Plus +addresses at Fastmail domains.

And we have SPF available optionally for virtual domains, if the user adds STANDARD_SPF records in the Custom DNS screen to the .mydomain entry (main domain) and *.mydomain entry (any subdomain).

All of the above I have verified works well with GMail, and I assume with other email providers.

Bill
n5bb is offline   Reply With Quote
Old 27 Aug 2007, 10:17 PM   #12
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,686

Representative of:
Fastmail.fm
Yeah, it should be.

I'm actually tempted to make user domains default the same, and have another keyword (STRICT_SPF maybe) to change the end to -all. Or you can of course write your own if you have a more complex policy to describe.

Bron.
brong is offline   Reply With Quote
Old 20 Sep 2007, 07:12 AM   #13
elvey
The "e" in e-mail
 
Join Date: Jan 2002
Location: San Francisco
Posts: 2,450
Unhappy No blog or email announcement???

No blog or email announcement??? You seem to have missed the discussion here, too: http://wiki.fastmail.fm/index.php?ti...nsSecurity#SPF

I (I'm sure you're not surprised to hear) don't think this was good idea.

Quote:
However - I've been re-reading the SPF documentation (in particular: http://www.openspf.org/SPF_Record_Syntax) and it looks like we can get some of the benefits of SPF without causing any problems.
Have you looked at how SpamAssassin scores mail from [email protected] but not through your servers with and without this change? Is it the same? (Yes, it 'should' be, but IS it? However, according to the scores at http://spamassassin.apache.org/tests_3_2_x.html, it it's hard to argue that Fastmail should continue to insist on not publishing an SPF record. Some really odd numbers there for the SPF tests, if you look closely - e.g. SPF_NEUTRAL is WORSE than SPF_SOFTFAIL for the usual bayes+net setups)

PS http://www.postfix.org/MILTER_README.html has good info on how to set up DKIM signing.

Last edited by elvey : 20 Sep 2007 at 08:07 AM.
elvey is offline   Reply With Quote
Old 20 Sep 2007, 08:29 AM   #14
robmueller
Intergalactic Postmaster
 
Join Date: Oct 2001
Location: Melbourne, Australia
Posts: 6,102

Representative of:
Fastmail.FM
The scores for SPF_NEUTRAL, SPF_FAIL and SPF_SOFTFAIL all look pretty similar to me. Anything I'm missing?

Rob
robmueller is offline   Reply With Quote
Old 21 Sep 2007, 08:28 AM   #15
elvey
The "e" in e-mail
 
Join Date: Jan 2002
Location: San Francisco
Posts: 2,450
SPF_NEUTRAL is WORSE than SPF_SOFTFAIL for the usual bayes+net setups. Not much worse, but that's rather surprising. In other words, the SA optimizer determined that (when run on the corpus used to develop the default scores) sending from a domain not having an SPF record was more of a spamsign than sending from a domain that did have one, but through a specifically unauthorized server. This shows that SPF very often is unable to correctly identify abuse, e.g. misidentifies legitimate mail as illegitimate. Specifically, if SPF wasn't a lousy framework, the score for SPF_SOFTFAIL would be much higher.

PS How 'bout that announcement?

You do keep track of your deliverability / bounce rates, right? It would be great if you would check to see how doing this impacted those rates and let us know what you find.
elvey is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 07:54 AM.

 

Copyright EmailDiscussions.com 1998-2013. All Rights Reserved. Privacy Policy