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