Ned,
I don't see this as a big technical problem. The engineering has been
done. For the most part, not to over simplify, this was a battle
between two camps:
DKIM + POLICY (1st party author domain) framework
DKIM + TRUST (3rd party signer domain) framework
DKIM is a trust model. It was unfortunate, by design, the Policy
Semantics were pulled. The trust advocates "won the war" by finally
making ADSP historic to make room for DMARC where the focus was mostly
about Reporting. Even with ADSP, we were collecting information but
it lacked the reporting part, unlike early versions of the policy
proposals. But DMARC reporting was richer.
But this DMARC did have a similar handling logic it learned from SSP,
DSAP and ADSP. It was odd but I presume the IETF believed DMARC
p=reject will not be used as much as they strongly believed the
equivalent ADSP dkim=discardable policy would never be used or
honored, and if so, in a small insignificant way.
YAHOO changed that mindset and reality. Did they ever! In my book, as
I always knew this lost of policy focus would have to be corrected
some day. Yahoo has forced the issue. Policy wins.
To me, both TRUST and POLICY are needed.
POLICY is just a first level filter of the most obvious domain
practice faults. After policy passes the test, the trust layer comes
in. After all, for DKIM trust query to be activated, the signature
must exist and be valid per specification.
But just with using trust, Yahoo could of used the signer domain as
the DKIM specs wanted it to do in the first place to lookup some
"trusted" whitelist or 3rd party service to see if the signer domain
is a "good guy." It could of also accepted and quarantined the
message allowing the user to white list the signer domain. Yahoo
online mail UI can offer the user a "DKIM whitelist" input field.
Yahoo can keep this to itself or it can create public ATPS records, if
it makes sense.
DKIM also has the Agent or User Id (AUID), the i= tag in
DKIM-signature, that can be used as some MLM signing method. I think
we need to explore this again.
But ultimately, the author domain policies should be honored as the
first layer check before trust can even come into play. That mindset
needs to be accepted.
The hard part is going to be getting the same folks to change their
tune about how the Author Domain fits in with DKIM specification. The
DKIM abstract says:
DKIM separates the question of the identity of
the Signer of the message from the purported author
of the message.
Impossible. I always wanted to know which "question" that was.
5322.From is the sole single technical requirement to be hash bound to
the signature. There will always be an authorization relationship.
--
HLS
On 4/17/2014 11:46 AM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
On Apr 16, 2014, at 11:00 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
On Sat, Apr 12, 2014 at 4:35 PM, <ned+ietf@xxxxxxxxxxxxxxxxx> 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