On 2022-04-28 at 12:45 -0600, Geoff Mulligan via mailop wrote: > I have a user on one of my servers that uses procmail to forward > messages to their gmail account. > > Every once in a while messages sent to them are "bounced" to the > sender with the error fro gmail: > > 550-5.7.26 This message does not have authentication information or > fails to 550-5.7.26 pass > authentication checks. To best protect our users from spam, the > 550-5.7.26 > message has been blocked. > > How can I diagnose this???
Seeing it here as well. Something has recently changed in gmail again, just like last December. I'm quite sure Robert L Mathews discovery of the line-wrapping issue was caused by this as well. (And yes, this is happening to legit messages, hand-typed for them, and that when reviewed manually show no trace of spamminess at all) If your senders use DKIM, those will generally pass. However, a) some senders do not implement DKIM, so their mails cannot benefit from it when forwarded b) some mails will have invalid DKIM signatures (in which case you will have a hard time figuring out if that was broken to begin with or if some uncommon feature on this mail moved your MTA to "fix" it breaking the signature) On 2022-04-28 at 12:02 -0700, Brandon Long noted: > Are they using the suggestions on > https://support.google.com/mail/answer/175365 for procmail > forwarding? > > There's a double edge sword with SPF auth for forwarding.. if you re- > write the envelope sender to the forwarding address and forward spam, > the forwarding domain can accumulate poor reputation. If you don't > rewrite the envelope sender, then the messages will no longer be SPF > authed, and that may cause spam detection issues. Gmail guidelines explicitly ask not to rewrite the envelope sender > There's no great solution to this problem. (...) ARC is the > theoretical solution to this, where it can forward auth > information, but how to handle the forwarded auth information is > still a work in progress. There is a really simple solution for these Gmail customers getting their forwarded mail rejected. But it lies on Gmail side. Gmail already knows that the account of bl...@gmail.com is linked to the mailbox bl...@example.com, since bl...@gmail.com is configured to allow sending as bl...@example.com. It should thus detect that the email received from mta.example.com with a "To: bl...@example.com" is a forward requested by the user, and not reject it at the gateway when it fails SPF. Or, in order to have a stronger command from the user and avoid forward-guessing, at the cost of a new configuration setting, let the user configure a list of IP addresses from which they are forwarding mail to their account. Then Gmail could clearly recognise what is actually happening: that the connecting IP adddress belongs to a border MTA of this user, and then walk Received: headers to fetch the actual IP address that delivered it to bl...@example.com, which is the one that should be taken into account for a proper evaluation. This is something that should be implemented by everyone. If you are forwarding messages to somewhere else (and expecting to receive them!), you should configure the *receiving* side to recognise it as such. Sadly, no end-user provider seem to include this setting, so it ends up being only an option for those running their own systems. ☹ Even on corporate systems, where they have a filtering mail server at the border, and their postmasters should know better, it's not that uncommon to find out it is misconfigured and the internal MTA is treating every mail as failing SPF. Regards _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
