On 21/07/2014 01:26, Michael Richardson wrote: > 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. I thought the preferred solution was to rewrite the From for those users only. > 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" I doubt if this is soluble in any obvious way. Brian > 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 =- > > >