rich text

AOL implements SPF

Just found out from Freeside that
his baby, SPF, has been implemented
by AOL:

$ host -t txt aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
  ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24
  ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24
  ip4:64.12.138.0/24 ptr:mx.aol.com -all"

SPF is Sender Permitted From, an antispam soon-to-be-standard
which essentially allows domain owners to specify the hosts from which
mail can be expected to originate from that domain.

Getting AOL on board is a pretty impressive win. You’ve all published your
SPF records, right?

Rich

4 responses to “AOL implements SPF”

  1. Here’s a situation:

    I’m at work. I have an account with my ISP, but I’m sending mail “from: peggy@isp.com” through my work’s SMTP server. Wherever I’m sending that mail would bounce, correct? This would mean that people would always have to use their e-mail account’s related SMTP server, which isn’t always possible because some ISPs block traffic on port 25.

  2. That’s the simple view. The simple answer to the simple view is that if you are dealing with a company that can’t provide the services you require (either your local connection blocking port 25, or isp.com publishing hard-fail (“-all”) instead of soft-fail (“?all”) SPF, or isp.com refusing to allow SASL SMTP on port 25 or 587), then you shouldn’t do business with them. If your ISP decided you couldn’t download MP3s, you’d probably move; if they decide you can’t send mail from other networks, you should move then too.

    But there are ways for the ISP to make it work.

    The optimistic one is that there will be no reason to block port 25 outgoing once SPF is adopted — but there will be an adoption period in which SPF and blocked ports exist.

    SPF has soft-fail precisely to deal with that period, where isp.com wants to tell people where you expect mail to originate, but admits that some will still send from elsewhere.

    The mail-injection port, 587, is another way to handle this; isp.com wants you as a customer, and is aware that other networks are blocking port 25 outgoing, so they accept SASL connections (only) on 587. That’s what port 587 is designed for, and there’s probably a good argument to be made that port 25 for injection isn’t the best idea. The other ISP involved can’t very well block 587, since it’s only used for injection in the first place, and one can only go so far in preventing customers from doing what they want to do.

    But yes, the intention of SPF is that when implementation is commonplace, everyone will use their ISP’s SMTP server to send mail from their ISP’s domain (which isn’t an unreasonable request, inasmuch as the ISP owns both the server and the domain name), and that that will be permitted from non-local networks via SASL.

    For what it’s worth, the SPF FAQ anticipated your comments in terms of how an ISP should support SPF here, and the objections page responds to some scenarios which roughly match what you describe.

  3. That was a really long way for me to say “If your ISP implements SPF, they’ll do it so that their customers can still meet their needs” — either through soft-fail or exists or through providing SASL SMTP on unblocked ports.

    If an ISP implements SPF rules that don’t match what their users actually do, then their mail will be refused and their helpdesk costs go up, whether it’s because they forgot the users who are in the situation you describe, or because they forgot one of their own mailservers, or because they typoed an address. It’s in the ISP’s own interest not to misconfigure their own systems, and no-one else can misconfigure their systems for them.

  4. I did do some searching on the web sites you provided… and thanks for the extra links. It all looks very interesting :)