ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Attempted summary

2006-01-27 13:36:04
william(at)elan.net wrote:

On Thu, 26 Jan 2006, Jim Fenton wrote:

william(at)elan.net wrote:

On Thu, 26 Jan 2006, Mark Delany wrote:

Right. So the question is, can a signature be constructed such that it
doesn't interact with SSP to infer a binding above and beyond "I claim
it passed through me"?

Make 'i' optional.
'i' is optional, but takes the value @d if it is missing.

Then define it so that it could have empty value ("i=") that would
mean 3rd party signer, not associated with "from".
It's already a third-party signer any time i= (or its default value if
it's absent) doesn't match the From address.  It doesn't have to be empty.

My preference however is to have field in signature that specifies
what type of email parameter the signature is associated with (i.e.
see 'id' segment of metasignatures).

If we know this, presumably one could tell, for example, whether a
signature came from a mailing list.

I explained it before - the way to it is for 3rd party is to associate
signature with signing host itself. For mail list this could also be
directly associated with listid (per RFC2919 list-id has similar format
to hostname). The result is that you know for sure that email message
came from mail list (even if it has afterward been forwarded) and can
make the reputation decision based on how well the mail list is run
(i.e. its clean and uses good anti-spam and anti-forger policies, etc.)
Associating the signature with the signing host (or listname(_at_)host) is
what I expect a mailing list would do.  But the reputation decision is
required to really know that it's a list.  It's not sufficient to see a
list-id or any other header field to know its role.

But it's the signer's assertion what their role is:  one might
imagine setting up a rule, "I'll accept any messages re-signed by
mailing lists."  So the Bad Actors will just start adding a few more
headers, and all of a sudden you're getting lots of mail from the
unbelievable-deals(_at_)example(_dot_)com mailing list, with
messages from "people" talking about what great deals they got.

See above.

Since there's no way to know what the role of the signer really is,
it's not a useful piece of information.

You're wrong - the information is still useful. If we take your
view that additional info coming directly from me is of no use,
then fields like Received (and in fact any trace fields) are also
of no use, since I just claim that. Similarly in fact for most
origin fields, like say "reply-to".
I get lots of falsified Received header fields.

What is useful is who the signer is, and then the verifier or
recipient might recognize it:  Oh, it's signed by mipassoc.org,
which gives the responsible address as
ietf-dkim-bounces(_at_)mipassoc(_dot_)org(_dot_) I know that's a mailing 
list.

For recipient, its easier to make association of the address with
mail list when signature explains that its a mail list. This makes
processing of this data on recipient end more streamlined. This
does not change the fact that if somebody claims its a mail list
and recipient can not verify from its known list of mail lists
(known may include checking with external accreditation/reputation
authority), this fact is not going to be accepted.
We agree on this.

-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org