questions on setting up a mail server

[Jonathan McKeown]

I've edited ruthlessly to reduce the length of this message.

On Wednesday 05 September 2007 11:07, you wrote:

> > > > 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:
[list of SASL methods plus question what to use]
> > >
> > > 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.

I wasn't trying to be stupid: I saw a single list of SASL authc methods and 
wasn't sure where you had drawn the line to divide them into two groups.

[...certificates]
> > > 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.

Yes, it is: but with Windows 2000/XP and Outlook 2003, it's not magic. In fact 
I was pleasantly surprised how easy it was.

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

I'll bow to your experience on that. All I can say is that my own view is that 
the bigger the network, the more important it is to get software standardised 
across the organisation to reduce your support costs, and the cheaper it is 
to do through volume licensing. We're a small, donor-funded, African NGO, and 
we have two versions of Windows (2000 and XP) and one version of Office 
(2003). We will use Microsoft's down-licensing provision to stick with what 
we have until we're ready to upgrade everyone.

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

No, Outlook 2003 doesn't support PLAIN - at least I couldn't get it to. That's 
why I enabled LOGIN. It's true that NTLM is the only encrypted password 
protocol supported by Microsoft - that's why I'm using an encryption layer 
with cleartext authentication.

> > > 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 [end to end]

> It is only useful for protecting passwords from wire sniffing.

True up to a point. It can also offer integrity - an assurance that the 
message is from the authenticated identity. Although that assurance is only 
valid at the first server (the MSA), that may be enough to prevent injection 
of a variety of kinds of junk with forged sender information.

> But in most cases, the wire isn't sniffable.

Given that, certainly in my case, the ``wire'' may be cellular, radio, 
satellite, wireless LAN, or a government, academic or hotel/airport network 
providing temporary connectivity, I can't say that with confidence.

> password sniffing only becomes a concern when you have road
> warriors who are NOT connecting into the mailserver via a VPN

Again true - but now you're talking about another method of protecting 
passwords, and another technology to master. In practice, even though I run a 
VPN as well, I still use TLS at the individual service level to protect 
passwords ``in flight''.

> 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 would dispute that this is idiotic. You do need to protect the password much 
more carefully, but there are advantages to having a single password, easily 
changed by the user and easily cancelled when the user leaves.

[certificate authority not hard]
>
> I didn't say doing that was hard.  The problem is that the entire SSL
> picture is hard for a newbie.
[...]
> It's only after digging for a long while will they come across
> some pointers that will shed the light.

That's certainly true. The longest part of the design, implementation and 
rollout of our new mail system was finding all the bits and pieces and 
working out how to put them together.

[of SASL authc methods]
> > 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.

No. There are small differences but they are there. PLAIN sends a single 
string containing the authorization identity, authentication identity, and 
password. LOGIN expects a prompt to which it replies with the authc identity, 
then a second prompt to which it replies with the password. The protocol 
specifies that the content of the two prompts is irrelevant, but Outlook 
expects specific strings.

[long discussion of config details]
> > 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.

Again, I wouldn't run a network like that because of the support problems it 
causes - this being one example. You can buy one copy of Microsoft Office and 
a volume licence, and Microsoft will allow you to downlicense so that you can 
standardise on an earlier version until you are ready to upgrade. This 
approach to licensing is one thing they get right, IMO.

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

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

Yes, but in a business environment, almost the first problem you need to solve 
is controlling which clients are going to connect to the mail server. If you 
haven't managed to standardise on one or two clients across a large 
organisation, you're probably too busy doing support to worry about setting 
up a new email system.

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

I haven't tried putting any obstacles in the way of incoming mail over and 
above the difficulties many mail admins cause themselves. You would be 
astonished at what I see coming over the transom on my mailservers, 
especially the Mailman box (we host a number of lists). As it is, we take a 
few steps that end up rejecting over 80% of our incoming connections.

> Seriously, it is just a bit more complicated that your making it
> seem.

Yes and no. It's a big deal trying to get your head round all the different 
packages, all the various options, and all the conflicting advice; but having 
done it once, I'm confident I could do it again quickly and simply and that 
(if I had world enough, and time) I could talk someone else through the 
process, not only of doing it, but of understanding it.

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

Yes.

Jonathan