On 04/14/2014 07:53 PM, Murray S. Kucherawy wrote:
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.
As with any draft, its content is only as good as its contributions
and the reviews it got.
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.
This might have been true if:
1. Yahoo _did_ solve the abuse problem and
2. the decision making process within a closed industry consortium with
maybe less than 20 members, representing immense commercial power, could
be compared to the process of consensus, that's being used within IETF.
Ad 1. Yahoo only solved some of the problem, for some time and only for
themselves. But we have seen that bad guys have adapted faster than
anyone else to new technologies:
- 90% of all mail agents show the display-name in the From field and
with the current move towards mobile devices this percentage will likely
further increase;
- Yahoo doesn't use the From:From construct to enable receivers to
detect use of multiple From: fields;
- developments like EAI will help bad guys to find lookalike
domains/cousin domains [1], [2]
Ad 2. I assume this doesn't need further explanation.
/rolf
[1] http://www.ietf.org/mail-archive/web/dmarc/current/msg00370.html
[2] http://en.wikipedia.org/wiki/IDN_homograph_attack