From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Murray S.
Kucherawy
Sent: Monday, April 14, 2014 1:54 PM
To: ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
Cc: ietf
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL
community lists
On Sat, Apr 12, 2014 at 4:35 PM,
<ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com<mailto:ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com>>
wrote:
The underlying technical issue is that the two technologies DMARC is built on -
DKIM and SPF - both attach additional/restrictive semantics to longstanding mail
system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)
Something's amiss here. What new semantics does DKIM attach to From:? As far
as I know, it only requires that the field be signed. It doesn't require that
it be interpreted in a particular way or that it contain any particular value.
It goes on to discuss the use of p=reject with domains that only send
transactional. AFAICT there is no discussion of when *not* to use p=reject, and
why. Nor, for that matter is there substantive discussion of mailing_list,
and why it's not a general solution to the problems caused by p=reject.
Yes, that's useful advice for a future revision.
Like it or not, the IETF published a draft that defines certain mechanisms
which, if used improperly by a large provider, cause serious problems for a
large number of people. The text describing the consequences of the use of
those mechansisms in the drafts is, IMO, entirely inadequate.
It's the same document that was posted on other web sites for some time, and
was in use by a number of operators (including Yahoo) long before it went into
the datatracker.
As it's only a draft, there's ample opportunity to make such improvements.
Also: By "the IETF published a draft", are you talking about an RFC, or the
DMARC base draft? It seems extreme to lay blame on the IETF in general merely
for having an open mechanism by which to post a draft for all to see and
discuss. A "Request For Comment", as it were. Are you suggesting that process
should be closed or moderated somehow?
And it's not like we didn't know. As others have pointed out, this issue
existed in the earlier ADSP proposal. It was given insufficient attention there
as well.
MH: I’m going to disagree with your statement about insufficient attention Ned.
I’ve been reviewing the discussions from the DKIM working group at that time
(early 2008) and there was in fact quite a bit of attention given to the issue
in the context of SSP and the discussion got quite heated. One such discussion
at that time was “RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of
SSP tounsigned messages”. One position in that discussion was that mail lists
could be trusted and therefore should supercede any policy assertions by domain
owners made through SSP (which name was changed at my suggestion because the
standard represented domain policy assertions and not individual sender
assertions). The discussion of mail lists in the context of email
authentication has been exhaustive (both literally and figuratively) on
multiple occasions and in multiple places for some time frame approaching a
decade if not longer.
As with any draft, its content is only as good as its contributions and the
reviews it got.
MH: The reality is that there was a compromise to get ADSP set and out the door
with the understanding that once there was some experience running in the wild
“we” would circle back and remediate identified issues. It was a bad compromise
and there were even some that stated at the time, the compromise was intended
to kill ADSP. If I had it to do over again I would be more resistant to
compromise regarding the MLM issue even if it had meant ADSP not getting out
the door.
Of course the IETF can fall back on the usual excuses, including, but not
limited to:
Yahoo, of all ISPs, should have known better
We don't tell people what to do
It was just a draft
It was never intended to be a standard
We're not the Internet Protocol Police
etc.
I'm sorry, but this time none of these dogs are hunting for me. An attractive
nuisance is an attractive nuisance, and this is what the IETF has, albeit with
the best of intentions, managed to create.
I would add to this that, by its ultimate inaction in the face of a protracted
period of abuse and attempts by participants to solve that problem within its
procedures, the IETF has abdicated any authority it may have had.
MH: I’m not sure I would go this far but I think it reflects concerns held by
many.
The real question we should be discussing is what options the IETF has to try
and address this.
I certainly agree with that.
MH: First there needs to be a consensus as to what “this” is before there can
be an attempt to address “this”.
-MSK