On Tuesday 01 June 2010 20:47:32 Dave CROCKER wrote: > On 5/29/2010 2:09 AM, Daniel Black wrote: > > * email gateways became authenticated > > What does this mean? MSA became authenticated - generally a reduction in open relays. > > * 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? >From the users that get DSN or the intended recipients harassing their mail administrators because mail isn't going trough.
> 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. I agree - lack of precision is why feedback loops are important. I suspect open relays got to the state they are now because of a set of pressures. > How have receivers changed the way they "receive"? mail gateways rejecting based on blacklists of many descriptions, strictness in reverse IP address, friend list and numerous secret sauces of message acceptance. Some recipients may even look at dkim. > > 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. acknowledged. > > 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. I was more highlighting there was an active choice in a MLM development to remove DKIM headers (as a default enabled option I think) and without a guidance such as what the draft is trying to achieve there could be more. > > 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. Strongly recommending the placement of the optional reporting address defined in draft-ietf-dkim-deployment will enable somebody to know the message isn't getting through. Recipients also have a role in reporting ARF by using this header field. > > 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. ok for clarity - the message received shouldn't be rejected on DKIM/ADSP grounds. > > 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. An exploration of DKIM for MLM (ref abstract) sounds like recommending changes is a possibility. Barry's comment #4 as chair in the email 'Some procedural notes from the chairs' suggests it is not out of bounds of the working group or this draft. > Nor is there any history of having > MLMs adopt such recommendations. acknowledged. Barry explains this well too. > Nor, I suspect, is there likely to be community agreement that changing > this widespread Subject: field behavior is a good idea... I image some community disagreement however as Murray points out, MUAs may be changing faster than previously accounted for and provided the MUA is doing a comparable thing as the subject alteration. Perhaps avoiding the possibility of subject changes will preclude the benefits it may gain. > > 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. Quite right - this is more a discussion point. > > 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. Sure. An examination as to why thing are is sometimes more revealing than what they are. > > 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. MLM behaviour is driven by client need. It is presumably there because MUA can't or won't provide the desired functionality. MUA changes may remove the need for DKIM incompatible MLM behaviour when clients have this function served by their MUA. > > 5.X MLM ADSP > > > > A participating MLM should be able to assert a ADSP policy. > > This sort of statement is certainly controversial I suspect more ADSP angst reasons than technical reasons. > but worse is outside the scope of this specification. It falls within the scope of exploring the DKIM and MLM topic. I suspect its a little too early in discussions to limit scope beyond the WG charter. Daniel _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
