RE: questions on setting up a mail server
-Original Message- From: Jonathan McKeown [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 5:12 AM To: Ted Mittelstaedt Cc: freebsd-questions@freebsd.org Subject: Re: questions on setting up a mail server 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. That sounds like a line from a MS sales rep. It really isn't true and I'll explain why in a moment. 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. I don't know what licensing your running but I can tell you that MS has a program called Open Charity - if your donor funded, you very likely qualify for this, and are on it. The costs for licensing on that program are -unbelievably- cheap. It completely changes the capital cost/support cost equation that yes, indeed, it almost always makes sense to upgrade across the board under that program. For most for-profit corporations it is -very- expensive to upgrade across the board. It also causes costs to spike in some years - most corporations hate that. Most corporations when faced with a choice of spending $50K a year, every year, from now until doomsday, or a choice of spending $100K every 3 years, from now until doomsday, they will take the $50K a year, even though over the long run it costs them more. The reason is due to cash flow. This is also why corporations will buy a photocopier for $10K, and immediately stick it on a 5 year lease that will cost them $3K a year in interest and principal. Yes I know it is stupid and it used to drive me banannas when I worked as an accouting clerk a couple decades ago, but it is how businesses (at least in the US) do business. Anyway, because of this most large corps follow a staggered upgrade plan. Every 4 years a quarter of their employees get brand new computers and a quarter of the computers they have in production get scrapped. Or, every 3 years a third get new stuff. Or every 5 years a 5th get new stuff. Whatever they decide to budget for. This is why Microsoft has twice extended the End Of Life software support deadline for Windows XP. Corporations are nowadays treating their computing purchases the same way they treat other capital expenditures, by staggering the costs over time. The days of across the board software upgrades are over and done with, except for government contracts where most governments are still clueless. 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. I've never enabled just PLAIN without enabling LOGIN since it is rather pointless to only enable one
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. 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. 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. 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'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. 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). I've configured sendmail and cyrus to use SASL, offering LOGIN and PLAIN, and to use TLS. 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. 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, 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. 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. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: questions on setting up a mail server
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jonathan McKeown Sent: Wednesday, September 05, 2007 1:13 AM To: freebsd-questions@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
Re: questions on setting up a mail server
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). Thanks, that's almost all of what I needed there. You insinuated (but I don't think explicitly stated) that LOGIN is in fact encrypted in some form? Thanks, -Jim Stapleton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on setting up a mail server
On Wednesday 05 September 2007 12:46, Jim Stapleton wrote: 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). Thanks, that's almost all of what I needed there. You insinuated (but I don't think explicitly stated) that LOGIN is in fact encrypted in some form? No, it's just obfuscated. Both PLAIN and LOGIN send the username and password base64-encoded, which doesn't provide any security - it just protects the mailserver from funny characters in passwords. The only difference between PLAIN and LOGIN is that PLAIN combines the username and password into a single string and sends that, whereas LOGIN waits for a prompt, sends the username, waits for another prompt and sends the password. If you enable the option to prevent plaintext methods except under a security layer, both methods will be disabled. If you do decide to use cyrus, there's a useful tool called imtest which connects to the server, negotiates a TLS connection and lets you type IMAP commands at it. You can see the actual exchange of authentication details, and you can use openssl base64 -d to decode the base64 string to see what's sent (man enc for details). You can also test a secured connection using openssl s_client, which has an option for doing STARTTLS against smtp and pop3 servers (man s_client for details). Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on setting up a mail server
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
Re: questions on setting up a mail server
On Sep 5, 2007, at 5:46 AMSep 5, 2007, Jim Stapleton wrote: 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). Thanks, that's almost all of what I needed there. You insinuated (but I don't think explicitly stated) that LOGIN is in fact encrypted in some form? Thanks, Only across SSL/TLS connections. - Eric F Crist Secure Computing Networks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: questions on setting up a mail server
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Stapleton Sent: Saturday, September 01, 2007 1:36 PM To: freebsd-questions@freebsd.org Subject: questions on setting up a mail server 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. 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. You cannot really find recipies out there to do it - but you can pick up bits and pieces here and there and learn a lot about SSL and assemble a recipie. Basically, you want to create a self-signed root certificate, then sign your POP3 mailserver certificate with that, and put the self-signed cert into the root store in Windows. Not only can you sign your pop3 certs with this, you can sign your www, imap, pop3, smtp, etc. etc. etc. certificates with your root CA and then you won't get bitching from your windows clients. The first group is a different story. If you want to get Outlook to work with that, you can only use NTLM. The developers of all of the various packages dislike NTLM so they force you to use arcane makefile options and such to build your system so that it will support NTLM. Eudora, by contrast, supports only APOP and Netscape mail only supports CRAM-MD5 and as I recall bugs in the clients basically make it impossible for a server that supports all these encryption types to work with all clients. 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 would definitely not bother in a corporate environment where you have maybe a handful of road warriors that would be on sniffable networks - just make sure their pop3 login and password isn't the same as their network login ID and password and the worst a cracker can do is steal their mail. whop de do. Chances are far more likely their laptops will be busted into by a robot loaded on the laptop that sniffs keystrokes. By contrast in a creaky old college network with a bunch of dumb network hubs and a couple dormotories full of jerkoffs looking to prove they are hackers, you probably would want to encrypt it via SSL. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
