Re: Mailing lists - assumptions

Theodore Ts'o <[email protected]> wrote:
    >> These ideas about mailing lists have been rattling around in my head these
    >> past couple of days, and they're based on a bunch of design assumptions. So
    >> I figured I'd post my list of assumptions and see if anybody thought any of
    >> them were off in space.
    >>
    >> 1. The mailing list itself is going to have to participate in this in some
    >> way. There's no point in trying to design something for mailing lists that
    >> simply will not make any modifications.

    > We need to answer the question, explicitly, about whether or not the
    > sites which are currently honoring the DMARC p=reject policy can be
    > assumed to adopt whatever we come up with.  Because if the answer is
    > no, then your assumption/requirement #2 is flat-out impossible:

There will be some adoption, and perhaps some sites that will not adopt.
I care about the next 10 sites that want to turn on p=reject, not the one
that already did it.  While I'd like those sites to adopt, for me as a
mailing list admin,  there is a serious win if I can reduce the amount of
spam that goes into the moderation queue.

    > And even if eventually all of the DMARC p=reject sites (both the ones
    > setting the p=reject policy, and those that are honoring the p=reject
    > policy) will eventually climb on board, there is still the transition
    > window period that needs to be considered.

    > What I'm currently thinking about hacking together is a scheme where
    > the mailing list server will rewrite the from field to something like
    > this:

    > From: user+originatingdomain.example.com@dmark-remediation.mailing-list.org

    > .... where dmark-remediation.mailing-list.org is an MX record to an
    > automated bounce server that will explain to the user that they need
    > to really send their e-mail to [email protected] via
    > a 550 error.

I understand that you might want to do this in your context, and I accept
that it might work for you. But I don't want to do this for @ietf.org lists,
for instance, I want @ietf.org lists to honour p=reject, and reject the
message immediately.

    > That's because I'm assuming that the DMARC sites are going to be
    > intransigent, at least in the short term, so at least for some period
    > of time, possibly forever, I'm going to need to work around sites such
    > as yahoo.com.

    > If we go down this path as a long-term solution, as opposed to just a
    > short-term hack, we could imagine MUA's doing automated rewriting of
    > the from field to handle replies, and automatic address book
    > population.  Yes, it's an architectural hack, but so are NAT boxes,
    > and see how long they have lasted....

If we can assume any changes to the MUA, let's assume that they make sensible
changes that we document.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUBU1JyeoqHRg3pndX9AQLm4wQA6GhQj+0cDdW3egAKJ8wRmjR1FOUCjl0m
0IkadsPTt7A+ptyUsqqHNjD14CqYp0Pp9phATMYepSy85r1VoLWBcgc+1vPPJs+D
2xED4N65GaIrAcMGwWJAmckulkFHXLvHxjc+ORaYo5UYy5F2CUTYsfiS3UqIDbyw
a3kPNpERYbo=
=CPRj
-----END PGP SIGNATURE-----