Michael Adkins wrote:
What is the basis for requiring it to be external.
Where the signer wanted reports about the message to go at the time the
message was sent is not relevant. Where the signer wants the reports to
go at the time the report is generated is relevant. It is common for
there to be a week or more delta between sending the message and a user
submitting a report. There is many a slip between cup and lip.
Oh.
Interesting point.
Anyone disagree with it? If so, how and why?
The presence of a header field that is signed does not guarantee that it
was placed there by the signer, merely that it was present when the
message was signed. It therefore does not provide a mechanism for
verifying that the requested destination address is authoritative for
the domain.
Oops. Right. I keep raising the same point about whether contents are
validated
by DKIM. Sigh.
So, there's a Pandora's box that this raises, which is how to use DKIM in a way
that has the semantics of claiming that bits of contents are in fact valid?
Also, this is a policy statement by the domain. Their policy is that
automated abuse reports should be sent to a specific address. My
understanding of the current model for stating domain policy (as with
ADSP) is a published record that can be queried.
I don't recall that ADSP is meant to lay claim to the entire space of such
declarations. So the precedent that it does some of it ought not to dictate
the
'venue' for communicating the next bit; that decision ought to hinge on
whatever
semantics, efficiency and validity issues apply.
If the address is not in the signing domain, then we need some kind of
'acceptance of delegation' record for the destination address' domain.
I was careful to specify the relationship among the domain names,
specifically to avoid delegation issues. It's not that they are
irrelevant, but that I'm hoping they are incremental. Let's get the
core details right and then we can enhance it to cover things like
delegation.
Delegation is the first real stumbling block these efforts always hit.
(I blame ReturnPath. ;)) If we are serious about it we need to make
sure that we have plan for how to handle it from the start so we don't
paint ourselves into a corner.
I think this is where we disagree. I feel that the trust requirements
don't need be part of the core details but delegation does.
ack. fair point to debate.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html