-----Original Message-----
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Thursday, January 24, 2008 3:52 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: MH Michael Hammer (5304)
Subject: Re: [ietf-dkim] Re: the entire world will change
their mail systems so that SSP sort of works
I'm not misrepresenting other peoples arguments at all. If the only
signature on the message is from a 3rd party and there is an
opportunity to check for the assertion of the purported From domain
that is not taken, that in fact is giving more weight ... to the
signature of the third party ...
Right. Let's look at the message you just sent, and imagine
that the list signed it with a mipassoc.org signature. Since
I know that Dave runs his lists well, I'm done. The
"opportunity" to check something else is irrelevant, as is the
fact that the list would have broken your signature.
You are picking a particular case structured by yourself to say "See,
this check is irrelevent". You ignore any other use cases regardless of
outcome. To construct a standard on a single constructed case (I trust
Dave!) is a mighty interesting approach. DKIM provides a standard
approach to signing. It allows anyone that handles a message to sign it.
But what to check? What if you have 10 signatures? What if the email
isn't from a list run by Dave? I haven't heard anyone suggest that you
MUST send the message under consideration to /dev/null if not signed by
From and SSP is checked. Do what you want. Why does doing the check feel
so onerous from your perspective? It helps in a number of cases and
doesn't require you as a receiver to do anything based on the check if
you choose not to. When Doug goes after SPF because of his perception
that checks may impose significant resource overhead I can understand
his concerns even if I don't agree with him about the risks. Where is
the problem with requiring the check in specific circumstances?
The fact that the list (may have) broke my signature exists whether I
publish SSP or not. Receivers will start to make decisions about broken
signatures as they gain more experience. Perhaps broken signatures will
make signers more cautious about what they put in SSP. Perhaps not. The
potential for a broken signature exists regardless. Are you concerned
about my broken signature because you fear you will miss my wit and
insight because your sofware will reject my message? Then have your
software send my messages to a special place and check for it. Tell your
software to ignore my broken signature. Requiring a check as part of the
standard simply ensures a standard hook for whatever the receiver
chooses to do. One is not forced to implement SSP.
You are arguing the case of "your trusted friend", the mailing list.
There are alternate ways for a mail list to function rather than
present the "from" address header from another domain.
Now we get to the nub of the fallacy.
Mailing lists like this one have been around for a rather long
time, quite possibly since before you were born, and they're
not going to go away. Lists are not and never have been a
significant phishing vector, but even if they were, there are
plenty of ways to address that without demanding that everyone
in the world change their software. If that's what you
expect, you're wasting your time.
No fallacy. Change or don't change. Accept or don't accept. Use or don't
use SSP. Lists may not be and may not have been a significant phishing
vector. And my question would be, what is your point? Lists have been
subject to other types of abuse. DKIM and SSP may or not be pertinent.
Don't think of it as domains wishing to make strong assertions breaking
mailing lists. Think of it as domains making strong assertions
voluntarily excluding themselves. They value security more than the
pleasure of your company on a list that does not respect their assertion
with regard to their domain. They wish to be master of their domain. If
they wish to have the pleasure of your company they will either have to
change their assertion/practice or participate using another account at
a more flexible domain.
You mean you didn't notice my grey beard when you were speaking with me
in person (DC MAAWG)? During the timeframe (first mail lists) you refer
to I was playing with S-100 buss stuff (altair) and IMSAIs on a personal
level. At school I was using card decks on an IBM mainframe running
HASP. You are right. Change is bad and we should go back to the day
where if you wanted a keyboard on a "personal" computer you could rewire
a teletype terminal if you so desired. Roll back 2821 and 2822. 821 and
822 are all we need. We don't need no stinking ESMTP! Let's all go back
to CP/M for an OS. I used to help run a BBS. We had forums where people
had communities. Along came the intartubes and BBS left the mainstream.
Now we have forums and blogging.
I'm not demanding that everyone in the world change their software, far
from it.
People sometimes do change the way they do things. Sometimes fast and
sometimes slow. Sometimes one subset chooses to change and another
subset chooses not to change. In most cases I believe in people making
choices. The right to make choices (which I consider fundamental)
includes the right to make poor choices. Given the importance of this
issue I hope that more than 10 people step up to the plate and chime
in....regardless of which way the decision goes.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html