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
