Tony Hansen writes:
> I would love to see that list of multiple mitigations shared with the
> broader community. That would be useful information for people in the
> IETF,
I've shared it here in various levels of detail more than once, and
sooner or later it will be in the Mailman FAQ as I'm sure that the
brief descriptions in the admin UI will need amplification.
Basically, Mailman provides two orthogonal features:
1. Whether to mitigate, and when to mitigate, that is the question
a. Don't.
b. Always.
c. Only for posters from DMARC "p=reject" domains.
2. How to mitigate:
a. Replace poster with list in From:, and diddle Reply-To so that
reply-to-poster is as convenient as possible.
b. Wrap the message in a MIME message/rfc822 body.
Thanks to John Levine, we'll eventually have a 2c option: append
.INVALID to the poster's mailbox in From:.
> as well as other MLM teams not involved wherever those discussions
> occurred.
AFAIK there is no particular place where MLM teams meet up; there are
very few interoperation considerations. I would think other MLM teams
would be here now if they cared (cf John Levine's comment on your post).
> Perhaps there is one or more of those solutions that we SHOULD be
> recommending.
The only solution currently available I can see recommending is
banning domains that DoS third parties. However, that isn't going to
fly on many, probably the great majority, of Mailman and ListServ
lists. (Majordomo, smartlist, and whatever is used with qmail may
have a rather different user population, as is suggested by John's
observation.)
All the others have defects that some people consider severe, so will
have to be chosen by the list's administration.
> And perhaps broader discussions will provide an AHA moment where we see
> a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the
> face of a p=reject policies.
My personal belief (as previously mentioned) is that that is a logical
impossibility. But we can hope I'm wrong!
> Are the current p=reject semantics totally correct? As has been pointed
> out by others, even with mail sent out from banks, there are legitimate
> uses of mailing lists or things like mailing lists where you want copies
> to be received by multiple people.
The important thing is that the banks' problems with "p=reject" can be
solved (worked around, if you prefer) by the banks, without
cooperation of third parties, and without (much) harm to third parties
(it's unlikely that there are Mailman lists where 314 bank reps will
post to the same list in a week and so knock all subscribers into
disabled state).
While it would be as nice as getting a pony for the banks' tech staff
to be able to post to this list from the well-known domain, I don't
think that's very high on their list of tasks for their techies. Just
registering a "somebank-inc.com" domain is satisfactory, I suppose.
> Or alternatively, perhaps p=reject needs to be redefined slightly to
> take advantage of specific recommended practices for mailing lists.
Perhaps. I'm a fan of "simple protocols used judiciously"
vs. "complex protocols that try to forestall all problems" myself.
If complexity would make it possible for Yahoo! to use "p=reject"
without DoS'ing mailing list subscribers and their own posters, it
would be worth it, I suppose.
> > SPF and DKIM are now ancient history, at least as far as Mailman
> > development goes. We've already done what's technically
> > possible.
>
> Since I'm not privy yet to what all GNU Mailman has chosen to do in
> the face of SPF and DKIM, so I don't know how to evaluate that
> statement. Sorry.
>
> If you're saying that you've thrown out all use of DKIM, I consider that
> a sorry state of affairs.
No. What we've done is
(1) Put up a FAQ encouraging re-signing by MTAs hosting lists.
(2) Added an option to strip the (presumably broken, we don't check
for it) original DKIM signature.
There's no real point in MLMs doing more than that as it requires
cooperation from the domain's DNS. OAR (which I don't think is worth
it) could be done, but I think this probably is better done by the MTA
(local MUAs and admins might wish to refer to it).
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
