[ietf-dkim] Lists "BCP" draft review
dhc at dcrocker.net
Tue Jun 1 03:47:32 PDT 2010
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
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
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.
More information about the ietf-dkim