Keyservers and the future
scc4fun at spamcop.net
Fri May 20 16:22:24 CEST 2005
> ----- Message from munged at codehelp.co.uk ---------
> Date: Fri, 20 May 2005 10:15:35 +0100
> From: Neil Williams <munged at codehelp.co.uk>
> Reply-To: Neil Williams <munged at codehelp.co.uk>
> Subject: Re: Keyservers and the future
> To: gnupg-users at gnupg.org
> Are you proposing a completely new key per domain that is "less secure" than
> the personal key because it's per domain and not per user? Who controls such
> domain keys? Is this just another "corporate" key?
> What about domains that have millions of users (like aol.com)?
> I may trust one or two individuals with AOL accounts, there is NO way I'm
> going to trust everything from AOL!
> > If email authentication was implemented, the majority of mail traffic
> > would be signed and verified.
> You're just verifying that the signature is good, not that the key is
> That's reasonable.
> How do you guarantee that From: cannot be spoofed - it sounds like you are
> delegating that to the individual ISP / domain holder. I'm concerned that the
> domain is too blunt as an instrument against spam and that it will remain
> easy to send spam from: aol.com and hotmail.com. Even if someone does
> compromise the AOL terms and conditions, users cannot ignore all email from
> that domain - it's simply too large - so I could not set the aol.com key to
> be untrusted or unwanted.
The idea is not that *you* as a user of email trust that email from an entire
domain is from a particular person or even that it is not spam. But that the
email can be verified when the receving server gets it that it really did come
from that domain claimed in the From: header. It would work at the domain level
between SMTP servers that send and receive mail between domains. The sending
server would have a key that corresponds to the domain(s) and then signs the
"primary" headers and message body and includes the signature as an additional
> This could prejudice small domains, userspace domains, unfairly. The big
> domains would trivialise the signature because you could not discriminate
> between your AOL friends and the AOL spammers. If a particular domain holder
> with lots of accounts is tardy or just inefficient in booting off people who
> abuse their terms, the user is left with a useless "validation" because the
> user cannot distinguish between users at the domain.
This would not be the end-all be-all of anti-spam tools. It would just be a
method to authenticate mail as really originating from a particular domain. You
would still use other tools (eg SpamAssassin, Norton, etc.) to figure out if the
sender is a known spammer/open relay or if the content is (like) spam.
> > DomainKeys, for instance, works at the transport level. Somewhat like
> > SSH, where the client and server use one key to encrypt the datastream,
> > but a different key is used by the user to actually authenticate and log
> > in. DomainKeys does not encrypt the channel, but it only signs it (it
> > signs a subset of the message headers as well as the body of the
> > message). If a recipient domain trusts Yahoo's keys, he can assert that
> > the mail really came from the Yahoo domain. This is a per-domain
> > signature, not per-user.
> Where does the secret key reside?
The sending SMTP server?
> Who controls the signing?
The sending SMTP server?
> What happens with the existing signature?
> Are you using MIME to achieve this - what are you going to do about broken
> email clients like OE that hide the message when receiving PGP/MIME - the
> message body is displayed as an attachment.
No, it would be a header like
> What about other clients (like some webmail) that cannot yet cope with
It would use a header. Also, it would be implemented at the server level not the
> Neil Williams
> ----- End message from munged at codehelp.co.uk -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: PGP Digital Signature
Url : /pipermail/attachments/20050520/58300d03/attachment.pgp
More information about the Gnupg-users