There is nothing stopping spammers from generating new keys and certificates
for their mail servers, so we can have servers exchange certs, but really
not authentication there as far as who is who.
Slightly better is if server must have a public certificate verifyable
though DNS, then whatever name is at EHLO, it can be checked at DNS and
then you know who it is. This does not stop spammers from adding their
certs into dns either, but at least then we are requirying them to have
valid dns record for mail server and they really do not like that idea...
(but they can still just get new domain for $6 which is real cheap as far
as preventing abuse and changing domains all the time - to stop some kind
of ip block verification has to be done or DCC like system).
In the far future, this can possibly be tied to reverse ip certs. Currently
there are discussions on possibly distributing certs to ISPs by RIRs (for
S-BGP - yes I know - its somewhat unlikely in the next few years) and if
properly used you could have the ISP when gives ip block to customer, it
could be required to sign their domain cert, then we have some level
of signage from central authority (i.e root dns->RIR->LIR->ISP->Domain
Host->Mail Server->User) but I'm just dreaming here...
On Tue, 1 Apr 2003, Jason Hihn wrote:
Well, you don't need a formal PKI that does end-to-end encryption.
If you encrypt between mail servers, and let the last leg be unencrypted
you'd get the same effect (keep POP3, IMAP for incoming, SMTP outgoing, but
once at the server, the server can use it's own randomly and routinely
generated keys, it just has to honor any incoming mail generated on a
recently expired key)
While that is NOT authentication, it does get us a level of control. Pub key
denial (due to blacklist) is one advantage. Another is the lock-step nature.
A down side is unless the server serves out keys for accounts it doesn't
have, it can be used to validate accounts. Still, with a good RBL, the
effects should be minimal, as any spamming server will be denied.
Also, because the server holds the keys, it can still scan the messages.
Note, that this still works without "encryption" if we change our thinking
to "tickets" (permission to send to an account, because that's all we're
really asking for) everything above still works.
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of
Hallam-Baker, Phillip
Sent: Monday, March 31, 2003 8:33 PM
To: asrg(_at_)ietf(_dot_)org
Subject: RE: [Asrg] How to defeat spam that uses encryption?
From: "Eric D. Williams" <eric(_at_)infobro(_dot_)com>
...
All: A question is the discussion of end-user MUA
technology uses of encryption
something people want to address as a 'spam' control solution?
It's a complete non-starter and waste of time, because it suffers
the threshold problem in the worst way. Early adopters get no
benefit and many hassles. Despite decades of work, the mechanisms
to distribute keys are practically useless. The user interfaces
are coming along, but they're still poor and sometimes just
don't work.
The mechanisms designed to distribute keys are fine. The problem
is the attempts to use X.500 and LDAP for this purpose which are
longstanding abject failures.
The problem with encryption is that encrypting a message says
NOTHING about its authenticity. I can send you an encrypted
message that purports to be from anyone I choose. To get any
statement about authenticity you need a signature.
You can sometimes justify the practical hassles of encryption for
keeping your communications private, but that avoids the threshold
problem. Many of us have used at least PGP for professional reasons,
but that's a whole other world.
Don't project your experiences of PGP onto PKI. PGP has a very
specific design which is fine for its intended purpose but that
is not to provide a PKI.
Encryption, whether signing by senders or decrypting by receivers, is
useless against spam until almost all of your correspondents use it.
It is useless against spam at any time.
Authentication is useful as a means of bypassing spam filters and
avoiding false positives even if relatively few people use it.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg