ietf-dkim
[Top] [All Lists]

[ietf-dkim] Comments on draft-ietf-dkim-deployment-07

2009-07-19 05:05:13
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

<Prev in Thread] Current Thread [Next in Thread>