At 08:02 12-05-2011, The IESG wrote:
The IESG has received a request from the Domain Keys Identified Mail WG
(dkim) to consider the following document:
- 'DKIM And Mailing Lists'
<draft-ietf-dkim-mailinglists-10.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-05-26. Exceptionally, comments
may be
From Abstract Section:
"Based on deployment experience with DKIM, this Best Current
Practices document provides guidance for the use of DKIM
with scenarios that include Mailing List Managers (MLMs)."
Although one can extrapolate from experience and provide some
guidance, I would not call it "Best Current Practices". I suggest a
change to that sentence:
Based on deployment experience with DKIM, this document provides
guidance for the use of DKIM with scenarios that include Mailing
List Managers (MLMs).
Quoting the Introduction Section:
"The goal for this document is to explore the use of DKIM for
scenarios that include intermediaries, and recommend Best
Current Practices based on acquired experience."
The Intended Status of this document is BCP. I cannot support a
recommendation for "Best Current Practices" that is not based on
existing practices. If the IETF wants a stick to tell the outside
world what to do, it can publish this document as a BCP. If the IETF
would like to provide guidance, leave it to the outside world to
adopt that and then document the current practice, it should not
publish this document as a BCP.
From Section 2.5:
"Each of these could have different security policies imposed
against them, or there might be a desire to insulate one from
the other (e.g., a marketing campaign that gets reported by
many spam filters could cause the marketing stream's reputation
to degrade without automatically punishing the transactional or
user streams)."
Shouldn't that be sending policies instead of "security
policies"? If we go a stretch further, a marketing campaign might
end up be labelled as a terrorist act and that falls under the Security Area.
I'll translate that paragraph for a wider audience. Some companies
send out spam; it keeps businesses happy if it is called a marketing
campaign. These companies also send out messages that the receiver
actually wants to read. On the receiving side, there is a lot of
zealotry that goes on. One way to mitigate the effects of that
zealotry is to provide the receiver a means to separate the spam from
other mail.
In Section 3.3:
"Some lists prepend or append a few lines to each
message to remind subscribers of an administrative URL for
subscription issues, or of list policy, etc."
It's funny to see how some MUAs adapted to that by hiding these lines
thereby rolling back that "fix".
In Section 4.1:
"In an idealized world, if an author knows that the MLM to which a
message is being sent is a non-participating resending MLM, the
author SHOULD be cautious when deciding whether or not to send a
signed message to the list."
The author generally does not have any control over that decision as
DKIM signing is not done at the MUA level. The usage of a key word
is somewhat excessive here as the ideal world is out of scope for RFC 2119.
"This problem can be compounded if there are receivers that apply
signing policies (e.g., [ADSP]) and the author publishes any kind
of strict policy, i.e., a policy that requests that receivers reject
or otherwise deal severely with non-compliant messages."
The "definition of insanity is doing the same thing over and over and
expecting different results". There are parallels between ADSP and SPF.
In Section 5.1:
"It is RECOMMENDED that periodic, automatic mailings to the list are
sent to remind subscribers of list policy."
This is currently being done by the IETF under the guise of mailman day.
In Section 5.5:
"In that case, authors SHOULD create a mail stream
specifically used for generating signatures when sending traffic to
MLMs."
I suggest using "DKIM signatures".
"This suggestion can be made more general."
Shouldn't that be recommendation?
In Section 5.8:
"DKIM-aware authoring MLMs MUST sign the mail they send according to
the regular signing guidelines given in [DKIM].
One concern is that having an MLM apply its signature to unsigned
mail might cause some verifiers or receivers to interpret the
signature as conferring more authority or authenticity to the message
content than is defined by [DKIM]. This is an issue beyond MLMs and
primarily entails receive-side processing outside of the scope of
[DKIM]. It is nevertheless worth noting here."
Removing the MUST and saying:
DKIM-aware authoring MLMs signs the messages they send according to
the regular signing guidelines given in [DKIM]
gives more weight to the last two paragraphs, especially with the
note about the concern.
In Section 5.10:
"An FBL operator might wish to act on a complaint from a user about a
message sent to a list."
Shouldn't that be FBI? :-)
In Section 5.11:
"Receivers SHOULD ignore or remove all unsigned externally-applied
Authentication-Results header fields, and those not signed by an ADMD
that can be trusted by the receiver."
Quoting Section 5 of RFC 5451:
"For security reasons, any MTA conforming to this specification MUST
delete any discovered instance of this header field that claims to
have been added within its trust boundary and that did not come from
another trusted MTA."
"For simplicity and maximum security, a border MTA MAY remove all
instances of this header field on mail crossing into its trust
boundary."
The MUST and the MAY are aggregated into a SHOULD. Is that intentional?
From Section 5.11:
"Upon DKIM and ADSP evaluation during an SMTP session (a common
implementation), an agent MAY decide to reject a message during an
SMTP session. If this is done, use of an [SMTP] failure code not
normally used for "user unknown" (550) is preferred; therefore, 554
SHOULD be used."
This falls under policy decision. The usage of a 554 code is
inappropriate. From Section 3.6.2 of RFC 5321:
"If it [SMTP server] declines to relay mail to a particular address
for policy reasons, a 550 response SHOULD be returned."
From the same section of this document:
"SMTP servers doing so SHOULD also use appropriate wording in
the text portion of the reply, perhaps explicitly using
the string "ADSP" to facilitate searching of relevant data
in logs."
I wouldn't put a SHOULD in there. The working group made the
argument. Leave it at that.
Quoting two sentences from the same section to provide better context:
"In such cases where the submission fails that test, the receiver or
verifier SHOULD discard the message but return an SMTP success code,
i.e. accept the message but drop it without delivery. An SMTP
rejection of such mail instead of the requested discard action
causes more harm than good."
I would remove the SHOULD as the argument (second sentence) is
clear. The usage of the SHOULD raises the question about whether
this is a SMTP receiver action and whether it is appropriate to
create a black hole (silent drop of message).
I found the document well-written. In places where the document
advocates a particular approach, it provides an explanation for
that. This document can be published as Experimental or
Informational. Please note that such an intended status is not a
dilution of the value of the document.
As there has been some discussion about an Applicability Statement
experiment, I'll quote some text from RFC 2026:
"An Applicability Statement specifies how, and under what circumstances,
one or more TSs [Technical Specifications] may be applied to support a
particular Internet capability."
This document covers RFC 4871 (4871bis actually), RFC 5451 and RFC
5617. The document specifies the circumstances under which the
capabilities discussed here are applicable. If the DKIM working
group decides on taking that path, it could ask for publication of
the document as Proposed Standard.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf