search

hardenize / hardenize-public

11 stars 0 forks source link

SPF macro expansion fails #53

Open saulchristie opened 5 years ago

saulchristie commented 5 years ago

I have an SPF record which uses macros in order to redirect SPF lookups to different records based on the email address of the sender.

I'm using %{l1r+} in order to get the localpart without any 'plus addressing' and with this your service is fine - e.g. this works: v=spf1 redirect=%{l1r+}._spf.example.com

However, I've tried to consolidate and use %{d} instead of the domain and that fails your checks, e.g - this fails: v=spf1 redirect=%{l1r+}._spf.%{d} (where %{d} expands to example.com)

Now I don't actually need to use %{d} - it was more so my SPF records were the same on all my domains - but I think what I'm doing is valid and should pass your checks?

(For info, one of the best checkers I've found is https://vamsoft.com/support/tools/spf-policy-tester as this actually gives an example macro-expanded SPF based on an email address - you may like to do the same using either the 'standard' RFC test localpart of 'strong.bad' or the fallback address of 'postmaster')

saulchristie commented 5 years ago

Actually thinking about it... maybe you're not doing ANY macro expansion and you literally looked for ${l1r+}._spf.example.com in the version that passed. Not sure.

So I guess it's either you need to add in macro expansion altogether, or it's you need to fix it! .

ivanr commented 5 years ago

Hello Saul, your second comment is correct—we don't currently do any macro expansion. It's not that we don't want to, but because it's a seldom used feature, it stayed on our todo list unimplemented. We're planning to review all our tests starting from Q2 this year and we'll fix this problem then at the latest (sooner if time permits it). Thanks for your report!