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