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: Wed Jun 07 2000 - 04:16:21 CDT

At 1:52 PM -0400 2000/6/6, Greg A. Woods wrote:

> Well then that's outside the scope of my concerns. I want strong
> accountability from the postmaster's point of view -- i.e. I do not want
> an annonymous collection box on the street corner, but rather I want
> something more akin to commercial couriers who often require an existing
> valid account before they'll accept a package for delivery, or indeed
> the outbox on everyone's desk such that the mail clerk can verify who's
> doing the sending.

        I have no problem with that. I have a problem with requiring the
inbound POP/IMAP servers to also handle outbound mail (even if they
just pass it off to another set of servers that actually interact
with the outside world). They're simply not designed to handle this.

> You seem to be solving different problems that I am. Indeed outbound
> mail relays still have to be secured, as do the IMAP servers, but that's
> only part of the picture that I'm interested in.

        And only part of the picture I'm interested in. However, I do
not want to unnecessarily tie parts of these systems together. They
are logically and architecturally separate, and any attempt to tie
them together is doomed to failure.

> Once again I can't see where I've made any such assumption.

        By using a message access protocol as a message submission
protocol, you have made this assumption.

> Just as there's no need to point your inbound MX at your IMAP server,
> neither is there any reason to force you to make your IMAP server also
> deliver outbound mail to the Internet. With IMAP message submission I
> too can have as many IMAP servers as I need, and I can also have as many
> separate outbound mail relay servers as I need (running Postfix, or
> whatever! ;-).

        The problem is that 99% of the work of handling a mail message is
in handling the connection, accepting the message, and then writing
it to a message store. The handling of the actual delivery attempt
from message store is relatively light.

        By forcing the POP/IMAP servers to handle message submission as
well as message access, you're doubling the amount of work they are
required to do, and for no good reason.

        The problem is that POP/IMAP servers cannot *POSSIBLY* be any
where *NEAR* as fast and efficient at the process of handling message
submission and message transmission (even internal message
transmission to a separate set of servers that actually communicate
with the outside world), as programs like sendmail and postfix can be.

        In fact, they are *GUARANTEED* to almost certainly be orders of
magnitude *WORSE* at this process than programs like sendmail and
postfix, since now you will have created a system that not only has
to handle everything there is to handle with POP and IMAP, but now
they also have to handle everything there is to handle with SMTP
(since the messages would have to be "transmitted" somehow).

        Sendmail is a huge enough hog of it's own. So is IMAP. Do you
*REALLY* want to put all of Sendmail inside of an IMAP server?!?

        Postfix is much slimmer than sendmail, and more inherently
secure. But can you think of a single IMAP implementation where you
would want to incorporate even all of postfix into it?!?

> Sure! Go ahead! The more the merrier. I've already said this. You do
> not have to integrate them at all. There are an almost infinite number
> of ways of forwarding the submitted message to the outbound mail
> delivery system(s) -- that's merely an implementation detail.

        Key word -- "forwarding". You've already integrated them, which
is *PRECISELY* what I want to avoid in the first place.

> Once again: "No Problem(tm)!"

        Show me systems that you have scaled to handle millions and tens
of millions of users, and I might be willing to listen to you.

        Until then, you clearly have absolutely no concept whatsoever of
what you are talking about, and if you persist then I will just have
to add you to the filter I have that throws away all e-mail I receive
from certain other people (such as Dan Bernstein).

> Note that if you've already solved the IMAP server scaling and
> reliability issues then you'll also have much more direct control over,
> and many more options for, the way you handle outbound mail relay load
> sharing and reliability if you handle message submission through IMAP.

        No, this is fundamentally wrong. See above.

> I certainly did not say anything of the kind.

        Essentially you did. By handling everything through IMAP, you
require that "one server does all", which is the worst possibly model
that could be applied to any system that might need to be scaled to
handle millions or tens of millions of users.

        If you don't understand this, then you fundamentally do not
understand the issues behind scaling, and you should not be
attempting to discuss them.

> I have never liked the idea of using SMTP for message submission. When
> I first read about POP over a dozen years ago I was dismayed that it
> didn't immediately deal with the issue of message submission, either
> within itself or with a companion protocol.

        Have one protocol that does one thing, does it very well, and
does nothing else. This fits the Unix "toolbox" quite well, and is
the only method I know of that allows for maximum system scalability.

> How can you trust an admin who may have been issued a "wire tap" order
> or whatever -- something the end user would explicitly be prevented from
> discovering? Even if you're not the subject of the wire tap you may not
> want your e-mail to be scanned! ;-)

        This is a different subject entirely. If you don't trust them at
this level, then you must use end-to-end message-level encryption.
And if you are this distrustful of them, then you almost certainly
are already doing this, or are at least aware of the issues involved.

        For those customers, adding link-layer encryption can only help
further secure the transmission of messages that should already be
themselves secure. 

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