ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft review

2010-06-01 10:39:48
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