On 5/29/2010 2:09 AM, Daniel Black wrote: > * email gateways became authenticated
What does this mean? > * 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. Pressure from whom? How is it manifest/documented? Although closing open relays is probably an acknowledged universal rule, not much else is. "Pressure" for 'RFC compliance' is certainly not new. Unfortunately, it also is not precise. > 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. How have receivers changed the way they "receive"? > 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. DKIM, by itself, does not protect against phishing. DKIM does not attempt to help find bad actors. Generic statements about DKIM and phishing, in some DKIM documents, has no technical substance. On the other hand, ADSP certainly was motivated by the direct goal of finding spoofed From: domains. > MLMs, like mailman, have taken the > simple option of stripping DKIM signatures which has also had a positive > effect > for many list admins. This implies that DKIM-stripping is an active choice among MLMs. It isn't. > 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. I do not understand this recommendation. > It is in the recipients interest to allow messages through that pass DKIM/ADSP > checks. As stated, this assertion is largely incorrect. It declares that a sender who publishes DKIM/ADSP is (automatically) to be interpreted as a good actor. > 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." This document has no goal nor scope for recommending basic changes to the operation of mailing list managers. Nor is there any history of having MLMs adopt such recommendations. Nor, I suspect, is there likely to be community agreement that changing this widespread Subject: field behavior is a good idea... > 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." Having one specification recommend that someone, somewhere, initiate a new specification effort is generally not useful. > 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. This document does not have the goal of explaining MLMs. We should be extremely careful to keep this document within its scope. > 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. Changing MUAs will not alter MLM DKIM breakage. Please explain how you think it can. The rest of that sentence has no technical substance and is not the sort of language that is helpful for a specification. > Append new section: > > 5.X MLM ADSP > > A participating MLM should be able to assert a ADSP policy. This sort of statement is certainly controversial but worse is outside the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
