--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
After some discussion on ietf-822, two viable methods were
identified for DMARC for mailing lists (ML). Someone cutely
suggested to do both:
*Tweak DKIM signatures*
...
*Whitelist*
...
Both methods require each domain to build a DB of MLs. That
can be done by a "manual process" (see picture) for the time
being. The process consists of each ML admin extracting a
per-domain list of subscribers and sending it to the relevant
...
Will the admins go marching in?
Ale,
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.
This misrepresents the situation so substantially it is essentially a strawman
argument. In particular, DMARC did not emerge, full formed, out of the void.
It's the logical evolution of ADSP, a standards-track IETF protocol.
In fact an argument can be made that in terms of responsible mail handling,
DMARC is actually an improvement over ADSP. In particular, ADSP provides policy
choices of "unknown", "all", and "discardable", wheras DMARC provides "none",
"quarantine", and "reject". Honoring a "discardable" policy causes mail to be
lost, whereas at least "reject" provides an indication that something went
wrong.
The fact that ADSP was developed in tandem with DKIM also means that the IETF
cannot reasonably claim that attaching these sorts of semantics to From: fields
was in any way unexpected. As such, there was at least a resposibility to
document likely interoperability problems use of DKIM in this way would cause.
But let's suppose for a moment the assertion that this is simply a case of a
non-IETF protocol coming at us out of the blue. I still categorically reject
the assertion that it's not our responsibility to address the issues it has
raised. Our job is to write documents that improve email.
Of course a line has to be drawn somewhere; the IETF can't possibly respond to
every single stupid thing that people do on the Internet. But when three of the
largest MSPs in existence decide to publish problematic DMARC policies and
large numbers of email receivers have implemented DMARC checks, resulting in
widespread damage, and subsequently refuse to reconsider those policies, I
think the line was crossed.
(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.
The "new protocol" of which you speak is, in fact, a combination of three
pieces: DMARC, SPF, and DKIM. Two of thoese are standards-track protocols, and
one of those (SPF) has a built-in policy mechanism which, if used, most
assuredly does "impose costs on operators of other systems".
And as I noted above, it's not like the IETF didn't publish ADSP on the
standards track, or that this usage of DKIM was a surprise.
So it seems that the IESG felt there was an IETF consensus in this area.
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.
(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.
Good point. I don't think the database approach is remotely viable for other
reasons - mostly that I've yet to encounter an ISP or MSP willing to take on
the task of building and maintaining such a thing - but the privacy aspect
do warrant some consideration.
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.
Or 4. ML revoking the posting rights of users from domains that
report policy errors. Or 5. Rather than unsubscribing the failing
recipients, either ignore the error or report the failures to the
original message sender, thus making it clear to them the cost
they're paying for the provider they have chosen.
Except in order to do either of these well you need some additional status
codes, codes which only the IETF can assign. (And yes, I'm aware that a ML can
perform its own check on the From: domain and if it lists a reject policy
refuse the mail, thus avoiding the need for new error codes. Except that's both
a lot more work with a less reliable outcome.)
The good news, such as it is, is that the relevant registry is "Specification
Required", meaing this can be done in the DMARC base specification or some
other informational RFC. Which I guess would avoid significant IETF
involvement.
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. 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.
I'll note that "ignoring stricy policy specifications" is not necessarily
a good thing. Having a DMARC failure contribute to an overall spam score
can easilt lead to mail being silently lost instead of being rejected,
with all that implies.
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.
Well, yeah, that's kinda the point of this exercise.
The analogy is obviously not exact, but, if some external group
came up with a protocol that weakened TCP and undermined all of
our congestion control mechanisms, we might be pointing out the
damage and encouraging people to not use that protocol --
perhaps even figuring out ways to block its use -- but would not
be scurrying to alter TCP to better accommodate the behavior of
that new protocol, especially if the alterations made "normal"
use of TCP less efficient or effective.
On the contrary, if the protocol that external group came up with was widely
deployed and there were reasonable tweaks that could make them coexist, I think
that's exactly what the Transport Area would do.
Ned