Michael Adkins wrote: > Please, let's not drag message header fields into this. That's an > unproductive path. (and by unproductive path I mean I will never send an > ARF report to an address just because it's listed in a header field, > signed or not)
Mike, Please review the summary. It was not "just because it's listed in a header field", but the listing was within a larger trust and authentication context. Very different beast. > If we want to make FBLs (reports back to the signing domain, not the > mailbox provider) easier, then we need a record we can lookup to find a > report destination email address. The choice between within-band (in the message) and out-of-band (e.g., DNS record) should be determined by efficiency and/or trust. Out of band is mostly used for matters of trust, such as getting the DKIM key independent of the message that it is used to validate. The summary I gave accomplishes the necessary trust by validating the associated identity with DKIM, and b) consulting whatever assessment/reputation mechanism is deemed sufficient. Even with an external listing of the ARF address -- such as via a DNS record -- you don't have the necessary trust basis for believing that the address should be used. Note that I claimed that the current FBL registration mechanism is for both authentication and trust. If I've got that wrong, let's figure out what it should say that is right. After all, I did say the summary was primarily intended for you guys to fix. Not 'reject' but fix. > If the message is signed, great. We can check some kind of RR for the > signing domain to find a destination address. If it's an address within > the signing domain, then we send the report and call it a day. If the > signing domain does not list a destination address, then we don't need > to send a report. What is the basis for requiring it to be external. > 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
