questions on setting up a mail server

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Jonathan
> McKeown
> Sent: Wednesday, September 05, 2007 1:13 AM
> To: freebsd-questions at freebsd.org
> Cc: Jim Stapleton
> Subject: Re: questions on setting up a mail server
>
>
> On Wednesday 05 September 2007 06:25, Ted Mittelstaedt wrote:
> [Jim Stapleton]
> > > I figured I'd try cyrus, I remember hearing that one is a good mail
> > > server. But I'm new to the mail server thing, and I'm not even sure
> > > where to look for some of this stuff if anyone can help. Also, I plan
> > > on just doing POP3, and only allowing secure connections - if anyone
> > > can reccomend a good, simple server for that, that they think is
> > > better than Cyrus, I won't object.
> > >
> > > My main question is on authentication. I was looking at authentication
> > > types in kmail to get an idea of what I can use, and I found:
> > > Clear text
> > > LOGIN
> > > PLAIN
> > > CRAM-MD5
> > > Digest-MD5
> > > NTLM
> > > GSSAPI
> > > APOP
> > >
> > >
> > > I know clear text is not what I want - if I remember, that's
> > > unencrypted. Does TLS/SSL make this a non-issue? What about the other
> > > methdods?
> >
> > Much of this depends on the mail clients that your going to be
> > hitting the server with.
> >
> > The first group does encryption of the password only.
>
> Not sure what's meant by ``the first group'' here.

CRAM-MD5, Digest-MD5, NTLM, GSSAPI, and APOP are associated with
password encryption on SMTP auth and POP3 as you well know, so please
do not try to be deliberately stupid to make a point.  Just make
your point and get on with it.  Most people won't understand
anyway.

>
> > The TLS/SSL stuff does encryption of everything - password,
> mail contents,
> > etc.
> >
> > The TLS stuff requires you put a SSL cert into the client.  Most people,
> > not wanting to pay Verisign for this, make their own self-signed certs.
> > There is a large amount of arcane magic to do this, and to get
> it accepted
> > into Windows, so that an Outlook client will do SSL.
>
> This isn't true, in my experience.
>

Your experience is limited then.  Sorry, but if you think it is
simple, please post a couple pointers.  Don't forget to include
all versions of Windows and Outlook in current use - that includes
Outlook Express 6, and regular Outlook 98, 2000, 2003 that are
part of Office, as well as Internet Explorer 5 and 6 and 7.  Don't
forget to include the scripts needed to generate the keys too.

Sure it is simple - when ALL clients are running the same version
of Windows, IE, and Outlook.  Perhaps true in a small network.  Very
not true in a large network.

> > The first group is a different story.  If you want to get Outlook to
> > work with that, you can only use NTLM.
>
> This is also not true, in my experience.
>

Hmm - earlier you said you didn't know what I was referring to when
I was talking about "first group" now you seem certain that you
do - as you are including LOGIN and PLAIN (the non-encrypted ones)
in the same list as the encrypted ones?  Caught you there.

Everyone supports LOGIN and PLAIN.  (at least I never met a mail
program that didn't - perhaps there is one)  But, you cannot get
password encryption with Outlook Express unless you do NTLM.  It
supports nothing else, except for SSL which is encryption of the
entire channel.

If you know of a way to get OE to support CRAM-MD5 then do tell.

> > The honest to god truth of the matter is that encrypting your POP3
> > and SMTP auth passwords is difficult to do on a large scale no matter
> > what road you pick to do it, so there is really not a lot of point to
> > doing it unless your in a rather limited environment.
>
> I'm not sure I would agree with this statement either.
>

I perhaps should have explained this more.  Encryption of e-mail
is absolutely pointless unless done from mail client to mail client
a-la PGP or some such.  If the cracker can't get the mail sniffed
from client to server he can simply go to the server and get it
when it's transmitted to the other mailserver via SMTP which is
not encrypted.

It is only useful for protecting passwords from wire sniffing.
But in most cases, the wire isn't sniffable.  Your certainly not
going to be able to do it in most corporate networks as ethernet
switching has been in use for a long time now.  Your grandpa's
10baseT ethernet switches would protect as well from casual
sniffing as your modern gigabit ones do today.  And if your
in a corporate environment that still uses hubs you might as
well go home since your in an environment that is such an
antique that it's going to have a hundred holes even easier to
go through than that.  Ditto for unencrypted wi-fi, it does not
belong in a corporate network.

password sniffing only becomes a concern when you have road
warriors who are NOT connecting into the mailserver via a VPN
(many companies do not allow outside connections that aren't
inside a VPN even for popping e-mail) and are NOT using a
HTTPS webmail interface - which is going to be the norm if
the road warriors are using kiosks.  And if the road warriors
are using Blackberries or other PDAs as is becoming popular -
good effing luck, if they aren't breaking your security running
the blackberry client on their PC who knows what they are
doing behind your back.

And even if you have valid concerns on password sniffing well
that's simple enough to address - don't be an idiot and use
the same user name and password for your e-mail clients as
you use for your network and windows logins.

> I've just recently moved a network of 100 users scattered all over South
> Africa, about half of whom are highly mobile and using multiple forms of
> connectivity (6 office LANS, an OpenVPN, ADSL and cellular
> datacards), to an
> encrypted/authenticated email system. I'm using sendmail and
> cyrus. I set up
> a certificate authority (not hard - there are plenty of howtos
> all over the
> 'web) and gave the SMTP and IMAP/POP servers their own certificates.
>

I didn't say doing that was hard.  The problem is that the entire SSL
picture is hard for a newbie.  Most newbies to this aren't going to
be told to set up a CA and generate certs from it.  They will be
handed instructions to tell them to setup host self-signed certs
then be frustrated when their Outlook 98 and 2K clients reject them.
It's only after digging for a long while will they come across
some pointers that will shed the light.

Of course it's gotten better recently but I still see a lot of
people blithly unaware that Outlook 98 and Outlook 2000 will not
accept self-signed certs unless the cert was signed by a CA that
is inserted in the OS, and posting all manner of misleading
instructions telling people this will work.  Sorry folks, not
everyone has the $$ to upgrade to the latest versions of MS
Orafice and get the latest Outlook.

> All the authentication options you mention after plain text (which is the
> standard method built in to the protocol) require Cyrus SASL.
> This isn't as
> scary to set up as the docs make it sound. PLAIN and LOGIN can
> both use your
> existing user passwords (which is what I do). GSSAPI requires
> Kerberos, and
> the digest methods (the -MD5 ones) need a separate file of
> passwords held in
> plain text - the sasldb. Of the passwd-based methods, PLAIN is
> the preferred
> protocol according to the docs and RFCs - LOGIN is the one
> Microsoft uses (go
> figure).
>

LOGIN and NTLM.  PLAIN and LOGIN are identical, it's merely a naming
convention.

> I've configured sendmail and cyrus to use SASL, offering LOGIN
> and PLAIN, and
> to use TLS.

Yes, that is the way that most people nowadays do it, as a result
of the bugs I referred to with different mail clients.  Unfortunately
unlike NTLM this does require the client to accept a certificate
which means the user has to do something.

 sendmail uses STARTTLS on the submission port (587),
> and cyrus
> imapd/popd uses STARTTLS on imap and pop3 (143 and 110), plus SSL/TLS on
> pop3s (995). They are both configured not to offer LOGIN or PLAIN
> (or plain
> text login) without a TLS layer in place.
>
> Clients are kmail (me), Outlook 2003 (everyone else), and a
> webmail system
> using Squirrelmail with up-imapproxy (which is a caching proxy,
> and also does
> the STARTTLS stuff for Squirrelmail because Squirrelmail can't).
>
> Outlook 2003 uses LOGIN for authentication, and won't do STARTTLS
> on a pop3
> connection (which is where you connect in clear and negotiate
> encryption, as
> opposed to connecting to pop3s which is encrypted from the start).
>
> The Outlook clients are configured to require authentication for
> SMTP using
> the same settings as POP, and to require encryption on both POP and SMTP,
> with ports 587 for SMTP and 995 for POP.
>
> The first time someone collects email with Outlook, they get a
> warning that
> the certificate isn't trusted, but also the option to install it. Half a
> dozen clicks later the certificate is in place.
>

That is only for Outlook 2003, and that Outlook only comes with
MS Office.  Your making several assumptions here - first that it's
an environment with all Outlook (not Outlook Express) and second
it's all current Outlook.

With Windows Product Activation the bad old days of a corporation
buying a single copy of Microsoft Office and loading it on 50
or so machines are long gone.  Why do you think that there's a giant
fight now over the OpenXML standard?  Corporations are done with
standardizing on a -version- of MS Office, as they now know that
they are going to have mixed networks with different versions of
MS Office on them since they cannot pirate software anymore.  They
now want to standardize on a document format, so they don't get
pushed into updating -everyone- on the network when a new verison
of Office comes out.

For older Outlook versions, you can't just do 6 clicks and install
it.  And, are you aware that MS has dumped Outlook Express entirely
with Windows Vista and IE 7?  One more wrinkle for the sites that
are not all MS Office on every desktop.

And to top all of this off, just wait till you run Vista.  IE 7
and Vista give the user almost a dozen Dire Warning Signs This
Computer Will Be Cracked when attempting to install a self-signed
cert and the final ignomity is the stupid wizard defaults to the
personal store not the root store so the CA is not usable by
Outlook if they use the default.  Just get on the MS-specific
board and read all the screaming and bitching among Windows
admins about Vista and self-signed certs.

> Granted, if you have clients using older versions of Outlook or dozens of
> different email clients, you may have issues finding working
> combinations of
> TLS/STARTTLS/port numbers and authentication methods,

Bingo!

> but by and
> large it's
> just putting a few slightly scary-sounding pieces together on the
> server -
> all of which are either in the base system (sendmail: most of the
> objections
> to sendmail haven't had any basis in reality for several years.

I agree wholeheartedly, I use sendmail for all my mailservers anyway.

> It's now as
> easy to configure as Postfix, IMHO, and hooking Mimedefang in as a milter
> gives you the ability to reject a lot of junk during the
> connection rather
> than after the fact) or easily added from ports.
>

greylist milter is also a good one to have.

Seriously, it is just a bit more complicated that your making it
seem.  And, when the OP gets around to asking SPECIFIC questions
about these packages then I'll be quite ready to post the options
I use to turn them on and so on, as I'm sure you will.

But I'm not going to post a recipie when the OP is not willing
to interact on the list and is just reading via digest.  Screw
that.  He's (hopefully) read all of this, once I see him making
some effort on his part, great!  So far though I haven't seen
that.

Ted