3 ms·

SPF is broken in many more ways than described in this presentation. I work as an email hardening / deliverability support engineer and our advice is always to

• lucb1e 3y ago
  What's wrong with SPF then? Since source IP spoofing is rather tricky¹ with TCP, I've always wondered what advantage DKIM has over SPF. I've always just configured SPF to allow $myIP only: good luck sending spam in the name of my domain, you'd have to compromise my ISP or registrar first, at which point you can also get TLS certs for my domain for example. Even for larger organisations which need to allowlist multiple sending systems, how would one spoof being one of the legitimate SPF sender in a situation where it is not also possible to spoof the DKIM records? That is, besides allowlisting a range of IPs that anyone can publicly use (as in the submitted talk), which is just dumb. ¹ although not impossible, spoofing an entire mail exchange requires terabytes of traffic for one email of a few bytes, iff starttls is not enforced in which case it becomes impossible
  • toast0 3y ago
    It's easy to have too wide of a range specified for SPF. You can't properly DKIM sign a mail unless you have a valid key (or you control DNS). As a medium/large corp, you might blanket allow mail from your whole IP space, but you're probably not pushing DKIM keys to all your hosts.
  • fiirhok1 3y ago
    A lot of normal email setups, e.g. forwarding, break SPF. As log as the message isn't modified, DKIM will work in these setups.
  • LeonM 3y ago
    > What's wrong with SPF then? - SPF breaks with forwarding. This is by far the biggest problem. You typically end up with very large IP blocks being included in your policy (for example: MS365 includes a total of half a million IPv4 addresses, and billions of IPv6 addresses). All of which are now allowed to send on behalf of your domain. You'll have to trust (or hope) that the third party properly prevents other tenants from sending email on behalf of your domain. This is the problem with MailChannels as explained in the PDF. - SPF can be very tricky to get right, one simple mistake and you either allow way to many IPs, or break your entire email domain. Even most seasoned IT administrators don't fully understand the entire RFC with all its errata and amendments. Now imagine some less technical user trying to set up SPF. - You can only have one SPF record. If you want to add some external service, you'll need to merge your existing SPF record with the example given by your vendor. This can be highly confusing to many. - The SPF DNS record is placed at the domain root (apex), which as shown in other comment here can be problematic for large orgs. This also prevents using a CNAME for SPF. - SPF limits to 10 DNS lookups, which has proven far to low for modern use. The rules on how to calculate the number of required lookups is also ambiguous, so some receivers may accept your email, some may reject based on lookup limits. - SPF contains many rarely used features (such as macros) that may or may not be implemented by the receiver, so you can't really rely on it. - IP spoofing is an issue, but as you noted, this is not always a practical attack. DKIM is in any regard more robust, more secure, and more important: easier to set up for the domain administrator. Just copy/paste the DKIM record provided by the third party email service. The third party vendor can (and most do) easily verify that the DKIM record is set up correctly. This is about as easy as it gets for DNS. > Even for larger organisations which need to allowlist multiple sending systems, how would one spoof being one of the legitimate SPF sender in a situation where it is not also possible to spoof the DKIM records? That is the problem with the (current) DMARC specification, you need SPF or DKIM to pass DMARC. Emphasis on or. So no matter how well you manage your DKIM keys, if someone can spoof (or has access to) one IP in your SPF policy, then the email is delivered. This is also explained in the talk. Also, with DKIM you don't 'spoof' the record, you'd have to MITM the receiver when they fetch the DKIM DNS record, this is very hard to pull of in practice.
    • lucb1e 3y ago
      Thanks! Your reply and its siblings have convinced me why DKIM is better overall; my opinion was changed, but there's one part that doesn't make much sense to me: > and more important: easier to set up for the domain administrator. Just copy/paste the DKIM record provided by the third party email service Pasting the same known value (my IP address) into a TXT record of the domains I want to send email from is an order of magnitude easier than 1. configuring the mail delivery software to ask opendkim for a signature, which in turn needs multiple config files and lookup tables for every domain 2. deploying a cryptographic key that doesn't even fit into one record, with various guides telling you different things on how you should be inputting the data 3. still failing the DKIM check because it turns out that 4k or even 3k rsa keys (let alone ecc! But I wasn't trying to be adventurous...) are not commonly enough supported and so you get to start over, wait another 24 hours for caches to flush, and ask another favor from that friend using that failing provider if they can send me the headers of a new test email to see if it passes now. Even in your scenario where you hand your emails off to a third party, they can give you the SPF record to plug in literally, same as with DKIM, and then SPF is still easier because the input format doesn't depend on the registrar.