SM wrote:
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.
A proactive reputation service vouches for the sender. The sender could
collaborate with the reputation service, to affix signature by that
reputation service to the message; this is a means of imparting the reputation
service's own reputation to the sender. Hence, the reputation service is
performing a proactive role for that sender. (By way of example, this is what
Goodmail does, which perhaps explains why I might think of this scenario...)
I noticed that some sub-domain schemes are used as an "opaque identifier".
Only some?
"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
What you or I or anyone in the working group is in favor isn't the issue. The
issue is what a signer and an assessor might find useful. The paper suggests
some schemes that are likely to have assessment utility.
Choices for labels to use, for distinguishing different message streams will
have tradeoffs. Any particular choice will have negatives as well as
positives.
In this example, the premise was that the service provider's domain name was
being used, rather than the customer's. Sometimes that choice makes sense or
is
the only one that is available.
The purpose of the paper is not to dictate normative behavior -- note that it
intends 'informational' status; it is to explain how things work and what sorts
of choices can be available.
If you feel that tradeoffs are inadequately explicated -- and I mean tradeoffs,
rather than preferences -- please do supply some additional text.
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.
What language are you suggesting to change, and in what way?
In Section 6.2, is the "i=marketing.domain.example" correct?
yes.
If your concern is the use of .example as a TLD:
http://www.rfc-editor.org/rfc/rfc2606.txt
If you have some other concern, what is it?
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.
You appear to be commenting on the efficacy of particular choices, but that's
not the purpose of this document. It is trying to explain the choices, in
terms
of DKIM use, not assert recommendations.
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.
A variety of processes can break them.
I guess the challenge is in finding a single term to cover them. RFC 5598
doesn't quite permit calling them all "mediators". Forwarding is pretty
generic.
Senders which would like to prevent phishing might want to avoid
third party signatures.
Oh boy. That's a topic I hope the documented is not required to touch.
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.
What the receiver does with the message can be delivery as intended by the
sender or it can be delivery elsewhere, such as a junk folder. From an
end-to-end standpoint, that's effectively misdelivery.
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".
Well, "third-party" is a term of art in the DKIM realm and it means something
potentially different than meant here.
BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete.
So? This isn't normative use. And they are not irrelevant.
(On the other hand, 3164 appears to be an unused citation.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html