Michael Deutschmann wrote:
I'd like to more emphatically state the case for adding a
"dkim=except-mlist" policy to ADSP. It will soon become a practical
issue for me, since my mailserver software (Exim) is going to support
DKIM in its next version.
Without it, I'd have to use "dkim=unknown", which is effectively no ADSP
at all.
To review, "dkim=except-mlist" would mean:
I sign everything leaving my bailiwick, but may post to mailing lists
that break the signature. You are *on your own* in telling the
difference between mailing list mail (which may be good despite a
broken signature) and directly sent mail (that is always signed). If
you can't tell, then treat as dkim=unknown (ie: assume a message is
ML traffic unless you know otherwise.).
(Incidentally, anyone have a better name for this policy?)
IMO dkim=list would be fine for what you describe.
The concern I have two folds:
1) Its a threat entry point.
I rather see Doug's TPA or something list the DSAP 3pl=domain-list idea.
2) Complexity.
It appears to require a rule such as:
if signed and 3rd party and contains some form of
a list header, precedence: list perhaps
then pass (positive classification).
Now, this is GREAT. Fantastic! It might work, but we have the same
problem that is always the case for everything else:
What do you do when it fails?
Its hard for me to shallow the idea that its ok to accept mail when
you declare all these parts are needed, but not say anything about
when its not detected.
The determination of whether it is good to add a new policy to ADSP
should rest on three issues:
1. Is it backwards compatible?
+1
2. Will senders ever deploy it?
3. Will receivers ever treat it differently than what the senders would
use if it were unavailable?
For #1, it is indeed compatible. RFC 5617 explictly says that unknown
values are to be treated identically to "unknown".
Under Levine's interpretation of RFC 5617, "unknown" is clearly the best
approximation to "except-mlist". Under the Thomas interpetation, it is
a small step back, but enough people endorse the Levine interpretation
that it would be foolish to count on sites treating "all" as
"except-mlist".
Hmmm, wouldn't it be nice if we have a WG interpretation?
The Levine doctrine "Do as I say, not as I write" A.K.A IGNORE it, is
design to have unrestricted 3rd party signers (middle ware). They are
not going to look at it.
For #2, do I even need to argue?
I hope so. Everyone else is required to argue their case. :)
Any site that passes all outgoing mail
through a DKIM-aware smarthost qualifies for "except-mlist", but not for
"all" if there are any mailing list subscribers.
How does a receiver know that the client is sending list mail? Do they
need to look at some other 2822/5322 header?
Who adds this? senders or author domains? It sounds like the sender. No?
#3 is the weakest point, but I can offer my personal testimony that I
have all my mailing lists whitelisted, and could thus only improve my
bad-mail determination accuracy if this extra information was available
in the ADSP records of purported senders.
IMO, it is the weakest point and also the one you need to address.
Our SMTP server is integrated with our LIST Server, so all list agents
ids are validated at SMTP level (RCPT TO) and its validated like its
any other hosted user or domain. Thats not an issue to accept the
message.
The issue is the failure of the author domain policy. Lets assume the
following DNA:
From: user1(_at_)domain1(_dot_)com
To: user2:domain2.com
Dkim-Signature: d=mipassoc.org
Precedence: list
I believe you are saying domain1.com has ADSP++ record:
dkim=except-mlist
and the domain2.com receiver sees this policy and also maybe
Precedence: list to determine it was a list message?
Why? What is gained by checking for some "list" header?
Why not just consider previous polices like in SSP
op=- which is a must sign and allows for 3rd party signatures.
Anyway, what I want to know if what happens when you have this:
From: user1(_at_)domain1(_dot_)com
To: user2:domain2.com (MDA2)
Precedence: list
and there is no signature, Is this a Discardable message for domains
with dkim=except-mlist?
---
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html