On Mon, Aug 15, 2016 at 7:10 PM, John Levine <[email protected]> wrote:
> >And they WANT to be able to choose whether to get spam mails tagged and > >have them delivered to their account where they can process them with > >their own filter rules and maybe report them. > > Then you should deliver them to local mailboxes from which they pull > the messages using POP or IMAP. Any sort of SMTP "this is spam but > deliver it anyway" won't work since spammers can set it, too. Or do a > hybrid where you forward the stuff that has very low spam scores, so > they get it fast, and deliver everything else locally where they can > poll eventually. I have users who do that and it works pretty well. > We were debating an X-Spam header which would deliver directly to the spam label without using the message in our "is spam" learning. This would match what our support pages say about putting SPAM in the subject, which I don't think we've actually listened to maybe ever, and without the authentication breaking properties of touching the subject. There is the class of spammers who seem fine with getting as much mail as possible in the spam label, with the assumption that enough folks will check their spam label and click on the links anyways. We'd probably need to have more complicated rules of when to listen to the X-Spam header, of course. Is there some other issues with a "deliver to spam"? My prefered solution is to bring an "inbound gateway" setting to consumer Gmail, but that's a lot more complicated. It's also possible that with ARC, you wouldn't need the SRS and we could better learn forwarding on a per-user basis, and so we'd just know it's a gateway. > >So how do I solve that customer need in the best possible way? > >Forwarding without some kind of SRS just does not work with all the SPF > >protected domains out there (our own domains are also SPF protected > >which cut of a lot of spam and phishing emails to our customers). > > Maybe things are different in the US, but around here, I don't know > anyone who rejects on SPF failure other than a plain -all for we send > no mail at all. If you want to do phish detection, sign your mail and > use DMARC and hope your users don't subscribe to many discussion > lists. > Agreed. I have seen a couple non-US banks with a DMARC p=REJECT policy and no DKIM signatures, relying only on SPF. SRS won't solve that problem, though since it won't align. In general, Gmail won't reject based on an SPF failure (except -all), though it can cause spam rejections on the margins. And for Gmail, it's probably better to keep the envelope sender the same and not use SRS. Brandon
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
