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: Brad Knowles (blkskynet.be)
Date: Tue Jun 06 2000 - 09:32:00 CDT

At 10:04 AM -0400 2000/6/6, Greg A. Woods wrote:

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

        It may do reading and writing of the message store (mostly
deleting messages or moving them from folder to folder), but from the
server side that is totally unrelated to the injection of mail
messages.

> 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 don't give a flying mongolian cluster sexual intercourse about
client-side "efficiency", since this has absolutely nothing
whatsoever to do with server-side scalability.

> 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.

        Users don't keep the connections open all the time. They
download their e-mail, read it locally, write replies, then upload
their outgoing e-mail and check their inbox again. Anyone who keeps
the connection open all the time is wasting major resources on the
server, the access system (now they have to have a modem for every
user), and on the transport network itself.

> 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).

        No, not at all. I use different authentication systems that are
architected exclusively for the outbound mail system and which are
dedicated to that purpose. They are totally separate and distinct
from the authentication systems that are used for users logging in to
download their e-mail.

        Furthermore, I have my outbound mail relays outside the firewall
(although they have their own host-level firewalling) because the
majority of traffic our users have to send is for other addresses off
the system, while the POP3/IMAP servers are inside the firewall since
obviously that traffic must be 100% for our users exclusively.

> 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.

        I don't want to unnecessarily tie the inbound to the outbound
systems. Right now, I have one primary inbound MX, one backup
inbound MX, and one back-end POP3 server (which we can scale by
adding more POP3 servers). However, I have multiple outbound mail
relays.

        I want to be able to add more outbound mail relays if that is
what I need, without being forced to integrate them into the
POP3/IMAP/TMSAP/whatever-the-hell-you-want-to-think-of-it-as system,
and if I need more resources on the front-end MX servers or the
POP3/IMAP system, I want to be able to add those without affecting
the outbound mail relay system.

        When you scale systems to handle millions of users, you want to
be able to define the roles of machines as tightly as you possibly
can, so that when it comes time to have dozens or hundreds of them,
they are all cookie-cutter installs, and you can add resources to
only those parts of the system that actually need them.

> 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.

        See above. You are not comprehending the scalability issues.

> 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.

        Correct. That should be a separate protocol on separate servers,
since they have very different requirements.

> 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.

        If you choose to tie all your servers into the "one machine does
all" model, then so be it. However, I should not be required to do
the same.

> 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.

        True enough. However, when more than 50% of all sites support
this sort of technology and will use it by default (when available),
and given that most mail flows are point-to-point (technically SMTP
is store-and-forward, but usually it gets stored at their ISP just
long enough to be transmitted to the machines owned by the ISP at the
other end, and that's it), then the majority of mail transport will
be secured.

        In that context, it makes sense to try to secure the message
submission as well. In fact, it makes sense to try to secure the
message submission well before that point happens, because the "last
mile" is usually the hardest to secure, seeing as there are so many
different implementations that all have to be fixed.

> 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.

        True enough. People need to use message encryption if they want
to prevent that from occurring. However, assuming you "trust" the
admins of the sites where the MTAs encrypt communications between
each other, then link-level encryption does help ensure message
integrity and freedom from spoofing and man-in-the-middle attacks, if
not message security from the administrators of those systems.

> 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.

        That's a marketing problem, not a technical one. They need to be
careful to make clear what is being protected and what is not, and
that if users want to keep their messages secure from the prying eyes
of everyone, then they need to use end-to-end message encryption. 

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blkskynet.be>                || Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49             || B-1140 Brussels
http://www.skynet.be                         || Belgium