Scott Haneda wrote, at 05/01/2009 08:37 PM: > On May 1, 2009, at 7:19 AM, Jorey Bump wrote: >> >> The difference is that MTAs typically don't quit if they can't verify >> the cert (check it against a root certificate store), so using a >> self-signed cert is adequate. >> >>>> # client TLS parameters, forward mail via TLS if possible >>>> smtp_tls_security_level = may >>> >>> I had this one already I believe. >> >> This is what you need for your server to connect *as a client* to other >> MTAs, opportunistically using STARTTLS when offered. > > In a previous sentence you used the word 'typically' in regards to if > the MTA will quit or not on seeing a cert. What is the risk here?
Most connecting MTAs will still encrypt the communication if they cannot *verify* the certificate, so there is little risk of sniffing on the wire. Some policies will require verification, but that usually implies a special relationship. > If I > understand, this gives an opportunistic ability for MTA to MTA > discussion to be secure, falling back on the old plain method if it is > not available. Correct. > Is there really a lot of exploiting going on in-between one MTA and > another? From what I can tell, this would boil down to a rogue person > at some router between me and say, gmails servers, that wanted to > intercept traffic. Just does not seem likely. Which is why most MX hosts and relays use encryption opportunistically instead of enforcing it. Perhaps the days are numbered even for this innocent approach... >>> smtpd_sasl_security_options = noanonymous >> >> Change to noanonymous, noplaintext if you don't want passwords sent in >> the clear. > > If I set this to noanonymous, noplaintext to confirm, if any of my > current users are using an authenticated plain text login method, they > would fail to login? In many cases, yes, because plaintext mechanisms won't even be offered unless the channel is encrypted. However, some clients might automatically use the remaining secure mechanisms that are still offered. > This then gets my phone ringing, where I can help them make the changes > to either use a non plain text login method, with auth, or use a plain > style login with crypto. I think I have that correct. Yes. >>> submission inet n - n - >>> - smtpd >>> -o smtpd_tls_security_level=may >>> -o smtpd_tls_auth_only=no >>> -o smtpd_sasl_auth_enable=yes >>> -o smtpd_client_restrictions=permit_sasl_authenticated >> >> IMHO, too weak for port 587. > > Can we explore your HO on this. I have helped many a friend set up > email for any number of the 9.99 a month ISP's out there, the are all > offering normal 25, some alt submission port, and some SSL port as > well. I am yet to see any particular mandate that the submission port > be crypto mandated. Not that I want to just follow the examples set by > others, as often is the case, they are "doing it wrong" anyway. > > I am just not seeing why a user can not auth with no crypto. Or, are > you taking the stance that users really do not know about this stuff, > and it would be best if you protect their actions on their behalf? No, I'm more interested in protecting the integrity of the submission service on port 587, and prefer to see it locked down as tightly as possible. The main reason is to prevent a breakdown in security that could lead ISPs to block port 587 as many have done with port 25. I've seen misguided configurations that duplicate port 25 settings on port 587, making the port a fully functioning MX that can be abused by spammers. Another reason is that some hotels and internet cafes arrogantly try to proxy email connections, and that's a lot more threatening than unencrypted MTA to MTA communication. TLS helps mitigate this, as it is really hard to proxy encrypted connections without generating a warning (unless they trick you into installing a root certificate in your client). > I certainly can appreciate that. Having to deal with hundreds of iPhone > users, and desktop users, when I toggle this switch may prove less than > fun. Since my old server does not support SSL/TLS, it is not like I can > send an email out, tell them to switch, and then mass move everyone to > postfix. This is going to be a throw the switch, and start answering > phone calls. > > I do really like the idea of all users being secure. Perhaps I will set > up a new MX, run the old and the new at the same time, and migrate one > domain at a time, that would remove the "throw the switch" support burden. > > Not really liking the idea of using a new domain for setting up the > postifx server. I am pretty sure I can not do this in the same domain, > as the second I add in a MX pointing to the new postfix server, that is > going to break everything. You have your work cut out for you. > What specifically about smtps was it that you ended up determining you > needed it? I needed to support legacy clients. I don't enable it on new servers, though, unless there's a demonstrated need.
