> 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 "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.
