Comments on draft-kucherawy-dkim-lists-00
Murray,
Well done on your draft. This encompasses many themes from current email
practices namely:
1. sender responsibility
2. keeping it simple
3. attempts to keep impact minimal and provide a compatible way forward.
Historical Sender Responsibility for SMTP:
Email has slowly changed the way it has been sent over the years in the
following ways:
* open relays fell out of favour
* email gateways became authenticated
* email providers were pressured to stay off blacklists by complying to a set
of practices including no open relays, RFC compliance to not sending bulk
spam.
These changes have occurred because of receivers changing the way they
receive, block and filter email. The senders have had a choice here of change
practices or risk their email not being accepted.
In the same way that receiver practices have previously changed the way email
is sent DKIM, despite its infancy has also had an impact. Brett has mentioned
earlier the positive effects for paypal as a mechanism that domains can use to
protect their customers from phishing. MLMs, like mailman, have taken the
simple option of stripping DKIM signatures which has also had a positive effect
for many list admins. The conflict in these approaches has put receivers in
limbo as to how to perform appropriate actions based on DKIM signatures.
Introducing a recommended way of doing things like this rfc-draft is an
important step.
Previously email verifiers had introduced practices over time. The key to
changing the sender behaviour has been using the feedback mechanism of SMTP
rejection and NDR. The feedback mechanism for future filtering I see is the ARF
RFC (once published). Specificity to DKIM/ADSP is draft-ietf-marf-dkim-
reporting standard. In the same way that NDR drove email practices from 1984
to where they are now, DKIM/ADSP reporting feedback via ARF I see as a way to
provide sender domains information relating to genuine phishing attempts
against their domains, and also feedback on incompatibilities due to MLM and
the occasional MTAs along the way.
Actual Review:
Principle Recommendations:
Incorporate ARF/draft-ietf-mark-dkim-reporting as strong recommendations so
that any incompatibilities anywhere will be obvious the the sender domain. As
gaining statistics and experience is a dominate objective of this working
group getting report forwarding done by verifiers so senders have a full
picture is essential.
Some mechanism, potentially part of draft-mark-dkim-reporting, for
intermediaries signature to receive notification whenever a final delivery
didn't get accepted independent of the verification status of the DKIM
signature added. This would enable MLM to gain an idea as to which recipients
are rejecting emails based on author domain signatures. Some MLMs currently
manage bounce list to unsubscribe broken end user accounts.
Another idea based on what Barry said was to introduce a section of why MLM
break signature and potentially dkim compliant practices that could be
achieved in the medium to longer term. An attempt at this has been
incorporated into the current section 3.3.
Specific components of the draft:
section 1.1
add to list of questions:
"What options exist for a recipient verifying a message?"
minor: I tend to think this current list of questions omits the significance of
the end recipients' options in decision making based on dkim signatures and
this is discussed in the draft.
section 1.2
insert as 1.2 before the current 1.2:
"1.2 DKIM / ADSP failure reporting
It is in the author domain interest to have its messages widely accepted by
MLM recipients. For this reason senders are advised to utilise a [draft-marf-
dkim-reporting] feedback mechanism to help them make informed decisions about
what DKIM/ADSP verification failures are occurring. Based on the feedback
received it can be evaluated as phishing attempt or a message that passed
through the gateway that was desirable to reach its intended recipient. Some
options listed in section 4.1 Author-Related Signing could be utilised for
future mail to this destination.
It is in the recipients interest to allow messages through that pass DKIM/ADSP
checks. MLM are likely to cause some difficulties in processing. Whatever
action
a recipient may choose to take sending a ARF message back to the via [draft-
marf-dkim-reporting] is an important way that a sender domain or MLM can occur
take action to enhance DKIM/ADSP."
significant: this adds a feedback mechanism for everyone.
section 1.3 Feedback Loops And Other Bi-Lateral Agreements
insert as last paragraph:
"[draft-marf-dkim-reporting] allows a FBL between non-related entities without
a bi-lateral arrangement."
section 3.3 Current MLM Effects On Signatures
Append at end of subject tags paragraph.
"The content of MLM modification of the subject tag is effectively replicating
the List-ID value in a way visible to the recipient. This behavior was
motivated by a lack of MUA support for displaying List-ID tags. It desirable
for MUA to start supporting List-ID tags in order to deprecate this behaviour
in MLMs."
Addition to other header fields paragraph:
"The modification of Sender/Reply-to stems from a goal to guide the recipients
behaviour to continue the conversion or or off list. There could be an attempt
to create a new header field to describe the desired behaviour and for MUAs to
take note of this header field."
(ref: http://mail.python.org/pipermail/mailman-users/2009-October/067391.html)
RFC5322 also lists Sender and Reply-to as originator fields.
Alter start of body changes paragraph to:
"Some lists filter attachments, prepend, or append"...
minor: filtering attachments is a common body modification
Add to end of this paragraph:
The filtering of attachments is a part of MLMs that are aimed at reducing
message size and preventing malware aimed at MLM subscribers.
Alternate practices like rejecting messages with attachments would some the
malware case. There is some convenience to users to be able to send messages
to a mail list with attachments that get archived on the MLM and users receive
a HTTP link to its content. A dkim compatible way for this to be facilitated
would require the sender to sign only the non-attachment portion of the
message using l= dkim tags.
Prepended or appended lines currently tend to describe unsubscribe information
or list policy information. List unsubscribe is currently a RFC2369 header
field with few implementations in MUAs. List policy information is currently
unsupported as header field however its purpose could be implemented.
Policy notices could be sent periodic notices authoring list notices from the
MLM.
significant: explores options in changing MLM behaviour, that while is not
going to happen in any hurry may end up occurring eventually. I acknowledge
that the bit on attachment filtering alternatives isn't complete.
new paragraph at the end of 3.3
In essence, the practices of MLM breaking DKIM signature verification could be
reduced with better MUA support on existing standards and the introduction of
a few simple standards so that MUA and MLM can operate consistently rather
then retrofitting desired behavior into existing header fields potentially in a
incompatible way.
significant: explores options in changing MLM behaviour, that while is not
going to happen in any hurry may end up occurring eventually.
3.4. Alternatives of Participation and Conformance
Alter beginning of second paragraph to:
"However, the practice of applying headers and footers to message
bodies, modifying subject header field and attachment filtering is common"
minor: adds the other equally as common signature breaks to the rational.
4.1 Author-Related Signing
note:
Not adding signatures removes the mechanism provided by [draft-marf-dkim-
reporting] for gaining feedback.
4.3. Handling Choices at Receivers
"[ADSP] presents an additional challenge. Per that specification,
when a message is unsigned or the signature can no longer be
verified, the verifier [must] discard the message."
minor: "should" would be closer to the RFC5617 meaning.
4.3 Handling Choices at Receivers
add to end:
"A verifier should choose to send a [ARF] message to the author domain
reportable address [draft-marf-dkim-reporting] enabling them to take action
for future messages sent to the MLM."
minor: highlight the benefits of ARF
5.1. Author-Related Signing
change title - "Author verification by MLMs" perhaps
minor: Title seems misleading. especially considering the first paragraph.
second paragraph probably should be removed or merged into 4.1 Author-Related
Signing. Removing this second paragraph will make 5.1 flow into 5.2 better. I
suspect the 5.2 heading could be removed.
5.2 Verification Outcomes at MLMs
append to second paragraph.
An author domain may request for DKIM and ADSP failures to be reported through
[draft-marf-dkim-reporting]. A participating MLM is advised to comply with
this request.
minor: highlight arf
5.3 Pros and Cons of Signature Removal
a con of signature removal is it removes the tags need for a recipient to give
feedback via [draft-marf-dkim-reporting].
significant. Breaking a feedback mechanism isn't a great improvement.
5.3 Pros and Cons of Signature Removal
comment:
minor: given resending MLM set the envelope to receive bounce message, they
are in a good position to know which recipients reject based on ADSP/DKIM
failures. A enthusiastic MLM implementer could avoid deliver there or deliver
there as an authoring list.
5.4. MLM Signatures
Question with regard to "as it arrived". I suspect signing it after
modification provides greater utility to the recipient. I'm not sure of the
value in an arrival signature - wouldn't this be the same as the author
signature that potentially got removed?
Add also at this point:
DKIM-aware resending MLM may decide to use the [draft-marf-dkim-reporting]
mechanism to determine if any DKIM signature breaks are occurring between the
MLM and the recipient.
Append new section:
5.X MLM ADSP
A participating MLM should be able to assert a ADSP policy. This is especially
true for authoring and digesting mailing lists. Resending and aliasing lists
still have benefits as administrative messages are likely to have a domain as
an author domain. Care should be taken if the MLM domain is shared with other
message streams.
important: As mailing list domains are probably the ones going to have
filtering exceptions at the recipient end because of signature breaks this
makes them potentially a targeting domain to use if phishing attacks. An ADSP
policy will make it easier for recipients to apply filtering rules as mailing
lists are unlikely to be chained together outside a recipients ADMD.
5.5. Verification Outcomes at Final Receiving Sites
comment:
minor: As a final receiving site will have a recipient that is likely be be a
participant in the MLM, some form of feedback look within the receiving ADMD
to produce a favorable(?) set of MLM signatures.
Daniel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html