----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
o Are 3rd party signers allowed to strip your
original signatures?
This is redundant when a list of designated domains can
be asserted as being exclusive.
Yes, it can be redundant. But what if it is not exclusive? This one I can
punt with, however, I highlighted it for this reason:
This has to do with MLS (Mailing List Servers or any middle ware for that
matter) and any mail tampering behavior they may exhibit and to help reduce
any "multi-signature" failure ambiquities.
In other words, if a domain has in its policy that 1st party signatures is
OPTIONAL, then it would be, in practice, possible for the MLS to 'cleanup'
any mess it may create.
However, it should be noted DKIM-BASE does have it stated that no signatures
MUST NOT be removed, even it was invalid which only adds to more ambiquity
because it may instantly promote failure as well as hide them. It all
depends on the OA.
More on this below.
This is a 2822.From policy, and as Jim has pointed out,
when allowing a list, a means to signal whether the 2822.From
addresses should be considered valid is needed. I think
being able to differentiate between scenario 1 and 2 is
also important. This introduces the concept of two
flags "All" (signed) and "Only" (these used).
A desire to include sources where the 2822.From is not
valid requires three flags: "All", "Only", and "Invalid."
I understand the point and your suggestion.
But lets keep in mind that DKIM-BASE, including the fact that existing open
source code do already support the granularity (g=) and the identity (i=)
for the verification process. So this logic is already part of the
DKIM-BASE signature HASH verification process.
The question, if I am still understanding the deviations of this thread, is
which domain to do the policy lookup.
It seems to me to hinge on two things:
A) Whether there is a VALID 1st party signature, thus as
some suggest, no need for a POLICY lookup, and
B) Whether 3rd party is an important consideration, if present.
For example, suppose there are multi-signatures and lets throw in all the
discussed entities such as Sender:
FROM: boss(_at_)company(_dot_)com
SENDER: mailinglist.com
DKIM-SIGNATURE: d=ISP.COM; i=boss(_at_)company(_dot_)com; # 3PS
DKIM-SIGNATURE d=company.com # 1PS
According to requirement #10, as long as the 1PS is valid, then there is no
need for any extra consideration (as far as DKIM is concern).
Now consider the issues:
If we ignore the state information regarding the presence of the 3PS, then
we lost the opportunity to protect the exclusive or any 3rd party
restricted/limited policy. In other words, maybe there was no allowance for
ISP.COM to sign?
DKIM-BASE says, that as long as one signature is valid, then it passes the
DKIM-BASE test.
So what if the 1PS is not valid?
Remember, the scenario is that this is a mailinglist.com message, therefore
if company.com did sign the message, mailinglist.com might destroy the
integrity.
In this case, which SSP domain do we look at for the policy lookup?
I would hope that we still look at company.com's Policy.
Now lets consider at what ISP.COM might be doing when there is a 1PS already
present.
a) Should it even add a 3PS?
b) Should it remove the 1PS before adding a 3PS?
DKIM-BASE mandates option B is not to be allowed (no stripping of
signatures).
Therefore, the ISP is left to have smarts to either ADD one or NOT. If the
1st party signature is invalid, it would seem to me that it must add one to
correct the message.
But whether it does or not, goes who left holding the bag to try to make
sense out of all this?
The verifier.
There are far too many scenarios to make heads and tail.
We need to keep it simple, the verifier needs to look at the original domain
policy to find out what was allowed to happen here or not and in my view, it
doesn't matter if there was a 1st or 3rd or both signature present or not.
My only point here is that company.com will need to learn how to use
DKIM/SSP if it wants to protect itself. As you say, ultimately, the
presentation of such results is going to be able how the FROM is presented
to the end user.
If we want to discuss implementation details such as how mailinglist.com
(MLS) should be behave when it receives a company.com message or how the
ISP.COM (MSA/MTA) should behave when it sees two possible messages, one from
company.com and mailinglist.com representing the same OA domain, then I'm
ready for this.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html