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
