Two inline thoughts. > On Apr 30, 2022, at 4:48 PM, Ángel via mailop <mailop@mailop.org> wrote: > > 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.
What’s the threshold for not forwarding? If a user is at some point used to receiving all mails, but with SA’s default score of 5 tagged with a standard *****SPAM**** header, or an X-Spam-Status header, gmail should easily recognize that it’s a forwarding account. There are going to be false positives to a spam filter — and what should happen with those? They get not-forwarded and put in a mailbox on the forwarding server that the user literally never checks? Rejected at SMTP time, for fear of gmail? And then there are false negatives, which will make a forwarding server seem more spammy, unless *my* spam filter and *gmails* are in perfect harmony. To the point that when I send a new mail to a gmail user, it’s routed to the spam folder, because “Lots of mail from prime.gushi.org <http://gushi.org/> is spam”. Seriously. With nothing showing in postmaster. There’s a couple of very standard headers that the common open source filters add (spamassassin, crm, dspam). Gmail could trivially recognize upstream spam filters (per sending-host) and act on them. They choose not to. […] >> 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. If you’re already doing DKIM and SPF anyway, arc is another milter in the chain that gives you that benefit. (You want it after your DKIM and DMARC validators). You can leverage your same DKIM keys to use arc (or a different one), but it’s largely the same idea. Right now nobody is validating arc, but this is largely because nobody’s signing/sealing with it…because nobody is validating it…because nobody is signing/sealing with it….someone needs to move first. Unlike DMARC with p=reject or spf with -all, there’s no harm in adding an ARC signature. There’s no DNS record that you put in ARC (other than for the domainkey) that says “if arc fails do this” and the ARC rfc does not extend DMARC to change its action. I spent arguably an hour tweaking it and turning it on both on $dayjob’s mail entry points and on the sending-end of our mailman 2.x server. If more people start looking at that info, we’re ready. Right now, one of the best things gmail could do is when you say “view original” for a message, in addition to showing the SPF/DMARC/DKIM status at the top, show the arc status too, at the top of the page. Make people more aware of ARC. Gmail pushed ARC as a solution, and yet it’s not advertised to users as something that they should see passing. That said, if you have a gmail account for testing, you can see the arc=pass or arc=fail results of mails you forward, down there in the headers.
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
