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