On 2022-04-29 at 10:28 -0700, Brandon Long wrote: > There have been other reports on this list of Gmail requiring > authenticated email. > > We don't require authenticated email... but we vastly prefer it, and > that preference has only increased over time. And the dkim replay > attacks have meant increasing the scrutiny of messages which are dkim > authn but not spf authn, which of course can hurt forwarding. > Forwarding is getting the short end of the stick in that > toss up. > > The above rejection isn't for the dkim replay case, of course, it's > for no authn at all.
Yep. I completely understand it's not authenticated. The problem is, it's out of our reach to authenticate that third party email. It's the recipient who wants to receive it. > SRS style rewriting allows the forwarder to get feedback if the > forwarding destination address goes away, > and do bounce handling... > and prevent bounces from going back to the original sender, exposing > the destination address. There are good reasons to do the rewrite, > but not as likely for the average procmail user, and having a good > spam filter that doesn't forward is very important. We do some hoops here, in that we provide the original envelope to the forwarded mail server, but it if refuses to accept it, we send the bounce to the forwarding account, not to the original sender. :) This not only avoids leaking the information about forwarded accounts, but also confusing the senders. >> Gmail guidelines explicitly ask not to rewrite the envelope sender > > Yes... and gmail forwarding does ;). Mailing lists do as well. Should we then do as-it-does rather than as-it-says? :) If gmail has changed its stance, messages could be forwarded with a different envelope sender, but I suspect it wouldn't be happy either, as it would then show an envelope suspiciously unrelated to the content. > > > 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. > > Heuristics like this have been used in the past, but spammers often > figured them out. I was initially going to suggest that it was received by any server passing SPF for the configured external account, then noticed that perhaps that didn't work so well with those large SPF records, and mentioned just that To: (just an example, it could e.g. be detected through headers as well) but it really should have mentioned "from the right server". > > 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. > > Yes, this is how workspace handles this, you would just set the list of IPs > as > the inbound gateway. Even then, there are cases like outlook.com/O365, where > the list of possible IPs is very high... or forwarding gmail to gmail, for > that matter.. Allowing users to set this as well would allow users to fix this issue where gmail would otherwise reject the mail they want forwarded. At least for those coming from a small set of ip addresses (although large ones probably use a forwarding pool). > An even better one would be ARC, it would be pretty easy to specify > one or more ARC ADMDs as trusted forwarders on a per-user basis (or > for workspace admins). > > This suffered from a chicken/egg problem on top of the general > "hard for most users to understand", and the general small usage of > regular forwarding... > the better option was to generalize the benefits of ARC to all users > automatically... but that work is still in progress. ARC would indeed be a more complete solution. However, I suspect this may be one of those cases where perfect is the enemy of the good. Specially since this doesn't solve the issue of which ADMDs to trust. I agree about the general problem of "hard for most users to understand" how to fill out ip addresses or ADMD identifiers, but given the issue that they are actually missing messages, I think they would be more than happy with a working hocus pocus. Best regards _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
