On 9/16/20 6:18 AM, Nick Tait wrote:
> Thank you.
> I see "SPF: SOFTFAIL" in my gmail message.
>
> Authentication results:
> spf=softfail (google.com <http://google.com>: domain of
transitioning some_user@sender_domain does not designate MY_IP_ADDR
as permitted sender)
>
> While the message is not blocked, it is still not good to have SPF
failure. Even when failure is soft.
>
> It seems that I can't fix it, right?
Don't worry about it. There are enough real problems to worry about.
Not that I'm recommending it (or in fact have any experience with it
myself), but theoretically at least, you could probably use the
"smtpd_command_filter" option to modify the RFC5321.MailFrom address
to substitute your own domain in place of the sender's domain (e.g.
change "sender@senderdomain" to
This is called Sender Rewriting Scheme (SRS). There are milters for it.
Our gateway uses a sub-domain in the rewrite, then rewrite's it back.
"sender+senderdomain@yourdomain"), before you relay the message to
Google (but after you've done your own incoming checks, which probably
entails setting up a separate smtpd service on a loopback interface)?
Doing so would alleviate the SPF failure, although I should highlight
that it won't actually make any practical difference to the DMARC
result because the RFC5321.MailFrom address will be out of alignment
with the RFC5322.From address. Plus it may also create other issues
with bounce messages... You'd probably need a mechanism to reverse the
translation for a non-delivery report received from GMail (e.g. change
"sender+senderdomain@yourdomain" back to "sender@senderdomain", so
that the original sender can be notified if your mailbox is full), but
at the same time avoid creating an open-relay type of vulnerability
(e.g. allowing an attacker to use "user+targetdomain@mydomain" to
trick your server into forwarding emails to "user@targetdomain").
Of course the real cost of implementing something like this is the
increased effort required to figure out what went wrong when something
isn't working properly. :-P
Nick.
--
--
Michael D. Sofka sof...@rpi.edu
ITI Software Architect, Email, TeX, Epistemology
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
