[wplug] IMAP revisited... to send mail?

Bill Moran wmoran at potentialtech.com
Sun Nov 21 11:21:30 EST 2004


Brandon Kuczenski <brandon at 301south.net> wrote:

> On Sat, 20 Nov 2004, Brandon Kuczenski wrote:
> 
> > On Sat, 20 Nov 2004, Bill Moran wrote:
> >
> > > On Sat, 20 Nov 2004 08:47:36 -0500
> > > "Jonathan S. Billings" <billings at negate.org> wrote:
> > > >
> > > > On Nov 20, 2004, at 8:34 AM, Bill Moran wrote:
> > > >
> > > > > So stuff had to be added to SMTP to secure it.  SASL is a component of
> > > > > SMTP AUTH.  SMTP AUTH allows a user to authenticate to the SMTP server
> > > > > before using it, SASL is how the SMTP server determines whether or not
> > > > > that authentication succeeds or not.
> > > >
> > > > I should note that SASL is also used by imap and other services to
> > > > negotiate authentication, as well negotiating the security layer for
> > > > the protocol.  So you might see it in your IMAP configuration as well
> > > > as MTA.
> > >
> > > Good point.
> > >
> > > SASL is the underlying method of authentication.  SMTP AUTH is the way
> > > that SMTP uses SASL to do its job.  IMAP and POP could use SASL as well.
> > > In fact, I think you could (potentially) use SASL for all authentication
> > > (even login) although I don't know of anyone ever doing so.
> > >
> >
> > Okay, so this is helping, somewhat... Again, tell me if I have it right.
> >
> ...
> > Maybe beating myself over the head with this for 18 hours straight is not
> > a good idea....
> 
> I'm calmer now.  I think I have it -- at least, in a broad, conceptual
> sense.
> 
> Really, postfix's job is simple: accept mail, and when doing so from
> remote sources, require them to authenticate first.

The determination (on Postfix's part) as to whether to require authentication
is almost always based on the _destination_ of the mail.  Mail destin
for the local machine will always be accepted.  Mail destin for remote
machines requires authentication.

Thus, delivering mail is available to anyone, but _relaying_ mail is
only available to autherized users.

> For security, the
> authentication must be performed with a layer of encryption (SSL/TLS)
> (still not quite clear on the difference between SSL and TLS, but I would
> guess it's one of nomenclature).

I may be wrong, but:
SSL requires that both the client and server to know about encrytion right
off the bat, and use it from the get-go.
TLS allows the server and client to communicate (unencrypted) and to
determine that they both support TLS, and determine whether they want to
use it or not.  Thus an SSL connection must always be SSL, but a TLS
connection can (depending on configuration, of course) be TLS or
unencrypted, based on negiotiations when the connection is made.

> A mail client connects to my port 25 and
> tells postfix to STARTTLS.  Once that's happened, communication is now
> secure (assuming the client accepts the server's certificate), and so the
> client AUTHenticates.

Yes, except those two steps are seperate.  It's possible for:
1) no TLS, no authentication
2) using TLS, but not authenticated
3) Authenticated, but not using TLS
4) Use TLS, and authenticate

#3 is never a good idea.  #1 is usually OK, as an unauthenticated connection
is not guaranteed to be secure anyway.  #2 is often unnecessary overhead,
but doesn't hurt anything.

> Here's where SASL comes in: it provides a way for Postfix (or any program)
> to interface with an authentication database, and provides some tools for
> maintaining that database, but really it expects to use something like
> /etc/passwd or an SQL database or something (this is for scalability, I
> would guess).
> 
> And that's the difference between transport-level security and
> authentication.

authentication is ensuring someone is who they say they are.  encrytion
is ensuring that only the intended recipient of a communication can
decypter it.

SSL/TLS are best known for encryption, however, they _do_ provide an
element of authentication.  (stick with me, this can be a little
confusing at first).  SSL/TLS do _not_ provide a way for the user
to authenticate to the server.  Instead, they provide a way for the
server to authenticate to the user (or, potentially, for servers to
authenticate with each other).  That is where certificates come in
(certificates are not necessary to encryption).  A certificate proves
that server X really is who it says it is, and protects you from
hijacked DNS servers pointing you to systems that pretend to be your
server.

> What's really neat about this is that once I have this setup I could tell
> postfix to act as a secure client as well -- and only deliver mail when
> SSL is used.

Yes.  The part that's (currently) missing from the standards, is a way to
specify _in_ the _email_ that this email must _always_ be transported
securely, thus telling Postfix (or whatever program) when TLS was
required, on a message-by-message basis.

I suspect that it will be difficult, or impossible to adjust the standards
to make that work.  Bummer.

> That way, if I ever fear an overzealous Justice Department
> or a nosy ISP, or if the free world becomes overrun with terrorists, or I
> have an ugly breakup with some l33t hacker girl, I can encrypt ALL my
> email (and simply not correspond with people who don't provide TLS on
> their mailserver).  It's really a very different issue from setting up an
> IMAP server.

Correct.

> My problem is that I hate setting a problem down in the middle, unsolved,
> which leads to these marathon weekends during which I'm buried in man
> pages and howtos.
> 
> Does everybody go through this?  is it a phase?  Or am I doomed to
> struggle with every system upgrade and every service rollout?  Am I too
> old to become a Jedi?  People who started hacking when they were 8 don't
> have this problem.

Pretty much.  I don't know anyone who hasn't put in their share of long
nights and weekends figuring things out.

The good news is that it gets easier the more you learn.  As you understand
more things, you find that most new things that you're learning are just
adjustments or refinements to things you already know.  But it takes a
good number of long nights and weekends to get to that point.

As far as being "too old to become a Jedi", I've have some pretty strong
opinions on education.  I've never been a professional educator, but I
do a lot of educating.  The following my generate a "holy war".

The most common problem I see is previous education that failed or was
poorly done.  The _most_ common is when someone _thinks_ they understand
something, but they really don't, then they are confused as to why they
can't learn things that depend on that knowledge.  The thing that
surprises me is when folks don't recognize that their difficulty learning
is the result of prior learning mistakes.

This may have to do with sociatal misconceptions.  I've met a lot of
people who think that "this stuff is just to hard for me to understand",
or "I'm not smart enough to learn that".  In any case that I've bothered
to hunt it down, it's always boiled down to something that the person
thought they had learned that they hadn't fully learned, or that they
were missing pre-requisit knowledge that they thought they could do
without.  I've never met a person who I honestly believed "wasn't smart
enough to learn something".

That's enough philosophy for today.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com


More information about the wplug mailing list