,---
|5.3.1. Negative Commentary
|...
|4. Concerns about conflation of responsibility and/or reputation:
| there are concerns of adding to the confusion about who is
| taking responsibility for what. Is it the d= domain in the
| DKIM-signature? Is it the domain in the From: address? Is it
| both? Is it neither? Keeping this simple by using the NS
| delegation mechanism would not raise these interesting, if not
| thorny questions.
'---
Perhaps the most basic requirement for any accrual is properly
attributing actions to the correct entity. What this means with
regard to DKIM must be kept clear. This statement indicates there is
confusion?
1- The recipient of the message (2821.Rcpt To:) is independent of the
entity defined in the To: or CC: headers.
Perhaps policy could change this assumption, but without being able
to associate these fields, the recipient can not hold the signer
accountable for having actually sent the message. For those domains
setting up trip-wire or honey-pots to identify bad actors, they need
to fully understand this limitation. Otherwise, a bad actor is able
cause serious harm to innocent signing domains.
2- Only the signing domain is verified when the signature itself is
verified.
While there might be external associations found in policy records
binding the email-addresses with that of the signing domain, only the
signing domain can be verified as being accountable. Only the
signing domain can be held accountable for any abusive content such
as malware or phishing attempts irrespective of any email-address
contained. When a signing domain is a bad actor, why trust them to
pass accountability onto someone else via an email-address?
3- Who Should sign?
DKIM should be allowed to naturally associate with that of the
sending domain. The contained email-address found in the
2822.Sender: or 2822.From: header fields or the 2821.Mail_From
parameters may be different. To facilitate the activity at the MTA,
the 2821.Mail_From offers the greatest advantage.
Any domain found in an email-address can expressed as SHA-256 hash
and listed by the email-address domain as a base32 52 character
label. Any association of an unlimited number of signing domains
would require only _one_ lookup to resolve.
<base32 SHA-256 signing domain hash>._x-policy.<email-address-domain>.
3- Reputation of the sender will likely resolve to their IP address
in most cases.
This means DKIM feedback reports needs to be directed to the actual
sender. This is not necessarily the owner of the email-address.
Using a key published in a foreign domain as achieved through the use
of DNS delegation prevents essential reporting information from being
sent to the party held accountable by way of IP address.
For the sender's protection, DNS delegation is a bad practice. The
email-address should never be held accountable for a message. Ever!
There is no risk or danger created by allowing email-address policies
for the 2822.From, 2822.Sender, or the 2821.Mail_From from simply
listing an association with some signing domain. This allows the
signing domain to best protect outbound services, and also allow the
email-addresses to be safely annotated by the recipient's MUA or
safely used in a DSN.
This section seems to be profoundly confused about who is most likely
to be held accountable, and what advantages are afforded by having a
DKIM domain be associated with the sending domain. From the MTA
operations standpoint, an association with the 2822.From offers the
least protection. Policy allow associations to be made in a very
simple fashion. The MTA should be more concerned about abuse
reporting and issuing DSNs.
Let the MUAs worry about email-address annotations via policy
associations.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
