2009/4/25 Scott Haneda <talkli...@newgeo.com>: > I have a little affliction against man type pages, they never seem to make a > lot of sense to me :) This section does though. Just to be clear, this is > a full blown over-ride, in that deleting the corresponding value from > main.cf would do nothing to the server, so long as it exists in master.cf?
Not quite. It's an override for when you want to change the settings for a particular daemon. Overrides in master.cf don't "propagate" out to the rest of the config though. If you want a setting, put it in main.cf. If a particular process needs an override, *then* it goes in master.cf. A relevant example: For spam-filtering most people fill out smtpd_recipient_restrictions. smtpd_recipient_restrictions will be used for any smtpd process, which in master.cf is the lines like this: smtp inet n - - - - smtpd submission inet n - - - - smtpd smtps inet n - - - - smtpd A lot of the time you'd like a different set of smtpd_recipient_restrictions for the submission port. *That's* when you override it; you DO NOT delete the smtpd_recipient_restrictions from main.cf! Otherwise you'll get the default restrictions for your smtp and smtps ports. > If you do not like a lack of TLS enforcement on the submission port what do > you suggest for users who just do not care enough to use any TLS? You let > them work on port 25? I could go that route, but I am really trying to find > a way to do traffic isolation. If I know no client connections are made on > 25, from a troubleshooting perspective alone, it seems to make things > simpler on me. > > My mailserver has a setting where I can disable auth on port 25. Maybe I > will do this pre-migration, which would allow me to force all my users to > change to port 25. The hobbly little server I am using now does not offer > any way for me to look and see what users are connecting on 25 still. I > think most are on 587 as a result of most ISP's filtering 25. There's a few distinct concepts here: SSL and TLS. While it's not entirely accurate, it's easiest to think of it in this way: SSL is an encrypted pipe that goes around the smtp session. SSL is negotiated before SMTP starts and is transparent to the MTA at each end. This is why you can use tools like stunnel to setup transparent security for HTTP, SMTP, etc. TLS is negotiated in-band, at least for SMTP. The session starts in plaintext, the server offers STARTTLS in its reply to EHLO, the client can choose to initiate negotiation by sending "STARTTLS", then the crypto kicks in and the session is protected. Each side then keeps talking SMTP as usual. http://en.wikipedia.org/wiki/STARTTLS Port 25 == regular SMTP, this must always be enabled if you want to receive mail from the internet Port 465 == de-facto port for running SSL-mode SMTP Port 587 == usual port for running "TLS" SMTP - this is exactly the same as port 25 however! You can talk plain SMTP to port 587 if you want, try it in a telnet session. Because port 25 and port 587 are configured separately in master.cf, you can have different settings. You can't enforce crypto on port 25, but you can do that on port 587 if you want. You can enforce the requirement to perform auth on port 587 if you want. Auth and crypto: these are separate things. MTAs can use opportunistic encryption across the internet even if they don't know each other; this is confidentiality without authentication. Given that regular mail transit is already unauthenticated, this can only be a net gain. Authentication is what you want your users to do before they can relay mail. In the context of SMTP it just means they prove their username and password to you, one way or another. Obviously it's bad if customers send their username and password in the clear, which is why you can tackle this in a couple of ways. 1. Require them to use a "secure" authentication protocol - this does *not* necessarily imply crypto, which is where a lot of confusion stems from. If you send me your password in plaintext, that's "insecure". If we perform a challenge-response session, you send me a hash that allows me to verify your password, but your password was not transmitted, so attackers can't steal it - that's "secure". Due to various reasons relating to secure storage of passwords, using an insecure auth protocol means I don't have to store a plaintext copy of your password on the server; that's a Good Thing. A "secure" auth protocol like CRAM-MD5 requires the server to have a plaintext or effectively-plaintext copy of your password, and that's not as nice. Note that even if I use a secure auth protocol, the rest of the mail session is unprotected and can be read by an attacker sniffing the wire. 2. The alternative is to wrap everything in a crypto pipe - this is SSL or TLS. Once the whole session is encrypted we don't care how authentication happens, as confidentiality is provided externally. It's obvious that there's a 2x2 matrix of auth+crypto options here. If you're trying to be very flexible then you're probably interested in stopping the one possibility that could leak passwords - no-crypto while using insecure auth. > Glad you brought up webmail. I am going to use Roundcube, on the same > machine, worst case, on a close machine, in the same subnet. Since I have > the nynetworks setting set to allow mail, all should be ok? I do not want > to deal with AUTH for SMTP in webmail, it is going to be local to local, I > see no point in securing that part. Is that correct? This really depends how the webmail software implements the SMTP client side; I've not touched Roundcube so I can't say. If you're working on a trusted network then you don't need crypto and it's safe to let mail through by virtue of permit_mynetworks. It might still be beneficial to have authentication happening though. Depending on how Roundcube sends the mail, you may or may not have much of a paper-trail if you need to track down a rogue user with a compromised account (eg. if mail were submitted using the "sendmail" method, and users have someway of hiding their details, you might only see maillog entries from the "apache" user, and no way of knowing which webmail account is compromised). >>> In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse, >>> Kerberos, and Password. In Thunderbird I notices there are no such >>> options. Which are used in Thunderbird? What is the best to use, or is >>> it only applicable if you are choosing to not use SSL/TLS? >> >> Thunderbird has a "Use secure authentication" checkbox that supports >> multiple mechanisms (independent of SSL/TLS). Unfortunately, *it* >> decides which one to use, which I find very frustrating. > > I am glad you brought up "Use secure authentication", what exactly does this > setting do? In Thunderbird, there is none, optional TLS, and SSL, and then > this "use secure auth" setting. That is a lot of control, and totally > unclear on what setting in postfix that secure auth checkbox is going to run > up against. > > Apple Mail does not even have such a setting, so I assume it is one of the > encryption modes that kicks it in? This is that crypto vs. auth thing again, hopefully it's a bit clearer now. I've not used mac mail myself, but my understanding is that it uses a bit of voodoo and works out the best parameters it can (ie. it just tries STARTTLS if offered by the server). Don't quote me on that though. As for auth options, "password" is the plaintext one that's okay to use on an unencrypted session. >> I'm happy for >> mail clients to select the best mechanisms available for easy >> autoconfiguration, but it would be nice to have the ability to set them >> explicitly (for troubleshooting or security reasons). >> >> In any case, it's good practice to check this box if the server supports >> secure mechanisms, for a little extra protection beyond SSL/TLS. > > What more do I need to do in postfix cf files to support this setting? Any > downsides as far as performance and load? This depends on what you want your security policy to be. One useful main.cf option is smtpd_tls_auth_only - when TLS is optional, it'll only offer authentication if the connection is encrypted. (obviously it's always safe to offer authentication if encryption is mandatory). The catch is that authentication isn't strictly handled by postfix. Your SASL backend (cyrus or dovecot) specifies what authentication protocols are offered; I believe this is because it's the SASL daemon that has to deal with the password backend, so it's the right place for that sort of policy. You can't offer CRAM-MD5 if the passwords are stored in a hashed form; postfix has no knowledge of the password storage, so authentication can't be handled in postfix (though sasl can be tweaked a little). >>> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem >>> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem >> >> If you're not using client certificate authentication (and you probably >> aren't), delete those lines. > > Well now you threw me for a loop :) I am a small ISP, and I will buy a > emailserver.company.example.com SSL cert. As it is now, in email clients, I > get a box pop up asking me to approve my current self signed one as a non > known untrusted authority. I just select accept always and move on. > > So removing those certs above just removes the certificate trust issue, but > does not change any of the encryption methods I have going on? In apache, I > can not enable SSL, as far as I know, without a cert. I was under the > impression, if I want to offer SSL, I am going to need those certs? Correct, a paid-for cert will sidestep the trust issue for your users. It's the same here as it is in apache. Crypto certs are just "dumb data" - it's primarily key material, it doesn't affect how your crypto works, or how strong it is, etc. I think you misinterpreted that comment though. "If you're not using client certificate authentication, delete those lines". What was meant was, "if postfix isn't using certificates to authenticate ITSELF to other servers, delete these lines". Postfix can talk to other MTAs with crypto as well, this is the `smtp_tls_security_level` setting - notice the "smtp_" prefix on the config options, it's not "smtpd_". The thing is, you can do crypto with or without certs. A cert is just a combination of (optionally) signed identify data tied to key material. If you don't care about identities (and for MTA-to-MTA traffic on the public internet, we don't), you can negotiate an anonymous TLS session and everything works as you expect it should. By setting smtp_tls_cert_file (I think) you're telling postfix to negotiate a non-anonymous TLS session, which the other end may baulk on if it doesn't have a cert, or can't verify your cert's signer, or for any number of reasons. >From the docs: http://www.postfix.org/postconf.5.html#smtp_tls_cert_file "Do not configure client certificates unless you *must* present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them. The recommended setting is to let the defaults stand" (all empty) >>> smtpd_recipient_restrictions = permit_mynetworks >>> permit_sasl_authenticated reject_unauth_destination permit >> >> You can remove permit_sasl_authenticated from here if you don't want to >> offer authenticated submission on port 25... > > In my context of using Dovecot, and not using the cyrus sasl thingy, where I > see mention of _sasl_ in a config line, that is in reference to both SSL and > TLS? Of course I can see no reason not to offer authentication on port 25, so long as the passwords are safe, for reasons described above. As we've already established, SASL is completely separate from SSL/TLS. >>> smtpd_sasl_authenticated_header = yes >>> smtpd_sasl_exceptions_networks = $mynetworks >>> smtpd_sasl_local_domain = $myhostname >>> smtpd_sasl_path = private/auth >>> smtpd_sasl_security_options = noanonymous >>> smtpd_sasl_type = dovecot >> >> I'd probably leave these in main.cf, just to keep master.cf simple, but >> it's your choice. Also, you can probably drop >> smtpd_sasl_exceptions_networks, as it won't make sense if you disable >> SMTP AUTH on port 25 and require authentication on port 587. I agree with this suggestion. You can keep sane settings in main.cf, it's nicer to leave master.cf alone. You also *probably* don't need to define smtpd_sasl_exceptions_networks. An example from my config, if it helps. # we can allow relaying by forcing senders to authenticate first (by permit_sasl_authenticated in smtpd_recipient_restrictions) smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous <-- this is the default, BTW smtpd_tls_security_level = may <-- offer but don't require TLS broken_sasl_auth_clients = yes # server TLS parameters smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt smtpd_tls_auth_only = yes <-- as mentioned, user can only auth on a secure connection smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes # client TLS parameters, forward mail via TLS if possible smtp_tls_security_level = may These parameters will apply to all smtpd processes (smtp,smtps,submission) in master.cf unless you override the specific settings there. You may choose to enforce crypto on port 587 with "-o smtpd_tls_security_level=encrypt" but it's not technically necessary. You'll usually add "-o smtpd_tls_wrappermode=yes" to the smtps definition to get "SSL" mode working. I've personally got "-o smtpd_client_restrictions=permit_sasl_authenticated,reject" for my submission port.
