Agree with your assumptions ( and the later point that receiving person can't controls what their admins do any more than sender can control what their admins do) But there are two failure modes for something like this 1) sender knows their email was not received 2) email was not received by a bunch of people and neither the sender nor receiver knows that The second failure mode is much worse than the first. > On Nov 2, 2016, at 3:58 PM, Brandon Long <blong@xxxxxxxxxx> 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. > > 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. > > 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+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 =- > > > > > _______________________________________________ > dmarc mailing list > dmarc@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dmarc > >