ietf
[Top] [All Lists]

RE: namedroppers, continued

2002-12-09 10:12:02
Don't discount the unexloited features already supported in the deployed
base.

In particular most mail servers support inline SSL connection upgrades,
or can be upgraded to do so with minimal hassle.

Another instance in which a self signed cert is possibly sufficient
authentication - although when you consider the security you get from
upgrading the connection to SSL the price of the cert is kinda de
minimis but I'll play along with the rulling IETF assumption of millions
for hardware, not a cent for software.


                Phill

-----Original Message-----
From: william(_at_)elan(_dot_)net [mailto:william(_at_)elan(_dot_)net]
Sent: Friday, December 06, 2002 3:59 PM
To: Marc Schneiders
Cc: Fred Baker; Hallam-Baker, Phillip; ietf(_at_)ietf(_dot_)org; 
iesg(_at_)ietf(_dot_)org
Subject: RE: namedroppers, continued


I'v been saying about need for more radical change in mail
protocol for
years now on mailing lists. I'd rather work on smtp itself, but some
people who were involved in original protocol do not want any serious
changes to what they'v done, though its clear that abuse and
other holes
with current system is creating too many problems.

In any case, by next ietf meeting in san francisco, I'll
bring complete
proposal for new protocol and might even try some practical
tests. I do still
believe that smtp can be saved, but not without more complex
authentication
system during delivery of email and that can't be done with current
protocol design or current available extension process.

Also were there any discussions or more complete discription of this
algorithm for checking if host had sent an email and if so is this
available on website or archive to read more about? If answer
is yes, can
somebody send me url or approximate date of discussions so I
could lookup
in archives.

And am I correct here in understanding what was proposed is that smtp
conversation id be such that receiving mail server could verify with
sender (callback?) that it deed indeed initiate the email. If
so I do not
quite understand how MD5 helps there, plus I see quite a few
problems with
creating some special mx-like record in dns just for verification. If
this is indeed what was proposed its better to go with paul vixie's
proposal of mailfrom dns record -
http://www.vix.com/~vixie/mailfrom.txt or
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt

On Fri, 6 Dec 2002, Marc Schneiders wrote:

On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote:

I think it was Steve Bellovin that suggested a procedure for
reducing the
utility of spoofing source addresses in emails; if not, it was me
and I
happened to suggest something his favorite algorithm fit into, by
having a
host in each mail domain (mailid.example.com) be able to assert that
its
domain had or had not sent an email within a given recent  time
period
whose MD5 hash, when divided by <vector of prime numbers> resulted
in
<vector of remainders>. I could write that up in an internet draft
if folks
think it makes sense. That would be a more global procedure that
didn't
require a PKI and only addressed spoofed addresses.

Spammers would be the first to set up your mailid host. They will have
had years of experience to find holes in the system before you've
convinced everyone to adopt or accept the mailid.

It might be easier to write a new protocol to succeed email, instant
messaging, mobile phones (something useful in itself) with built-in
abuse control from the start.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>