Douglas Otis wrote:
Agreed.
But this 3PS type of message signature was the concern.
From: person(_at_)example(_dot_)com
Sender: other-person(_at_)(_dot_)example(_dot_)com
DKIM-Signature: d=expample.com i=other-person(_at_)example(_dot_)com (g=*)
But this isn't a 3rd party signature. The signing domain is the same as
the from domain, or did you try to throw in a "near-phish" domain, or
is that a typo? "exPample.com" ???
This message is clearly signed by example.com per RFC 4871, but where a
SSP policy assertion of either "all" or "discardable" might cause this
ABSOLUTELY valid message to be dropped as being non-compliant.
I don't see what you are talking about here. Where is the problem?
Which specification are you talking about? Is this really a valid
message?
(Hard to define compliance with the "discardable" assertion isn't it?
> Too bad this was not discussed on the WG list.)
It like you forced a non-compliance a ASP. :-)
But if you really meant the above being a near-phish, exPample.com, then
this goes to illustrate how ASP will harm the primary domain.
Plus, you didn't indicate if the Sender= was bound to the signature or not.
SSP stipulations changes RFC 4871 signature handling to not use the
i= parameter when there might be such a conflict with the From header.
Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i=
must be the same
Agreed, however the issue was with respect to the local-part
other-person(_at_)example(_dot_)com not meeting the requirements for "Author
Signature" in SSP, however it does meet these requirements in ASP.
Its hard to continue a thought process in what is a flawed concept.
Even then, all I see above is either a typo or an intentional 3PS based
on a near-phish. If that is the case, then you just showed quite
clearly, how the author domain EXAMPLE.COM has just been exploited with
less means of protecting it.
DKIM is silent upon what might be displayed.
The logical association implies for this to be:
([i] == d) != From
which is the fundamental basis for a 3rd party Signing operation.
Like wise, the logical association for a 1st party signature is:
([i] == d) == From
You appear to be describing a comparison stated in ASP, and not the
comparison in SSP.
Huh? the above logic has been the basis for 3rd vs 1rd party signature
(respectively) since the beginning.
We need to keep our eye on the prize here and that is DOMAIN protection,
Agreed.
You do? How can you support ASP when it doesn't help protect domains
from 3rd party abuse? You just illustrated this above.
to assist it in keeping with its new asserted DKIM-BASE "social and
ethical" responsibility. SSP is basically a fraud detection or
protocol consistency checker. If everything is koshser, I believe no
one has ever said SSP allows a message to pass or skip any other testing.
It would seem better to describe this as a means to evaluate compliance
with Sender assertions pertaining to what the transmitting indicates as
their handling practices. This view makes less sense when the assertion
is "discardable".
Now you really lost me. :-)
Are you suggesting even DISCARDABLE is no good? You want to further
water down SSP or whatever you wish to call it ASP?
The concern is when the message is signed by the author's domain, but
on-behalf-of someone else with the author's domain. When this domain
applies their signature, their signing policy MUST evaluate whether
"other-person(_at_)example(_dot_)com" is able to include "person(_at_)example(_dot_)com" with
the From header. It would be ridiculous to expect to have this policy
applied by a possible verifier. As you said, DKIM is about establishing
responsibility _at_ the domain. When the domain is held accountable, as
designed in RFC 4871, the local-part introducing the message does not
matter. The local-part might be highlighted by the MUA to indicate who
introduced the message, but as far as signing policy should be
concerned, local-part is immaterial.
I think I agree with the statement but I am not seeing the problem,
maybe because the above example had typos?
The local-part is only material when the key is g= restricted.
I'm going to take your word on this. It sound's reasonable, but I think
overall, this is now really a moot point because ASP has made DKIM-BASE
a less attractive idea to pursue. Too much fraud is possible now.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html