OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: pop-before-smtp (was Re: FreeInet and checking mail?)
From: Greg A. Woods (woodsweird.com)
Date: Tue Jun 06 2000 - 09:04:55 CDT

[ On Tuesday, June 6, 2000 at 12:52:12 (+0200), Brad Knowles wrote: ]
> Subject: Re: pop-before-smtp (was Re: FreeInet and checking mail?)
>
> I disagree completely. From the infrastructure point of view,
> reading is absolutely nothing like writing, and therefore attempting
> to shoe-horn one of the processes into a protocol designed to handle
> the other is an inherently bad idea.

Well since IMAP already does "reading and writing" I'm not sure what you
mean.

> If you're talking about tacking message submission onto POP3
> and/or IMAP, then I do not see how the server side could possibly be
> done in a scalable fashion.

It shouldn't be that hard. As I say it even simplifies some issues of
scalability since the MUA will possibly already have a connection open.
I.e. the factors on network resources are almost zero, while memory and
CPU resourses would require only a minor increase that would remain
constant over the number of connections. Furthermore there's no need to
repeat the authentication and authorisation steps if they've already
been done for IMAP thus decreasing the load on any resources involved in
this step (as well as potentially simplifying the distribution of such
services amongst clusters of similar servers). I.e. I can't even fathom
what scaling issues you're worried about -- it should scale just as
easily, if not easier, than any separate IMAP and LMTP/SMTP scheme would.

Maybe from the end user's point of view things might not be as
"efficient" as some power users might wish, but I'm not so sure that's a
bad thing.

> Even then, if the servers which handle users reading their mail
> have to also handle the submission of mail, I can't see how this
> could possibly be implemented in a scalable manner.

It all depends on what you mean by "submission"... I simply mean the
very first hop of accepting a message for delivery from the remote MUA.

> The requirements for a server to handle "reading" mail are
> totally different from the requirements for a server to handle the
> submission of mail.

Some simple processing would be most logically done on the server
handling message submission (i.e. in the IMAP server, should it perform
this function), however there's nothing implied that would even suggest
that the submission server has to learn to deliver e-mail to the rest of
the world -- it would only forward it to a "real" relay host that would
be running a full Postfix (or whatever :-) implementation.

> When we're talking about TLS being turned on by default in
> sendmail 8.11, I think we can assume that fairly soon, there will be
> a large number of servers in the world that use inherently secure
> methods to transmit mail between them (because both ends will support
> it, and both ends will use it by default if the other end also
> supports it), and within a year or two you should see the majority of
> communications taking place over secured channels.
>
> In that kind of environment, it makes a lot of sense to do the
> same at the message submission level, too.

I don't think so, though of course it depends on exactly what kind of
network medium separates the end user's MUA from the message injection
point.

End-to-end confidentiality and integrity is still not provided in that
kind of environment. Transport security between MTAs delivers only a
limited assurance that the messages handled are not viewed or changed by
unauthorised parties. Certainly there are major advantages to this when
considering the protection it will give from the most casual of
observers (eg. the prying eyes of major governments and organised crime)
and as such it may do a lot to change the way people think about
encryption. However it will do nothing at all to guarantee that any
message you send through your company's or ISP's mail servers has not
been examined or even altered by who you might consider to be
unauthorised persons w.r.t. any given message.

So given that the message security will rely on the security of the
systems (and perhaps even on the security of internal networks, in some
cases) of intermediate third parties there's still no confidentiatiliy
or even integrity guarantees, even if the message submission protocol
runs over a secure transport. Certainly if there's any question as to
the privacy of the medium between the MUA and the server then transport
security will mitigate the risk of disclosure, but *only* over that
particular hop.

I.e. what I'm very afraid of is that the average end user will be lulled
into a totally false sense of security by the claims of MUA and MTA
"vendors"; claims that may very well be true but are bound to be
misunderstood by layman. 

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoodsacm.org>      <robohack!woods>
Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>