Hello,
I have the following comments about
draft-ietf-dkim-deployment-07. The document is for people involved
in development, deployment and operations. These are different
audiences. Some of the material in this document is at a high level
and might be a challenge for people involved in deployment and
operations. I'm not suggesting any change to that.
In Section 2.3, it is mentioned that a DKIM signing entity can serve
different roles, such as author of content, versus operator of the
mail service, versus operator of a reputation service. I don't
understand the use of the word role in the content of a reputation
service. From the examples, it sounds more like an input instead of a role.
"For those originating message content, the most likely choice of sub-
domain naming scheme will by based upon type of content
...
where the choices are best dictated by whether they provide the
Identity Assessor with the ability to discriminate usefully among
streams of mail that demonstrate significantly different degrees of
recipient acceptance or safety."
I noticed that some sub-domain schemes are used as an "opaque identifier".
"For those operating messaging services on behalf of a variety of
customers, an obvious scheme to use has a different sub-domain label
for each customer. For example:
widgetco.example.net"
I am not in favor of such a scheme as it is vendor-oriented. If the
customer changes their messaging service, their signing identify is
no longer valid. One of the advantages of DKIM is that it doesn't
rely on the originating IP address, i.e. the service or content is
not tied to IP addresses. We would be taking a short term approach
by encouraging a tie-in with the transmitter of the message.
I'm going to use this mailing list as an example. The message is
sent through songbird.com. I don't know the relationship between
mipassoc.org and songbird.com. I know that the mailing list is
associated with the mipassoc.org domain. As the receiver, it's
easier for me if the DKIM signer is mipassoc.org. If we were to use
the obvious scheme, then the DKIM signer would be
mipassoc.org.songbird.com or something similar. If the mailing list
is moved to att.com, the DKIM signer would be
mipassoc.org.att.com. The change in signing identity is not to the
advantage of the sender or the receivers.
Section 2.5 focuses on variations in Organizational Trust versus
Message Risk. Adopting an Accept and Contact approach without any
filtering is troublesome for messages from some types of
senders. This is my opinion and not a suggestion to change that section.
In Section 6.2, is the "i=marketing.domain.example" correct?
Section 6.3 is about third party signatures. ESPs and ISPs are in
the same paragraph. In my opinion, they are different as they have
different orientations. What they have in common is the aggregation
of mail traffic which means that you will see "good" mail and "bad"
mail. The level of bad mail from an ISP varies according to the
"quality" of its users at any given point. There is some good advice
in this document which might help. Third party signatures from ESPs
are not that useful when the ESPs aggregate their mail traffic. This
is not a rule. There are mechanisms outside the scope of DKIM where
the information may be of use.
I'm not too keen about the paragraph about Forwarders as it mixes
forwarding mail with mailing list. There are two types of
traffic. The second one generally "breaks" DKIM signatures.
Senders which would like to prevent phishing might want to avoid
third party signatures. There are valid cases when third party
signatures are useful, e.g. forwarders, etc.
In Section 7.3.3:
"An organization (Company A) may specify its signing practices by
publishing an ADSP record with "dkim=all" or "dkim=discardable". In
order to avoid misdelivery of its mail at receivers that are
validating ADSP Company A MUST first have done an exhaustive
analysis to determine all sources of outbound mail from its domain
(companyA.example) and ensure that they all have valid author
signatures from that domain."
I do not understand what the authors mean by "misdelivery". From the
example, an ADSP of "discardable" means that the email can be
discarded. That isn't a wrong delivery as the receiver accepted
delivery of the message.
In Section 7.4:
"An organization may choose to outsource certain key services to an
independent company"
Third-party is more appropriate than "independent company".
BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html