Hmmn. I fear I see a lot of searching for our glasses under the
streetlight.
b) so that if Alice sends an advertisement to Bob, and Bob forwards
it to a large number of other addresses, it is clear that Bob, not
Alice is responsible for the messages forwarded by Bob.
Bob is all(_at_)mycompany(_dot_)com, a distribution list with a lot of names on
it. Alice is Krazy Kevin, who looks for lists he can send spam
through. Why is Alice off the hook here? I get tons of mail through
distribution lists, including a lot of spam from Krazy Kevin back when
he was sending spam rather than eating it, and I can't recall ever
seeing a remailing joe job, so this is hardly a hypothetical
counterexample.
it's not a counterexample, it's just a different threat. it's also
an illustration of why you want to authenticate each submission
separately, along with the recipient list.
if Alice sends mail to lists that isn't appropriate for those lists,
we want the authentication to provide evidence that she's done this.
if Bob resends the same message to people who haven't asked to be on
his list, we want evidence of that also. the two cases are not
mutually exclusive, and we don't know a priori which case we need
evidence for.
(btw, I have seen something resembling a remailing joe job. I was
hired to solve a problem that a fairly well known bank had. the
bank's incoming mail gateway had a peculiar bounce format that would
replace the subject message's From field with the bank's address, add
another nonstandard header that essentially said this is a bounce
(but which no MUA bothered to display), delete all received fields,
and send the resulting message back to everyone in the To or CC field
of the subject message. (honestly, I'm not making this up). the
attacker was using this to send porn out and make it look as if it
was coming from the bank. this didn't appear to be ordinary spam -
there was no way to contact the seller - so it appeared to be an
attempt to discredit the bank.)
c) (maybe) so if Alice wants to send advertising to Bob with the
promise that she will pay Bob $1 for reading it, Bob cannot
distribute the message to N of his friends so that they'll each get
$1 also.
Hmmn. Pay to read ads systems already exist, and they work by putting
a unique URL in each message that you can only click once. Can we
agree that this is not a problem that anyone has asked us to solve?
sure, we can discard that case.
I think things need to be as easy to understand as we can make them,
but not so simple that it misrepresents reality when there's an
important difference between cases.
I think we're trying to define a scheme that provides a level of
accountability that is useful for evaluating incoming mail, not
something that captures the semantics of every possible relationship
among a group of people.
that's not what I'm trying to do. I'm trying to make sure that we
don't design DKIM in such a way that it conflates different cases
that need to be handled differently, and also so that DKIM might
actually be useful against spam.
Well, DKIM doesn't make it through this list unless you use l=
and z=. :)
We definitely had this argument before.
what's this "we" stuff, white man? we don't even have a WG yet and
you're trying to insist that this is already a settled issue?
You cannot expect signatures
to survive mailing lists (as opposed to courtesy forwards) unless you
loosen the signing algorithm to the point that it will accept
mutations that people wouldn't consider to be the same message, e.g.,
adding new MIME parts.
well, the real world seems to be moving in the direction of doing
fairly arbitrary changes to messages even if you don't consider
mailing lists. consider the ongoing OPES work, for instance.
there's an inevitable tension here between the desire to authenticate
messages and the desire to filter out bogus parts and convert other
parts. it's not clear to me that the canonicalization stuff in
current DKIM is anywhere close to realistic.
anyway, we're going to have to have some way of resolving that
conflict and if DKIM wants to be successful it's probably not going
to be either "lists can't mung messages at all" or "lists invalidate
DKIM signatures". because it's too useful to be able to validate a
signature of a message that has been sent through a list, and it's
too useful for lists to be able to mung messages (though i'd be happy
to see less of this).
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org