----- Original Message -----
From: "Aumont - Comite Reseaux des Universites"
<serge(_dot_)aumont(_at_)cru(_dot_)fr>
So we must examine benefits and problems for 8 cases:
This is good but there are 1 additional action, that "might" be separate
from the above, and this the subscription process. The LS must follow
SSP to restrict subscriptions from domains who have specific restrictive
policies.
------------------- 0/0/0 :
-The list server does not add a signature/
-does not remove the existing signature /
-does not modify the message /
The message is distributed with a valid signature. The original sender
reputation will be used by final RCPT to evaluate the message : the
mailing list server is transparent forwarder but final receipient
can't use DKIM signature in order to prove that the message was
relayed by the list.
First, I am approaching this from the standpoint of the existing SSP
draft specificaition and what it will take to deterministically follow
it so that it is 100% consistent with SSP and the SSP integrity is
maintained during the transport or routes and mail processing.
For this case, the LS can allow this for all policies, except:
o=! EXCLUSIVE (signature required, no 3rd party allowed)
o=. NEVER (no mail expected)
EXCLUSIVE does not allow for 3rd party or middle ware SENDER: address
domains. However, if the LS is simply acting as a "passthru" system, no
change to control lines (headers) as well, then it might work here.
NEVER should have been handled by the the SMTP inbound verifier.
------------------- 0/0/1
-The list server do not add a signature/
-do not removes the existing signature,/
-modify the message,/
BAD : the message is distributed with invalid signature, this valid
message will probably be suspicious for many rcpt
Correct. In this case, a LS is not DKIM/SSP compliant. It can not
operate in this mode if it makes any attempt to support DKIM/SSP.
------------------- 0/1/0 and 0/1/1
-The list server does not add a signature/
-removes the existing signature, /
-does not modify the message or not
The message is distributed unsigned.
If the sender SSP specifies that all messages from this sender
must be signed then this message is suspicious.
Correct. I have no seen a definitive statement yet about stripping
(and/or replacement). We need a statement about this.
Nonetheless, currently, from a consistency standpoint, the LS can not
stripped for the policies that require a signature, and/or a optional
policy but a signature is present if we declare that a signature message
can not be stripped. If we allow it, the LS can only do a "Strip" for
the following policies:
o=? WEAK (signature optional, no 3rd party allowed)
o=~ NEUTRAL (signature optional, 3rd party allowed)
IMO, no stripping should occur unless it is replaced.
------------------- 1/0/0
-The list server adds a signature.
-does not remove the existing signature,/
-does not modify the message
A) the mailing list server adds a signature i= (signer) and
"From:" are different. The signature may be invalid if the
sender SSP does not allow third party signature.
Right, the LS can only add a signature for
NONE (no policy)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
For this state, the LS can not add a signature for the remaining
policies
B) Possible scenario for replay attack
A BAD actor could exploit a un-moderated opt-in mailing list in
order to subscribe, send a spam to the list, receive its own
spam signed by the listserver in order to replay it. This
would affect the list server reputation but also the original
sender reputation unless he's signature is removed or altered
by the distribution processus.
The original spam is not from any DKIM secured domain. How would this
harm other subscribers? As long as LS follows the SSP, the spammer can
not exploit retrictive policies. If the LS follows SSP, for this case,
it only allows case this to happen for NONE, NEUTRAL, STRONG which
allows 3rd party signing.
A and B are true for any of 1/x/x (if the original message is modified
or not and if the original signature is removed or not).
Well, it ain't going to work well if the LS blindly adds signatures. It,
as well as all mail reprocessors, must be consistent with the SSP
protocol to minimize all harm.
How can this signature be used by the final rcpt ?
What is it usefull for ? It can be used to prove that the message was
relayed via the mailing list but usualy, when this is needed the list
archives can prove it.
The list reputation can be used but to my mind, the original sender
reputation seems to be the reputation that should be used.
Sure. Thats obvious I think but that is results declared by his relaxed
SSP. If the domain uses a relaxed policies, then it asking for trouble.
This is already proved in practice with SMTP relaxed provisions where we
don't double check transaction entities and with SPF relaxed policies as
well, where its NEUTRAL policy is exploited and abused. Same will
happen with DKIM/SSP relaxed provisions. It should not expect any less
here.
Other cases are variant of 1/x/x and 0/x/x that cumul problems
from both categories.
Well, overall, its about following the SSP protocol. Whether the SSP
protocol mandates too much strains or pressures for mail author to
change their wares, thats a different issue all together. But if we
want it to work, well SSP defines exactly what sort of redesign projects
we have to do to support it. Otherwise it all for nothing.
At the end, I can't identify the reason why a mailing should add a
signature to a message, may be because I didn't understand how third
party signature can be used with a signer (i=) different from the
message Sender. Also I can't see how MUA could deal with message with
multiple From: . It is definitively not a common usage and it will not
be accepted by users because it suppose some modification in MUA.
Right, the question of multiple FROMS for the MUA (offline or online) is
a non-issue. Don't even go there. Thats a fundamental change in the UI
ergonomics across the board.
But to me, this is all very simple. SSP is a very strong protocol, like
Dave Crocker mentioned "Its scary."
This is all about "how much" we want to change our software to support
the SSP protocol. SSP to me is about "double checking" domain
declarations. We don't have anything today that offers this level of
verification in the SMTP/EMAIL transaction process. We have strong SPF
policies and that is the closest thing to have. But it has its mail
forwarding issues and DKIM resolved this specify issue. This is the
MISSING piece. If did not, DKIM would not be needed. SPF is sufficient.
But if compliant systems play the DKIM/SSP role correctly, then in my
opinion, we got a winner. It will work 100% for restrictive policies
from high-value domains who want it, it work less than 100% for relaxed
domain policies. But like all things relaxed, these policies and
provisions will always be exploited.
So how much we want to change our software is the bottom line here.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org