> > 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.
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. 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. >> 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. > > > d/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
