Regardless of how/if/why/when we process DMARC as a specification, we need to decide how ietf.org MTA is going to deal with things. 1) someone has to fund changes to mailman, and perform testing, installation, and community education for the IETF mailing lists. That implies that we have to decide *for ourselves* where and how we will "break" the DMARC/DKIM connection, and if we will reject email from p=reject senders before we attempt to relay. 2) there are a number of things which are not mailman lists, but aliases, which get *no* reprocessing of any headers at all. This includes, I think, "iesg", "iab", "iaoc", *AND* why I suddenly care again: "nomcom14-coord" yes, at least one member of nomcom has an ISP that processes DMARC, and I think two members of nomcom send email from p=reject addresses. The experience is that some senders get rejected by some recipients, but other senders do not. It felt at first, like some bizarre kind of censorship. The confusion is confounded because I think some DMARC processors (gmail.com?) may have already whitelisted ietf.org MTAs, while others have not. (3 - I'm still looking for confirmation that we a suffering on nomcom14-coord from DMARC) So, again, I'm not interested in what we might specify as an SDO. I'm interested in what we are going to *do* as an entity. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works -= IPv6 IoT consulting =-
Attachment:
pgpTJlhp5aOvp.pgp
Description: PGP signature