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(_at_)sandelman(_dot_)ca http://www.sandelman.ca/ | ruby
on rails [
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-