I've told any of my users to not forward to gmail instead, but rather to just use their pop-fetcher.
Two problems I had there. 1) Not a goog issue, but Microsoft effectively discontinued this feature for hotmail, for some reason, so it's not universal advice. 2) Gmail started hitting MTU/ipv6 issues with my system, and the error they presented to the user was useless (and in fact, cut off mid-sentence in the Google UI). My solution was to create a v4-only hostname and v6-only hostname, which required reworking all my certs. The bigger problem here is that there's no place a regular gmail or hotmail or ($freemail) user can reach out to for help. -Dan > On Apr 28, 2022, at 12:58 PM, Scott Mutter via mailop <mailop@mailop.org> > wrote: > > Automatic email forwarders are generally a bad idea, at least in my > humble opinion. > > They're always going to fail SPF unless you rewrite the > sender-envelope, which I also don't think is a good idea. > > Ultimately, the argument generally comes down to "well, these used to > work" and that's part of the problem. People expect everything to > work just like it used to - but they also want to gain all of the > benefits of newer anti-spam/anti-phishing components. That's just > simply a false narrative. > > I'm not sure what specific mail system the user is using, but my > suggestion would be to set up the address to collect into a local POP3 > mailbox on the same server that's doing the forwarding. Then > configure your Gmail account to POP mail from that POP3 mailbox. This > side steps the issues of SPF failing, while also allowing the user to > remain exclusive to their Gmail account. > > On Thu, Apr 28, 2022 at 2:02 PM Brandon Long via mailop > <mailop@mailop.org> wrote: >> >> 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. >> >> There's no great solution to this problem. Theoretically, one could try to >> walk the line and rewrite the sender for some messages where you think it's >> not spam but having no auth causes issues ... though it won't work for say >> domains with DMARC since there has to be alignment. >> >> 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. >> >> In a long ago thread, we discussed the benefits of doing both forwarding and >> pop fetching, to handle the edge cases. >> >> Brandon >> >> On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop >> <mailop@mailop.org> 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??? >>> >>> Is it that the message sender's domain has a DMARC setting or some such >>> that gmail is using and that my server (which is just forwarding the >>> message) is failing? >>> >>> If so, how is someone supposed to forward messages to gmail??? >>> >>> Thanks, >>> Geoff >>> >>> _______________________________________________ >>> mailop mailing list >>> mailop@mailop.org >>> https://list.mailop.org/listinfo/mailop >> >> _______________________________________________ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop