Open t3hmrman opened 2 years ago
Note the src_ip in maddy log being 10.244.206.187. That's probably the internal network's address of your Haraka server. maddy is trying to match that against sender.tld SPF record which fails.
In order to correctly check SPF (and also DMARC, by the way), maddy needs to know the actual IP address of the sender. maddy currently does not support any protocol extensions (XCLIENT or PROXY) that would help with this. Neither Haraka, it seems (it supports PROXY protocol server-side only, that is, accepting proxies connections only).
Yep -- so this is running inside a Kubernetes cluster, and PROXY
support is provided for the ingress controller.
Haraka will at least accept the PROXY
protocol. For actually passing through the connection, I don't think it forwards the PROXY
information....
Is there any way to use an external address?
Describe the bug
Maddy is reporting a
MAIL FROM
address as having SPF insecurely set (allowing "all"?) when it does not.Note that other emails get through just fine (ex. GMail, ProtonMail).
Steps to reproduce
The incoming mail path looks like this:
I'm trying to send an email from
sender.tld
torecipient.tld
, withsender.tld
being the MAIL FROM address on SES.The email gets all th way to maddy, but maddy fails the SPF due to "matched all" (see logs). I assume this means that the SPF policy was determined to match
all
, but when I check my DNS I'm 100% sure it doesn't and never has. The record is:v=spf1 include:amazonses.com -all
I've used the google toolbox to check the record so it's not just me either. In fact I'm fairly sure this rule is inserted by AWS SES automatically when you create a MAIL FROM alias because I don't see it in my infra code (and if I try to manually add one it collides)...
(Insecure) Workaround
(Don't try this at home folks!)
So of course, to test my hypothesis I've set
fail_action ignore
underspf
in the local routingcheck
stanza and the email gets through.Log files
After doing the workaround:
Configuration file
Environment information