ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP and mailing lists

2006-09-11 21:24:19

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