reference quibble...
On 4/16/2014 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?
Not really. In fact, I fear that that's a bit like saying that TCP
makes IP a reliable, byte-sequenced protocol...
Rather, DMARC defines its /own, additional/ meaning, but it does not
change DKIM or SPF. They do what they've been doing for quite awhile.
DMARC does something /more/.
Essentially, DMARC takes the domain name used in DKIM d= and/or SPF
"protected" rfc2321.MailFrom and invents a new requirement, namely that
that domain name be the one used in the author's rfc2822.From field's
addr-spec's <domain>.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net