On 5/28/14, 6:46 PM, Barry Leiba wrote:
Anything that requires mailing list software to change won't work.
I'm going to push back on this statement. I think we keep getting stuck
on the mantra that "the mailing list software won't change". However,
the majority of the mailing list software packages that are out there
now DO generate proper List-* headers. It took some time, and it may not
be 100% coverage, but by gosh and by golly, most of them do so and do it
correctly.
Why? There were a few things: 1) a well defined spec about what change
was desired, AND 2a) there was perceived benefit to adding those
headers, or 2b) there was perceived harm in not adding those headers.
If mailing list software is changed, the right answer is for the mailing
list to re-sign the message.
I think this is exactly the correct solution for mailing lists to
pursue. This is an excellent start of a spec for what mailing lists
should be doing in a world where systems are using DKIM and SPF, and
more systems are expecting such mail to pass validation. (A post-DMARC
world, if you will.)
There may be alternative solutions that are less optimal that will also
get mailing list messages delivered more reliably. (For example, delete
all DKIM signatures and force the From: header to use the originator's
name in the comment but with the mailing list address instead of the
originator's address. It works, but isn't pretty.) It might be worth
doing some investigation of those alternatives, and showing their
advantages and disadvantages.
Mailing lists have an expectation of being able to get their mail
delivered. That is no longer the case. The benefit of them making
changes is that their messages will get delivered more reliably. The
harm in not making changes is that their service will continue to be
unreliable.
But clear specs detailing what they CAN do and SHOULD do is the starting
point.
That doesn't help the DMARC situation
now, but DMARC could be given other options once that happens.
I agree completely that a change to DMARC is needed in conjunction with
having clear ML specs.
When HeartBleed came out recently, it was discovered that openssl had
rather poor support, even though everyone and their neighbor seems to
use it in some fashion or another. A consortium was then formed to
provide some needed support and to improve the quality control for openssl.
I've heard it said that the majority of the mailing lists out there are
managed by only a handful of ML management systems. I maintain that
these ML packages are in the same boat as openssl. It sure would be nice
if we could get some of that consortium money thrown at that handful of
ML management systems. That's a political solution for this current
technical problem.
However, before it can happen: we NEED clear specs as to what should be
done by ML systems, at least in the face of DKIM and SPF (and DMARC)
Tony Hansen
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
