FWIW, I use Google For Work (or whatever it's called this week) and it doesn't automatically add DMARC headers--that's something that you have to configure, apparently. So while I think that gmail.com is probably a lost cause, if your org is using GfW, you don't have to use DMARC. On Wed, Nov 2, 2016 at 3:00 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: > > Cullen Jennings <fluffy@xxxxxx> wrote: > > So if someone send a email with a bad signature to an IETF list from a > > domain that has a reject policy, and the IETF server forwards it to my > > email email provider, my email provider rejects it. Now the IETF email > > server counts that as a bounce. Too many bounces in a row and the IETF > > server unsubscribes me from the list. > > > This does not seem OK that anyone can trivially send some SPAM and get > > me unsubscribed. > > yeah, that's a real problem isn't it. > > After nearly three years of yelling about this problem, we are not even close > to consensus that it's a problem, with many people suggesting that IETF mailing > list software should just munge headers. > > DMARC WG was supposedly designing a solution. I don't know where that is. > > My take is that IETF mailing list software should reject email from p=reject > senders, since that's their stated policy. > > The original threads include: > https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html > > > What's the right advice on how the IETF server should be run? > > > Now to a more detailed problem - Jana sends lots of email to the quic > > list. I don't get any of them. It appears that my email server (run by > > rackspace) rejects them with an > > > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for > > google.com (G15) > > > If Jana sends the email directly to me, it works. This seems to point > > at the IETF server is doing something that breaks signature in Jana > > email. > > Jana needs to stop sending from google.com. > > Their policy is that not to forward, so sad to lose all the google.com > contributors.... we really shouldn't violate their stated policy. > > > -- > Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works > -= IPv6 IoT consulting =- > > >