Hacker News new | ask | show | jobs
by mmcclimon 1766 days ago
Yeah, for sure! Outlook is also very bad about this, and usually when we see it people have added include:spf.messagignengine.com (Fastmail's SPF, which is all IP addresses) and one other include, which does a bunch of recursive lookups. This is often very difficult to explain to people, and there's not even really a way to work around it, short of using different domains for different sending needs (which many people are unwilling or unequipped to do).
1 comments
Hello71 1766 days ago
why can't you just periodically fetch and cache the records yourself? i.e. an ALIAS record for SPF. if the customer doesn't want to use dynamic dns, then you could even provide this service for them, of course charging a premium for the "enterprise feature".
link
marcbradshaw 1766 days ago
There are services which do that, but it doesn't work in every situation. It can't (for example) cope with SPF macros, which is where the server looking up the record can replace parts of the record it is requesting with variables from the SMTP session (for example, by inserting the connecting IP address into the record lookup domain). In short, as stated in the article "email is complicated"
link
sillystuff 1766 days ago
> why can't you just periodically fetch and cache the records yourself?

The only way this will help you is if you recursively de-reference all the records, and replace them with a list of allowed sender IPs. Now you have a new problem. You only get 255 characters in a single string in DNS. You can chain multiple 255 character strings together into a single record though, so you can get up to 4K characters. But, if you have a bunch of authorized spoofers (e.g., mailchimp) that different departments of your organization uses, even 4K characters may not be enough (source: I went through this exercise a couple years ago and our organization would have needed closer to 8K characters for the de-referenced records).

Our solution is to include our own outbound MTAs, and ?all. On inbound, we don't use SPF as a signal at all, as there are too many sites with misconfigured records.

Long term, we are trying to get each department to send spoofed mail using per-department subdomains, e.g., info@marketing.example.org, data@research.example.org, etc.

DKIM + DMARC is designed to handle the above without any of the issues SPF has.

link