On 03/11/2016 10:58, Brandon Long wrote: > With the understanding that my email is unlikely to be received by some of > those having issues... > > Let us assume that those who specify p=REJECT have a good reason for doing > so, and that after 2-3 years, they are unlikely to change back. > > Let us also assume that the members of these organizations who are > participating in IETF may or may not have any power over whether their > admins have decided to be p=REJECT. > > And let us assume that we want these folks to participate in IETF.
Let me stop you right there. Yes, we want everybody to be free to participate in the IETF, and presumably those people want to participate in the IETF. But participants have to be able to use the tools that the IETF has chosen, which includes mailing lists. That's always been true. (In 1992, when I started in the IETF, it meant knowing how to subscribe to a majordomo list. Today, subscribing is a bit easier, but it means avoiding the DMARC trap.) So such participants need to use an email sending address that works with IETF mailing lists. yahoo.com and google.com don't work properly with IETF mailing lists. Fortunately, very fine alternatives are available, such as gmail.com. (gmail's spam learning is even smart enough to work around p=reject, as it did for this very message that I'm replying too.) I think Michael Richardson made a very valid point. If our mailing list software detects a sender whose domain has p=reject, we *know* that the forwarded message will fail DMARC validation. So there's a strong case for rejecting the message immediately, so that the sender can be told about the problem and can choose a different sending address. Presumably, we'd only need to do this until ARC is deployable. > > I will assume that if you're not willing to stipulate to the above, then > you don't actually want a solution. > > We are then left with only moving forward. > > If this is a problem for you as a receiver, you can choose to attempt to > whitelist the ietf mailing list mail from DMARC enforcement. You may not > be able to do so, just like the sender may not be able to change their > organizations DMARC record. > > The middle man, ietf, can work around this today. They need to run a new > enough version of mailman and enable one of the workarounds. For mailman, > this means munging the mail, usually the From header. It's not pretty, but > it works, it works now, and it will work for everyone. The difference is > mostly cosmetic, though depending on your mail client, there may be other > downsides. And it may violate RFC 5322. No, it's actually not cosmetic, for reasons that Dave Crocker pointed out. Regards Brian > I don't think this is possible with mailman, but theoretically it is also > possible for a mailing list to pass the message through without breaking > the DKIM signature. This means no footers and no subject tags. Which of > these a list would choose is probably dependent on the list members. > > mailman should also know how to tell the difference between a message > specific policy bounce, and particular DMARC bounces, and should apply > different heuristics to handling them. I have no idea if that existing in > any version of mailman or is a planned feature. > > There is a proposed standard, ARC, that would allow mail receivers to do > more intelligent whitelisting. It's not ready yet. > > It is unfortunate that these types of choices have to be made. > > Brandon > > > On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: > >> >> Cullen Jennings <flu...@iii.ca> 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+i...@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
