DMARC and ietf.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]