Scott Haneda wrote, at 04/30/2009 10:31 PM:> > On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote: >> >> Since one of the purposes of the submission port is to support road >> warriors, I feel it should be as secure as possible and the entire >> communication should be encrypted. > > I am in a bad spot in this regard, because of some of the faults of my > current email server. It is pushed a bit to move users to 587, but the > server does not support SSL/TLS. It would be very hard for me to get > them to all change their settings to use SSL/TLS. I would love to make > 587 the default secure port, I just do not thing I can put my users in > that situation. > > If postfix can log in a way that I can tell what is going on, and over > time, I can make a call a day, and convert people over to TLS, > eventually I will flip this switch.
You can alter the name syslog uses for the submission service by adding: -o syslog_name=postfix-submission I recommend setting up port 587 correctly and securely from the start and migrating users gradually. Since they are already changing configuration settings, have them switch to TLS at the same time, so it doesn't have to be dealt with later. The new log name will aid in troubleshooting. You'll be able to tell who is still authenticating on port 25 because it will be logged under a different name. Just grep for sasl_username in your logs. >> In some cases, I allow the use of a secure mechanism without TLS on port >> 25. This protects the login, but not the message contents. I don't allow >> unencrypted plaintext logins. > > I am leaning back on this idea again. Have to hash that out from the > standpoint of a proxy. I am just do not know if I gain anything by > putting all user MUA traffic on a non port 25 port. I know the proxy > tries to learn from users sending emails, and white list the recipients, > I do not know if that learning is port bound or not. Well, that's another potential advantage of using port 587: you can spare authenticated users (and your system) from filter/proxy scans. Note that some environments still want to scan outgoing mail. Once again, the fact that you're using an alternate port allows you to customize settings to suit the purpose, so it can be another win. >> It's up to you. I use SMTP AUTH for webmail, partly because it provides >> better logging for troubleshooting. > > Good point. What webmail are you using? Does it globally SMTP AUTH via > a config file and a smtp account, or is each user login it's own SMTP > AUTH case, which is where you are picking up the logging data specific > to the sender under that specific account? I use SquirrelMail, which uses individual login credentials for both IMAP access and SMTP AUTH. It's nice to have the user information in the logs. In fact, if you are using Roundcube, make sure it's fully patched. There is a vulnerability that is still being probed for daily against likely locations for it on web servers. >> Default autoconfiguration appears to use ports 25, 465, & 587 and SSL if >> detected. The server I tested supports all of these and the mechanism >> list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple >> Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message. > > Are there are good reasons to support PLAIN and LOGIN and PASSWORD? I > have told all our users to use MD5 Challenge Response. Maybe I would > aid Apple Mail in figuring out which to pick, it seems to always fall > back on PASSWORD iirc. Perhaps other desktop clients do not support md5 > mechanisms. PLAIN & LOGIN are almost universally supported, and are safe to use over an encrypted channel. If you force encryption for plaintext logins, you get peace of mind and your users get more flexibility when configuring clients (which I've found to be a big win as they point and click randomly). I've also had to support some "enterprise" applications that have severely limited SMTP capabilities, so this extra flexibility comes in handy. > A friend of mine signed up for some cheapo hosting account, and they had > a apple script to set it up. It did not work, but I have been meaning > to swipe it and fix it. It looks very simple to deal with, and you can > shove the users login name in, so all they do is run it, connect to get > email, enter in their password, and click "remember" and they are done. > > I would bet I can alter the default port in this script as well. That's one option, but you might be better off going with the autoconfiguration and providing instructions where that fails. Asking users to run scripts is sending the wrong message, IMHO. It just makes them more vulnerable to phishing and other exploits that rely on bad practice. >> You'll have to refer to your SASL implementation to see what mechanisms >> you can support. There can be some additional overhead with the secure >> mechanisms, but it's nice to have the flexibility. Also, some MUAs >> behaved unpredictably when certain mechanisms were absent as >> autoconfiguration was being developed. This is less of an issue, now. To >> be honest, PLAIN w/STARTTLS is usually adequate, and is universally >> supported in MUAs. > > Ok, but to be clear, on a AUTH only, no crypto account, you would not > want to use PLAIN, but something like md5? Correct, or kerberos, if you support it. > Curious, why is NTLM an option I see often, I am yet to see a MUA client > support it, other than showing it. I can never get it to work. What are > the real pros and cons of each of the 7 or so AUTH mechanisms? You'll have to research that yourself. Some of them are becoming weaker, others are proprietary. Personally, I like kerberos, but it's difficult to train users and there is no convenient way to support multiple accounts in different realms (that alone can be a show stopper). > When it comes to a TLS or even an SSL connection, I take it at that > point, the AUTH mechanism you chose really makes no difference? Is > there a performance hit, where it would be more ideal to use a less > complex mechanism since you are TLS'ing the entire channel anyway? Absolutely. Enforced TLS with PLAIN/LOGIN is often the best all-around solution (total message encryption, low overhead authentication mechanism). In that case, you can target TLS if you need to throw more resources at it (increase entropy for the PRNG, hardware encryption, etc.).
