Thanks for your comments Stephen.
On 5/31/14, 1:51 PM, Stephen J. Turnbull wrote:
Tony Hansen writes:
>> 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.
A change to the protocol? What? I don't see it. The protocol
actually in use by many domains seems to actually do what it's
designed for quite well. "p=reject" makes a lot of sense for banks,
for example. I don't think it can be removed from the spec, and its
proper use doesn't cause widespread problems for mailing lists.
It's use outside the design space that causes problems. Those uses
are by desperate organizations, and they'll ignore any change that
attempts to prohibit them because they are desperate.
See further below.
> 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.
I'm sorry, but that's nonsense for the volunteer-maintained MLMs like
GNU Mailman.
That's okay -- it was just a thought. However, note that not all MLMs
are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it
might be useful.
We already have implemented multiple mitigations, and it
doesn't take much code. We just hate them all and leave it up to
mailing list operators to choose the one they dislike least. If other
MLMs haven't done so already, I doubt it involves all that much effort
for them.
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, as well as other MLM teams not involved wherever those discussions
occurred.
Perhaps there is one or more of those solutions that we SHOULD be
recommending. Perhaps a broader discussion might come up with some
additional better solutions.
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.
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.
There might be an alternative to p=reject that we can come up with that
*) WOULD work with mailing lists
*) if mailing lists also were to take certain steps, and
*) these organizations might be willing to switch to.
Or alternatively, perhaps p=reject needs to be redefined slightly to
take advantage of specific recommended practices for mailing lists.
> That's a political solution for this current technical problem.
Mailing lists don't have a *technical* problem. If DMARC were used as
designed, we'd never have noticed. The problem is political: we have
a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb
gorilla joining the fun).
> 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)
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.
We'll see what more our users want us to do about DMARC, if anything.
There just isn't anything technical to be done AFAICS.
I can't speak for other MLMs, but I think that if there's going to be
real progress, the answer is with the MUAs.
1. If identity alignment fails, *all* links, scripts, and forms in the
message should be deactivated, even if it's already in the spam
folder.
2. If there's a type=password field in the message, *all* links and
forms in the message should be deactivated, even if it's already in
the spam folder.
3. Ditto misaligned MIME type and file name.
4. Ditto active or unknown attachments.
5. On activation of the message, all href and src URIs should be
displayed clearly, along with an intrusive warning that ID theft is
very common, so the user should check everything carefully
(preferably call the author on the phone) before doing anything
suggested by the message, even if it's already in the spam folder.
I'm sure there are other things they could do, but those are off the
top of my head.
Finally, Tim Draegen is right, it's not just about mailing lists.
Let's not forget all the other use cases that are stomped on by the
inappropriate use of "p=reject".
I agree with all of the MUA comments.
Tony Hansen
Steve
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
