John,
On Wed 14/May/2014 14:39:40 +0200 John C Klensin wrote:
--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely wrote:
Will the admins go marching in?
At the risk of repeating myself...
(1) I think it is a bad idea for the IETF to be formally
spending effort to work around damage caused by a non-IETF
protocol. I note that, if this were a protocol that was
specified in the IETF and over which the IETF had change
control, we would be trying to fix the protocol itself or would
withdraw or depreciate it because of the damage caused.
That sounds like yet another instance of the not-invented-here
syndrome. FWIW, much the same solutions were put forward for ADSP.
IETF or non-IETF, the difference seems to be that DMARC currently has
more traction and deployment than ADSP ever had.
(2) I believe it is unacceptable for a new protocol or
capability to impose costs on operators of other systems in the
absence of clear and broad consensus about why the changes are
needed and appropriate. That consensus may well exist for DMARC
and its policy statements among the contributors/ supporters of
dmarc.org, but it is fairly clear to me that it does not exist
in the IETF. Contrast that with, e.g., privacy issues about
which there have been consensus statements in the IETF, perhaps
even statements strong enough to justify some additional costs.
Getting a rough gauge of consensus is exactly the reason why I wrote.
I'm less confident than you on the opinion of DMARC people, since a
change in DMARC is implied. I noted some inclination toward
reasonable changes from a few ML admins on this list, though.
Let me make explicit it is not consensus on DMARC we're talking about.
It is consensus on the workaround and the demonstration.
(3) Since I mentioned privacy, I should note that developing,
keeping, and maintaining the database you mention could have
significantly more privacy risks than simple recording of
envelope information in server logs. If IETF is now committed
to privacy as a significant goal, that question needs careful
evaluation.
That's why the DB has to be build by hand. Although I doubt it is
realistic for users to hide out from their mailbox providers, I agree
special care is needed. For those who trust their mailbox provider,
it is convenient to have it control their subscriptions. A possible
method to automate that task was called water-tight-opt-in[1].
[1] http://fixforwarding.org/wiki/Water_tight_opt-in
Doing nothing will result in a mix of three reactions. 1, ML
admins changing the From: of domains who publish strict DMARC
policies; 2, some users changing mailbox provider; and 3,
less domains publishing strict DMARC policies.
There are two more options you didn't mention: (4) more systems
either not implementing DMARC or ignoring strict policy
specifications, and (5) driving some users and activity away
from the use of mailing lists entirely in favor of using more
"social network" web sites and activities.
Thanks to you and Ned for completing the analysis.
I note that some people believe that DMARC and strict policies are
part of a business model to force that result. I don't believe
that personally, but the optics are unfortunate.
Me too. Spam is the selective pressure.
The combined effect seems to weaken both DMARC and mailing
lists.
So? Perhaps we should be focusing more on strategies that
weaken DMARC to the degree necessary or appropriate without
weakening mailing lists or imposing added costs on those who
operate or subscribe to them.
I'm not sure it would be good to go for a head-on collision, even if
we were granted getting out safe. For another inexact analogy, we let
SPF die down that way. Had we agreed on a viable compromise, perhaps
we would have enjoyed less spam, who knows? Now DMARC comes harder.
The question is when the next will come, and whether it will be so
better as to be worth the while.
Yours
Ale
The analogy is obviously not exact, but, if some external group
came up with a protocol that weakened TCP [...]