The text below is a short essay I wrote in response to some discussion
in a Jabber session a month or so ago. John Levine graciously agreed to
review it, but any errors are mine.
The intent here was to present some thinking on how and why DKIM might
be used by mailing lists. It does not impact the -base specification
other than, hopefully, to show that what's in -base is sufficient for
mailing list usage. Some of this might be appropriate for the "DKIM
Overview Document" when we get to it.
-Jim
Use of DKIM Signatures by Mailing Lists
June 14, 2006
DomainKeys Identified Mail (DKIM) provides the capability for a message to be
signed by a party other than the author of a message or the author's
representative. This type of signature is known as a "third-party" signature.
Third-party signatures are expected to be used widely by mailing lists,
particularly those that modify messages in a manner that would cause an
author's
DKIM signature to break (become invalid). Up to this point, little attention
has been paid to the details of how this would work.
Security issues affecting mailing lists
There are three classes of security issues that involve mailing lists:
1. At subscription time, the mailing list wants to know whether a request is
from a legitimate subscriber. Forgery of subscription requests is common, and
is typically dealt with by challenge/response mechanisms or manual (human)
moderation.
2. When a message is posted, the list wants to know whether the message is
legitimate. Unauthorized submission of messages is common, and is typically
handled by checking the From: address on incoming messages against a list or by
manual moderation. Message forgery is currently rare, although this could
change as other mechanisms for forgery become more difficult.
3. When a list distributes a message, subscribers want to know whether mail is
really from the list. This determination is typically made by checking the
List-ID:, Sender: or other header fields inserted by the list. Forgery of list
messages is currently very rare, but this could be expected to change if such
forgeries are successful in getting messages accepted by recipients.
Potential benefits of DKIM to lists
DKIM signatures might be useful to mailing lists in the following ways:
1. DKIM should be useful to verify that a sender is who he says he is, or at
least who he said he was when he subscribed, so messages with DKIM signatures
from subscribers (or possibly others with good reputations) might be directly
accepted, while others will face more scrutiny such as a callback or manual
moderation.
2. DKIM should be useful to allow recipients to recognize list mail, in the
same
way as it would be used to recognize any other mail from a known correspondent.
3. For the small fraction of mailing list subscriptions initiated by mail (vs.
via web sites), DKIM could help authenticate the sender and perhaps simplify
the
subscription process.
Actions by author/signer
The author and signer of a message subject to application of a third-party
signature by a mailing list should not have to take any special action for
messages sent to mailing lists, other than to ensure that Sender Signing
Practices, if any, permit third-party signatures.
Actions by lists
Just as they do today, mailing lists should do whatever they see fit to limit
the distribution of undesired messages via the mailing list. This may include
checks to see that the From address on the message is a member of the list,
active (human) moderation, or other measures. With DKIM, it is also possible
to
check for a valid signature on messages from list participants that sign their
messages. The determination that a signature should be required from a given
participant can be made based on the presence of a signature when a
subscription
request is sent, or could be an option selected on a subscriber web interface
such as that provided by Mailman. If an unsigned message is received
purporting
to come from a subscriber that asserts that their messages are signed, the
message should be rejected via an SNMP 5xx code, if possible, or should be
ignored.
Messages should be signed by mailing lists using the identity of the list
itself, as shown in the List-Id header field being added, if any. For example,
if the List-Id is <ietf-dkim.mipassoc.org>, the signing identity (i= field of
the signature) should be ietf-dkim(_at_)mipassoc(_dot_)org(_dot_) This
provides the most
unambiguous interpretation of the role of the signer by the verifier.
The presence of DKIM signatures on subscription requests and other
administrative traffic can, in come cases, be used to simplify the subscription
process. Mailing lists may eliminate the confirmation step of the message
subscription process when a valid DKIM signature is present to validate the
requesting address. However, this is only a small benefit.
Mailing lists should not remove DKIM signatures on incoming messages. Because
the verifier is free to use whatever methods it chooses to try to verify
signatures successfully, it isn't, in general, possible to know whether an
incoming signature will continue to verify correctly. However, since some
mailing lists are advertising-supported, and would not want the verifier to
remove the advertising content in order to make the message verify correctly,
some lists will remove incoming signatures anyway.
If a mailing list or other intermediary wishes to assert that a message
verified
correctly when received, it should apply a header field such as Authentication-
Results and include that header field in its outgoing signature. The semantics
of such an arrangement are unclear, because the recipient should consider any
signed message from a known, trusted mailing list favorably, even without a
signed incoming signature.
Actions by verifiers and recipients
When presented with a valid third-party signature, a verifier may wish to
determine the role of the signer. If the List-Id header field is present, the
associated signature will have an identity (i=) corresponding with that header
field.
The verifier or recipient may also act on the signing identity alone, since
addresses used by mailing lists will usually assume no other role.
When presented with a third-party signature, it is important that the verifier
or recipient compare the signing address against a list of known, reliable
addresses. Relying on association with the List-Id alone is insufficient,
since
attackers could easily send messages on behalf of a nonexistent mailing list at
a disposable domain in an effort to have the message recognized as coming from
a
mailing list.
As with all third-party signed messages, it is helpful if the MUA is able to
display the signing identity as well as the author's.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html