On Sep 11, 2006, at 8:51 PM, Hector Santos wrote:
----- Original Message -----
From: "Steve Atkins" <steve(_at_)blighty(_dot_)com>
To: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Ah, I misunderstood. Your concern is that some mail transports,
including mailing lists, will invalidate a messages signature,
causing it to be unsigned.
That's certainly true, though I see it more as an example of
the futility of expecting DKIM, and anything based on it,
to be able to decide between "this is authorized mail" and
"this is unauthorized mail" rather than between "this is
authorized mail" and "I don't know whether this is
authorized or not".
Practically, as we knew since the beginning, the main problem is
with the
middle ware such as list servers, mail bots, etc, that offer the
highest
potential for damage.
The more direct transports will probably survive because for the
most part,
most systems, the BCP is to honor the passthru concept. In fact,
as a side
note, there is legal precedence and a current appeals court case
dealing
with this very concept of "who owns passthru mail." (ISP was
screwing around
with routed mail for anti-competitive reasons and was sued based on
US EPCA
grounds; lower court ruled in favor of the ISP, but most experts
agreed it
was a wrong decision based on decades old tradition. It is under
appeal and
most legal experts believe it will be overturned).
So with normal email, I'm sure there are the exceptions, I have
little or
less concern as it should naturally and expected to work.
But with list servers, that's a different story and since we are so
intent
in making it work or "fit" with list servers, well, I can only
express what
we would need to do in changing our software to accommodate this DKIM
engineering request.
I certainly think that not breaking DKIM signatures will be a mild
positive
for mailing list software, and in product terms it's probably a smart
thing
to do. Why break something if you can easily avoid doing so?
The main issue with the list server problem is the "cry wolf"
syndrome and
the inevitable high potential to ignore DKIM signature simply
because they
will have a high rate of failure in mailing list. Isn't this what
happen
with SMIME/PGP mail? Whenever I see a OUTLOOK popup saying this
message has
failed SMIME, I pretty much ignore it. I asked the mail author why
he is
sending SMIME signed mail via a mailing list if its going to fail
all the
time? What's the point? What happens if some bad guys spoofed him
with
HTML virus mail? The "cry wolf" dilemma now has the potential to
hurt me.
I don't expect MUAs to pop up warnings or anything similar when they
seen unsigned mail. I wouldn't be surprised to see something akin
to a web browser "locked padlock" or colored browser bar GUI element,
but I think it would be a big mistake and a big disservice to users to
do that.
There are several reasons I think that it would be a mistake, but the
dominating one is that a message being signed doesn't mean that
it's trustworthy (of which the c1t1bank.com problem, and it's i18n
parallels is just one example).
I wouldn't be surprised to see one or more external, non self-
publication
reputation services that tie a DKIM-identity to a real-life identity
(the
"This is a bank" popup, say), but given the standardisation of DKIM I
expect these services to just happen, and they don't need any
standardisation or much discussion in advance.
The primary value of DKIM and any extensions that seem to be directly
in scope for this group is at the ISP MTA point, where it can
be used to accurately send feedback reports and maintain reputation
statistics for "honest" senders. By "honest" I don't mean anything more
than a sender who consistently uses a DKIM identity.
As far as reputation is concerned I expect that an unsigned email
and a signed email from a new signer will be treated identically
by recipient ISPs that don't have a political axe to grind. The DKIM
signature will be used to identify the entity whose reputation will
be improved or damaged by each email they send. But I don't
expect that simple existence of a DKIM signature will ever
be a positive in itself, at the majority of recipient mailboxes. (I'd
expect it to be a mild negative, at most places, for a range of
reasons).
If the MLS was supportive and added 3rd party signatures, then we
simply
need to work out the consistency of what it means in regards to the
original
domain.
This is the other source of conflict in the group:
uncontrolled vs. controlled 3rd party signers.
I think once we get pass that hurdle, we are pretty much covered as
best as
we can do it.
I can happily agree that it seems to be a source of conflict. :)
So overall, I think its doable but it will also mean the original
domain
itself has to be more aware and responsible of what it is doing by
adding
DKIM into its mail system.
That's true, and has a number of implications. One is that senders
need to understand what DKIM is, and isn't, which is going to make
the marketing of DKIM as solution a bit tricky. Another is that we don't
actually know yet exactly what the implications of DKIM signature will
be. I'm pretty sure I can predict it to a couple of decimal places, but
that's different from knowing.
So some decisions might best be deferred until we've deployed DKIM
and gained some operational experience with -base.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html