Michael,
I couldn’t agree more, and this has been discussed multiple times on this
list. We’re still currently using Mailman 2.1.15, which goes back to 2012.
The current 2.1.x release for Mailman is 2.1.20, which is nearly a year
old. There’s also a 3.0.1 release from this past November. Either of those
can handle DMARC rewriting so that mailing lists continue to work. I’m
still not sure why we haven’t upgraded to at least 2.1.20.
Cheers,
Andy
On Wed, Feb 24, 2016 at 9:38 AM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
20 months ago, I asked the following question, and I am still unclear if
we have some plan.
https://www.ietf.org/mail-archive/web/ietf/current/msg88695.html
Again, I'm not interested what the best way to boil the DMARC ocean is.
I'm interested in the IETF cup of tea, as an enterprise, not as the
responsible SDO.
When I asked before, I was told that there would be results "soon", and I
should wait.
(I also would like to recommend that the 2016 nomcom be given @
something.ietf.org IMAP mailboxes, because DMARC makes receiving feedback
very difficult.)
So again, my questions were:
On 20/07/14 09:26 AM, 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 don't think we ever made a decision here. I'm pretty sure that we need
to make this decision regardless of what improvements are made to DMARC.
If someone marks their email as not for forwarding, perhaps we should
respect that. Some suggested that the lists refuse to have people on them
with p=reject policy.
My spam processor has just started processing DMARC, which will kick me
off mailing lists unless I disable it. Fortunately, that is an option, but
I think I have to turn off SPF to get it.
Has the tools cmte determined if mailman will be enhanced in the way that
we want?
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.