Using /srv/<domains/mailboxes/<user>/forward with an external destinations fails SPF and DKIM checks
#54
Comments
|
How is this different?
|
|
Heres a header from a mail which was forwarded with the forward file (though a different domain, but on the same box). Effectively it's just dropping the mail back in the spool after changing the RCPT TO - this is fine for delivery, but a sender with SPF set strictly will reject it as the original domain (bytemark.co.uk in this case) doesn't consider the Symbiosis server (carth.ebonhawk.example.uk0.bigv.io) as valid. We've had more than a few customers over the last year who have been using forwards like this for account which get a fair bit of spam then forward the mail on to a hotmail address or similar - this looks like the server is sending the spam itself (complete with invalid SPF and so on), so if left a while the IP reputation will drop with the destination host, and then that server will have trouble sending mail to any account on that host.
|
|
So from what I can gather here, the important difference is that the Return-Path is re-written from to by the sieve forwarding, but not by the exim4 forwarding. I'd almost be tempted to suggest that the sieve rule is doing the wrong thing anyway. The Return-Path is where bounces will go to if the recipient address is unavailable for some reason. I'd assume that if This is a really common problem with SPF, and is "solved" with SRS although this would be quite complex to sort out, I suspect!
|
|
Assuming someone is reading/receiving the local admin emails, then they would probably want to know if they set a forward which isnt working any more so they can disable it and/or contact the user by other means to sort it out. Since I started looking at SNDS, the majority of the reports which were causing problems (for us and other users) were down to blind forwarding on noisy addresses, and while it's still happening (although at a much lower rate) if Symbiosis is being responsible with mail it would probably need to either use SRS (which would be non trivial) or rewrite the Return-Path to something relevant to avoid it becoming a bigger problem later on - after all, any mail with SPF set up properly will not be delivered, and we've seen that with our own customers using forwarding which breaks the line of communication in RT.
|
|
Hmm, if the server is DKIM signing outbound mail, then that should be OK. But SPF checks fail without rewriting of the return path: and that will massively hinder deliverability. Especially when the sender address is in a domain with a "-all" spf record like, erm, BYTEMARK.CO.UK SRS isn't enough these days, though. Big recipients like YAHOO also check SPF for the FROM header address. That's a big mess. Forwarding is basically not reliable these days, and we should discourage it, it my view. Instead, we should steer people to using POP/IMAP fetch.
|
|
Yes, SPF isn't supposed to be used to inspect message headers at all. The problem is, that validating the return path is pretty meaningless, since the person reading the message never sees that. Anyway, Yahoo do that because someone stole all their users' address books. So they have a massive fraud problem. It means that discussion type mailing lists are pretty much unusable, unless you rewrite From headers, or don't have any Yahoo users on the list. But lots of users don't have sigs, so when you rewrite the From header, nobody on the list knows who wrote what. So mailing list managers typically offer rewrite options to change "Bill Blogs <foo@gmail.com>" to something along the lines "Bill Blogs via the list <list@example.com>"
|
|
I'm going to close this issue for now, as I don't think it can be addressed reasonably at this time. |
As
/srv/<domains/mailboxes/<user>/forwardsimply relays the mail, it often causes SPF and DKIM signed mail to fail. This is particularly bad as the more important the mail (banks etc) the more tight their SPK/DKIM will be, and the destination mail server may simply drop invalid mail, or in many cases (see SNDS) simply flag all mail coming in that route as spam.This can be worked around by using a basic Sieve filter (created in a mail client or Roundcube, etc) instead of a basic forward, which generates a header in the final mailbox like this:
This works with a simple sieve rule like:
It would be great if the forward file generated the relevant sieve rule, and massively improve deliverability.
The text was updated successfully, but these errors were encountered: