Re: [Exim] Yahoo DomainKeys...

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Tim Jackson
Date:  
À: exim-users
Sujet: Re: [Exim] Yahoo DomainKeys...
Hi Andreas, on Wed, 19 May 2004 02:49:20 +0200 you wrote:

> Sorry, but my point of view is that this system is utter bullshit.


It looks like a *FAR* better idea to me than the stupid, broken SPF system
which so many people seem to think worthy of worship. From a first
reading, I'm moderately enthusiastic about this. I'm sure there are lots
of issues to be ironed out, but the principle seems more solid than
similar proposals.

It's only major downside seems to be that in practical terms it is likely
to require that all mail from participating domains originates from
"trusted" servers (via SMTP AUTH or whatever). I don't consider this a
huge downside considering that SMTP AUTH is tried and tested already, and
I can't see how any system of this ilk is likely to work without MUA
intervention unless we push all "trusted" mail through certain servers.
Crucially, however, and unlike SPF, it *doesn't* break forwarders.

> 1. There already exist solutions which require less processing power
>     (think of high throughput MTAs) and are proven to work, e.g.
>     SPF , see spf.pobox.com (Greg? <me ducks>)


SPF is completely broken. Granted, it doesn't require so much computation
but since it breaks forwarders (without the entire world adopting hugely
complicated and messy envelope rewriting) it's as good as useless. Given
the huge advances in computing power since SMTP was invented, I think that
the extra computation to do some hashes is a price worth paying. Also,
given that Yahoo are promoting this, they clearly think it's viable on a
large scale.

> 2. What I really laugh at is the 'that the message was not tampered
>     with' part. And who the f..k asserts that the message wasn't
>     tampered with between sending MUA and MTA (evil grin)?


It's being pitched as an MTA-MTA system, not as a replacement for S/MIME
or inline PGP. So I don't think they're being unreasonable here. That
said, there certainly is an issue in terms of helping end users to
understand that when a message is "verified", this only means that it made
it from the originating server to the destination server unmodified, but
that modifications at other stages are possible.

> 3. If you wan't to sign a message there's well known and better
>     solutions like PGP/GnuPG that just don't fit a certain company's web
>     mail service.


Whilst OpenPGP is great, and DomainKeys does not replace it, I think we
have to accept that realistically as administrators there is a possibility
that we can at least partially address the "spoofed domain" problem easier
than end users can by using something of this nature. In an ideal world,
everyone would have MUAs which comprehensively support OpenPGP, they would
all use S/MIME and they would all understand web-of-trusts etc. However,
realistically this is not going to happen anytime soon, if ever (though
that's not to say we shouldn't promote it), but it seems that something
like this Yahoo system can solve some problems to a lower standard but in
a way that is transparent to the end user. Comparing OpenPGP with
DomainKeys seems to be comparing apples and pears; the spec itself
specifically mentions that DomainKeys is not in competition with S/MIME
and moreover is designed not to interfere with S/MIME.

> 4. Patent claims? For what? This kind of joke can really happen only in
>     a certain well known country.


Unfortunately this is far from true. A vote just *yesterday* in the
European Council of Ministers means that exactly the same trivial patents
on software, business methods, algorithms and mathematical formulae as are
permitted in the US are dangerously close to becoming a reality across the
entire European Union (including Germany) unless we can all convince our
MEPs to adopt an *absolute majority* in the European Parliament later this
year opposing it. With the elections coming up next month, this is very
timely. See here for more info:

http://kwiki.ffii.org/Cons040518En


Tim