Re: Suggestions on submission port config
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.
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/30/2009 10:11 PM: What happens is, under heavy MTA load on port 25, I will run out of connection slots on port 25. Have you investigated the nature of this problem? By moving users to 587, I do not care about port 25 connection slots. MTA's will try again later if busy. You might be chasing a red herring. If your server is overloaded, there is a reason why, and there may be more effective remediation techniques available. Improving your submission service is good, but it might not deliver the performance payoff you're expecting. What do you guys think? My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. If you still have a heavy load, consider separating your MX entirely from submission, using separate instances/machines. It's generally easier to move the MX, since MUA configurations don't care about it. I just do not want to add too much to my learning curve, so first, get postfix to where I understand it, then toggle the ports and put the proxy in. It should blindly pass the traffic, I assume in much the same way stunnel does. I am open to any and all advice on this matter to make this work best. I have a feeling later on down the road I will need to learn exactly what things to disable in postfix, as it should not do any bouncing at all, anything that will lead to backsplatter, since I am putting a proxy ahead of it. FWIW, a poorly implemented proxy can do more harm than good. A lot of sites just toss them in, and don't pay attention to finer details like DNS settings and recipient validation. I am still not entirely clear. The docs: I am still not entirely clear. The docs: 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 That supports your statement. What is confusing, is most of the tutorials for setting up Postfix have a section on setting these up. Trust the Postfix documentation, not random tutorials. Indeed, the ones I set up used a specific host name, and when I smtp, or pop or imap, I am asked to authorize the self signed cert, as at this time I do not have a purchased cert from a CA. That's something else. You get that prompt from the server certificate (smtpd_tls_cert_file), which you need. That is different from the client certificate (smtp_tls_cert_file), which you obviously don't need. What is the correct way to not use certs for MTA's, but to present one to the MUA? # 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 You have the two cert, ahhh, smtp*d*. Ok, I think I get it, that is for MUA traffic, and you present them a cert authorization when they are auth'ing. So I can even use the current certs I have in place now? These are for all client connections that use STARTTLS, not just MUAs. 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. It is increasingly harder to support MUAs with noncommercial certs, however. You can get basic ones fairly cheaply, so I recommend it to avoid annoying warnings to your users. # 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. The wrapper mode is probably a Outlook issue, or at least an older buggy MUA client issue? I do not have any easy access to Outlook. How do you go about testing before deployment? Don't set it up until you have everything else working properly (TLS, submission, etc.). Then wait until you find a need for it. Normally, the Postfix defaults in master.cf will suffice (assuming your distribution hasn't fiddled with them). smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem smtp_tls_key_file= /opt/local/etc/ssl/private/dovecot.pem Remove. smtp_tls_security_level = may Keep. smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache Keep if you need it. smtpd_sasl_security_options = noanonymous Change to noanonymous, noplaintext if you don't want passwords sent in the clear. smtpd_tls_ask_ccert = yes Why? smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem
Re: Suggestions on submission port config
On Fri, May 01, 2009 at 10:19:40AM -0400, Jorey Bump wrote: My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. There is no port 587587, the TCP port range (over both IPv4 and IPv6) is from 0 to 65535, but 0 means unspecified at the socket API level. In any case 587587 is usually equivalent to its residue mod 2^16 which is 63299, not a good port to choose for a service (dynamic port range on most systems). -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Suggestions on submission port config
Victor Duchovni wrote, at 05/01/2009 10:26 AM: On Fri, May 01, 2009 at 10:19:40AM -0400, Jorey Bump wrote: FTR: No, I didn't! :) My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. There is no port 587587, the TCP port range (over both IPv4 and IPv6) is from 0 to 65535, but 0 means unspecified at the socket API level. In any case 587587 is usually equivalent to its residue mod 2^16 which is 63299, not a good port to choose for a service (dynamic port range on most systems).
Re: Suggestions on submission port config
On May 1, 2009, at 7:19 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/30/2009 10:11 PM: What happens is, under heavy MTA load on port 25, I will run out of connection slots on port 25. Have you investigated the nature of this problem? Thoroughly. My current email server lacks control, it is only recently we have even been given greylisting. Moving users to port 587 largely solved it, but issues still remain. It is just time for me to move on. I am at the whim of the developer, this is not a config file driven email server. Even mention of SPF on his mail list get you told to not talk about it. It is not an option, and while I personally do not intend to use SPF, I want options, which postfix has abound. To be honest, I have received more education and support from you and a few other people on this list in a few days than the 10 years of using something else. I do thank you all again, as well as those who make postfix what it is. By moving users to 587, I do not care about port 25 connection slots. MTA's will try again later if busy. You might be chasing a red herring. If your server is overloaded, there is a reason why, and there may be more effective remediation techniques available. Improving your submission service is good, but it might not deliver the performance payoff you're expecting. You nailed it, there are indeed many more techniques for dealing with my issues. Manually scanning logs and putting IP ranges into a local DNS blacklist and manually creating rules that are not flexible in how they can match patterns is what hinders me for the most part. What do you guys think? My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. If you still have a heavy load, consider separating your MX entirely from submission, using separate instances/machines. It's generally easier to move the MX, since MUA configurations don't care about it. I have this as a option from the beginning of setup. I was given a large enough IP allocation that I tend to give up an IP for each service, and create DNS records pointing to each IP. If I ever need to for example, most SMTP 587 to it's own machine, it is as simple as just setting up the software, remove the old IP from the old machine, and putting it into the new machine. I use will use this when I migrate as well, not having to fiddle with DNS TTL's and some other ISP's that seem to cache DNS and not honor TTL's then becomes a non issue. I just do not want to add too much to my learning curve, so first, get postfix to where I understand it, then toggle the ports and put the proxy in. It should blindly pass the traffic, I assume in much the same way stunnel does. I am open to any and all advice on this matter to make this work best. I have a feeling later on down the road I will need to learn exactly what things to disable in postfix, as it should not do any bouncing at all, anything that will lead to backsplatter, since I am putting a proxy ahead of it. FWIW, a poorly implemented proxy can do more harm than good. A lot of sites just toss them in, and don't pay attention to finer details like DNS settings and recipient validation. I have spent the past few years looking at them and reading about them. Starting with the hardware driven devices like Barracuda. My main reason for not deploying as of yet was the only way to get user validation on my server was LDAP, which I could not ever get to work reliably. Maintaining a text file of users was an option, but at minutes to dump a list of users via AppleScript from the email server, I did not like that option. I am settling in on ASSP, which seems to solve my needs, and provide everything I need. If it turns out I do not like it, the nice thing about a proxy is, you just turn it off, a quick change of port listeners in postfix, and I should be back up and running. # 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 You have the two cert, ahhh, smtp*d*. Ok, I think I get it, that is for MUA traffic, and you present them a cert authorization when they are auth'ing. So I can even use the current certs I have in place now? These are for all client connections that use STARTTLS, not just MUAs. 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. It is increasingly harder to support MUAs with noncommercial certs, however. You can get basic ones fairly cheaply, so I recommend it to avoid annoying
Re: Suggestions on submission port config
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.
Re: Suggestions on submission port config
Barney, ( and Jorey ), thanks so much for your help in understanding this, moving to postfix is something I have needed to do for some time, glad to finally get down to it. I had to step away for a few days and get some other work done, but made some good progress last night. I have some more clarifications thought if you do not mind. On Apr 24, 2009, at 9:35 PM, Barney Desmond wrote: 2009/4/25 Scott Haneda talkli...@newgeo.com: If you do not like a lack of TLS enforcement on the submission port what do [snip... on SSL/TLS methods] think most are on 587 as a result of most ISP's filtering 25. There's a few distinct concepts here: [snip... Explanation of SSL/TLS] I am hesitant to detract and add more to this, but here goes. My current email server does not support SSL/TLS. I have 250-AUTH CRAM- MD5 DIGEST-MD5 NTLM PLAIN LOGIN ( Does the order of my methods matter? ) I do have some auth methods in regards to the user/pass, but from what I understand, the data is always in the clear. My current setup is *mostly* MTA to MTA on port 25, there are a handful of users whose ISP's have not filtered 25, so those users are still on port 25. I can force auth on 25, but with no way of testing that before toggling the setting, I am not anxious to do so. tcpdump would be the only way, and a little too much of a pain to deal with. The reason I want to force all users to 587, and allow auth and crypto on 587, and not mandate crypto exclusive, is that is how 99% of my users are set now, 587 using md5-challenge response. This has been done at suggestion of the developer of my current server. What happens is, under heavy MTA load on port 25, I will run out of connection slots on port 25. By moving users to 587, I do not care about port 25 connection slots. MTA's will try again later if busy. What I do not want, is MUA users getting a server busy response on port 25 just because mail volume is high that day. The general suggested idea from the developer of my mail server is to move all users to port 587, and only have MTA mail on port 25. Hopefully this issue of running out of connections is not much an issue in postfix. I also have a setting of limit x connections from same host. If I have an office of users, logging in over a LAN, where their public IP is a fixed IP, and they all have private IP's, my current mail server sees them all as many connections from the same IP, and they get too many simultaneous connections errors. ( How does postfix deal with this? ) Because of this, I can not limit connections from same host on port 25 to a reasonable number to slow dictionary attacks and the like, as the office of 100 employees is going to hit a wall really soon. By moving them to 587, I have more control. Maybe I am just jaded in how my old email server forced me down a path, and I should not worry about this, and allow 25 and 587 to behave identical, with one exception in that 587 would disallow explicitly any non authenticated connections. I think I can force auth and crypto on 587 and not hassle my MUA users one bit; then allow auth no crypto on 25, and also open it to non auth non crypto for MTA chatting. Not sure if that is possible, to allow non auth MTA mail on 25, but also tell MUA clients they must at minimum, auth. What do you guys think? My end goal here is to get this all working, and then change these ports to, for example, 25 - 2525 and 587 - 587587 unless there is some other convention. I am going to put a anti spam proxy in front of all this. I just do not want to add too much to my learning curve, so first, get postfix to where I understand it, then toggle the ports and put the proxy in. It should blindly pass the traffic, I assume in much the same way stunnel does. I am open to any and all advice on this matter to make this work best. I have a feeling later on down the road I will need to learn exactly what things to disable in postfix, as it should not do any bouncing at all, anything that will lead to backsplatter, since I am putting a proxy ahead of it. 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. Correct. I was actually not aware that something like password, md5-* etc was even a legitimate way of protecting yourself. I understand the data channel is plain text, but the user and pass being hashed in some way, I had assumed it would be trivial to crack, something akin to base64. Good to know it is a lot more than that. I'm happy for mail clients to select the
Re: Suggestions on submission port config
Jorey, thanks for your email also. Sorry for the delay, but you and Barney have been hugely instrumental in getting me on track with this. On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:41 PM: Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous 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? I suggest they use it if they want to send mail. :) 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 let them work on port 25? 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. 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? 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 am confused about your comments about 465. Reading it makes me think that 465 is sort of a last resort option. I am not understanding the difference between SSL and TLS. If I was setting up a email client, and could use TLS versus SSL, my logic would be to use SSL, it seems the better option, but I do not know why. Are you saying SSL email is the lesser of the options, and I should use TLS when I can? I'm saying that smtps (wrapper mode on port 465) is deprecated in favor of STARTTLS on ports 25 or 587. Good to know. For some reason, SSL sounds the better way to go in my head, and in the heads of a lot of people I talk to. Strange, because when I think about it, how it sends out a STARTTLS, and moves on from there, that seems a better policy, less prone to problems as well. Do you know how this related to Apple Mail? There is no setting in the SMTP section to opt for SSL versus TLS? Use SSL is the only checkbox there is. I take it if you do not select that, it will use TLS if it can, but do so in a invisible way? 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. I assume it follows an algorithm to determine a fallback strategy for trying the other ports if its first choice is not available. Although I would have preferred it start with port 587, the choice it made is
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). I successfully sent emails through this system as unauthenticated, authenticated, with tls, and with ssl. This is a migration, and I would like to have minimal email client settings needing change. My old server did not have SSL or TLS. Old Server: No SSL, No TLS port 25 = normal inbound, plus smtp auth'd users port 587 = forced auth'd users I am willing to disallow user connection to port 25. How do I do this? In main.cf or master.cf? Right now, I believe I only have this: [snip... master.cf ] smtp inet n - n - - smtpd I believe I need to add a restriction in there to stop clients from connecting? There was a recent thread on this subject, worth reading: http://www.mail-archive.com/postfix-users@postfix.org/msg06230.html For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. I can not seem to get this to work, it is either no encryption, or forced encryption. [snip... master.cf ] submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o milter_macro_daemon_name=ORIGINATING Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous * Do I even need the milter line? Good question. It may depend on whether or not you use milters. I don't, but I leave it in because I don't want issues later if I decide to deploy a milter. Port 465, I believe will be reserved exclusively for SSL? Port 587 does the TLS, is that correct? Or is the SSL just wrapping around the TLS? [snip... master.cf ] 465 inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is for legacy support. I suggest you don't activate it until you're sure you need it. Wrapper mode is different from offering STARTTLS. Nearly all modern clients support STARTTLS. If someone absolutely needs port 465, that could be a red flag that the user needs an upgrade. However, some webmail programs might have poor support for STARTTLS, forcing you to enable smtps if you require an encrypted connection. 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'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. I have been pretty up and down the docs, this is somehow not making a lot of sense. I think once I understand what crosses over in config from main.cf and master.cf, it will make more sense. postconf -n 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. smtp_tls_security_level = may This is good. smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destinationpermit You can remove permit_sasl_authenticated from here if you don't want to offer authenticated submission on port 25... smtpd_sasl_auth_enable = yes ...and change this to no (or remove the line,
Re: Suggestions on submission port config
Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). 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? [snip...] I am willing to disallow user connection to port 25. How do I do this? In main.cf or master.cf? Right now, I believe I only have this: [snip... master.cf ] smtp inet n - n - - smtpd I believe I need to add a restriction in there to stop clients from connecting? There was a recent thread on this subject, worth reading: http://www.mail-archive.com/postfix-users@postfix.org/msg06230.html Nice, thanks again, that was very telling. I will use that as a reference on how to best set this up, I think I still have some general questions below, as a result of my never having dealt with SSL/ TLS other than on ftp servers and SSL in the http space. For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. I can not seem to get this to work, it is either no encryption, or forced encryption. [snip... master.cf ] submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o milter_macro_daemon_name=ORIGINATING Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous 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. Maybe a little tcpdump would get me those numbers. * Do I even need the milter line? Good question. It may depend on whether or not you use milters. I don't, but I leave it in because I don't want issues later if I decide to deploy a milter. Quick research seems to lead me to believe milter is for mail filtering, hence the name. Since I plan to have a proxy sit in front of my system, it should be safe to never use milter at all? I may want to auto file IMAP email to a junk mail folder, but I believe that would be done in dovecot, not postfix. Port 465, I believe will be reserved exclusively for SSL? Port 587 does the TLS, is that correct? Or is the SSL just wrapping around the TLS? [snip... master.cf ] 465 inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING This is for legacy support. I suggest you don't activate it until you're sure you need it. Wrapper mode is different from offering STARTTLS. Nearly all modern clients support STARTTLS. If someone absolutely needs port 465, that could be a red flag that the user needs an upgrade. However, some webmail programs might have poor support for STARTTLS, forcing you to enable smtps if you require an encrypted connection. Glad you brought up webmail. I am going to use Roundcube, on the same machine, worst case, on a close
Re: Suggestions on submission port config
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.
Re: Suggestions on submission port config
Scott Haneda wrote, at 04/24/2009 07:41 PM: Thanks for this, this is getting me on track, comments interspersed below... On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote: Scott Haneda wrote, at 04/24/2009 07:58 AM: I am a little confused about main.cf and master.cf. Is there overlap in some of the settings? Do some settings exist in both files, or at least are interchangable? If this is the case, under what conditions do you decide to do so? From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer to other parameters as $name etc., just like in main.cf. See postconf(5) for syntax. As implied, it's useful when you need to override the settings in main.cf to get different behaviour appropriate to the service you're setting up in master.cf (submission, reinjection from proxy/filter, etc.). 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? Yes. But keep in mind that most settings have a default value. It's healthy to define a base configuration in main.cf, where your needs differ from the defaults, then only apply overrides in master.cf where necessary. For port 587 submission, I want to offer SSL, TLS, and non encrypted to cover the users who will not want to change their settings. Use: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=no I think it's normally a bad idea not to enforce TLS on the submission port, but if you're using a secure mechanism and want to prevent weaker ones, add: -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous 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? I suggest they use it if they want to send mail. :) 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. You let them work on port 25? 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 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. I think it's reasonable. Just give your users advance notice so they can change their settings. 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? It's up to you. I use SMTP AUTH for webmail, partly because it provides better logging for troubleshooting. I am confused about your comments about 465. Reading it makes me think that 465 is sort of a last resort option. I am not understanding the difference between SSL and TLS. If I was setting up a email client, and could use TLS versus SSL, my logic would be to use SSL, it seems the better option, but I do not know why. Are you saying SSL email is the lesser of the options, and I should use TLS when I can? I'm saying that smtps (wrapper mode on port 465) is deprecated in favor of STARTTLS on ports 25 or 587. So the ideal situation is using TLS on a non 25 submission port? Ideally, STARTTLS on the standardized submission port 587. Do you know how this related to Apple Mail? There is no setting in the SMTP section to opt for SSL versus TLS? Use SSL is the only checkbox there is. I take it if you do not select that, it will use TLS if it can, but do so in a invisible way? 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. I assume it follows an algorithm to determine a fallback strategy for trying the other ports if its first choice is not available. Although I would have preferred it start with port 587, the choice it made is acceptably secure. If you only offer port 587, it probably won't pose any problems (as long as it remembers the other ports are unavailable). In any case, you can set the port mechanism explicitly, and it will negotiate TLS/SSL appropriately for either wrapper mode or STARTTLS. It
