On Apr 16, 2014, at 11:00 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
wrote:
On Sat, Apr 12, 2014 at 4:35 PM,
<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.
I was trying to be brief. Yes, I'm well aware that DKIM can be used in other
ways. This entire discussion is within the context of DMARC here. Do you
disagree that DMARC's use of DKIM and SPF assign additional semantics to
header
and envelope from fields respectively?
Murray is correct. DKIM does not create special From header field semantics.
Actually, by requiring that the signature cover the From: field, it sort
of does. But that's beside the point. Again, I was talking about DMARC's
use of DKIM, not DKIM usage in general.
However, DMARC semantics are similar to those of ADSP while avoiding some
shortcomings.
But both of them attach additional semantics to From:. (Not that they had
a choice; as I pointed out previously, in order to acheieve the stated
goal they have to attach the check to the identity users actually see.)
...
Also: By "the IETF published a draft", are you talking about an RFC, or the
DMARC base draft?
The draft, of course.
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.
You may think it extreme. I don't. I think the IETF's politics have led to
it
inching closer to moral hazard territory for a long time, and with this
incident it has stepped in it.
This disruption should be shared with the provider that has already
enumerated 30,000 mailing-lists but made no effort to establish a means to
verify these sources and to safely assert specific exceptions to DMARC
alignment requirements. This ability is desperately needed before applying
DMARC reject on user accounts. I'll be happy to modify either ATP or ATPS to
permit these exceptions without the need to alter mailing-list.
I'm by no means sure that ATP or ATPS is the right answer, but I certainly
agree that we need to at least try and address the situation that's been
created.
Sigh. We have a lot of work to do, don't we?
Ned