Loading ...
Sorry, an error occurred while loading the content.

Re: Suggestions on submission port config

Expand Messages
  • Jorey Bump
    Scott Haneda wrote, at 04/30/2009 10:31 PM: ... You can alter the name syslog uses for the submission service by adding: -o syslog_name=postfix-submission I
    Message 1 of 16 , May 1, 2009
    • 0 Attachment
      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.).
    • Jorey Bump
      ... Have you investigated the nature of this problem? ... You might be chasing a red herring. If your server is overloaded, there is a reason why, and there
      Message 2 of 16 , May 1, 2009
      • 0 Attachment
        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
        > smtpd_tls_key_file = /opt/local/etc/ssl/private/postfix.pem

        Keep.

        > smtpd_tls_loglevel = 0

        Adjust when troubleshooting.

        > smtpd_tls_received_header = yes
        > smtpd_tls_security_level = may

        Keep.

        > smtpd_tls_session_cache_database =
        > btree:$data_directory/smtpd_tls_session_cache

        Keep if you need it.

        > tls_random_source = dev:/dev/urandom

        Probably the default. It's generally a good thing, because /dev/urandom
        is nonblocking. Some systems might use /dev/random, which blocks and can
        hurt performance in low entropy environments (opinion on security
        implications is mixed).

        > 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.

        > 465 inet n - n -
        > - smtpd
        > -o smtpd_tls_wrappermode=yes
        > -o smtpd_sasl_auth_enable=yes
        > -o smtpd_client_restrictions=permit_sasl_authenticated

        Don't use smtps port 465 unless you need it.

        Here's an example from one of my servers:

        submission inet n - n - - smtpd
        -o smtpd_tls_security_level=encrypt
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

        smtps inet n - n - - smtpd
        -o smtpd_tls_wrappermode=yes
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
      • Victor Duchovni
        ... 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
        Message 3 of 16 , May 1, 2009
        • 0 Attachment
          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:majordomo@...?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.
        • Jorey Bump
          ... FTR: No, I didn t! :)
          Message 4 of 16 , May 1, 2009
          • 0 Attachment
            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).
          • Scott Haneda
            ... Nice, thanks. ... Glad you pointed that out, slipped my mind, but that is probably the most compelling reason to get all users to port 587 for me at least.
            Message 5 of 16 , May 1, 2009
            • 0 Attachment
              On May 1, 2009, at 6:30 AM, Jorey Bump wrote:
              > 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

              Nice, thanks.

              > Well, that's another potential advantage of using port 587: you can
              > spare authenticated users (and your system) from filter/proxy scans.

              Glad you pointed that out, slipped my mind, but that is probably the
              most compelling reason to get all users to port 587 for me at least.

              > 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.

              Indeed, great point.

              >>> 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.

              Thanks for the heads up, I will make sure I am patched. I have been
              using SM for years now, I just find it is too slow, and even with some
              skins, is not what my users are after. I have a feeling the slowness
              will be a non issues once I get dovecot talking to it. However, my
              users rarely care about what is under the hood, and eat with their eyes.

              >> 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.

              I hear ya. Auto configuration is something Apple Mail only seems to
              do. I have never seen it in other apps, though I have only personally
              used Entourage. I use Thunderbird in testing now, and I do not see
              any really slick auto conf in there either.

              Let me put it this way, many times, my users can not enter in their
              own email address, or will enter in a host name as mail@...
              over mail.example.com, I know right away when I tell them to "get
              mail" and do not see the connection come in.

              I have learned the common mistakes they make, but even a auto
              configuration still requires some data entry on their part. What I
              would prefer is a simple xml or text file, that I could tell them to
              import into a mail app, this could be universal, and have all the
              settings in it, sans a password.

              >> 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.).


              Thanks, makes good sense.
              --
              Scott * If you contact me off list replace talklists@ with scott@ *
            • Scott Haneda
              ... 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,
              Message 6 of 16 , May 1, 2009
              • 0 Attachment
                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 warnings to your users.

                I plan on getting one from a good provider. I have seen too many
                cases where Safari balks at the 10.00 ones from GoDaddy, and it seems
                hit or miss as to which ones they supply that will be an issue. I do
                not mind paying a one time fee even if it is a little pricey, to gain
                reliability.

                >>> # 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? 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.

                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.

                Just curious, if you do not have time to explore this side of the
                conversation, I understand.

                >> 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).

                Ok, sounds like a solid plan. I mostly am supporting Mac users, and
                can easily mimic the desktop clients they are using. On the windows
                side, any open client should for the connection level, be able to be
                tested on the Mac. As far as I know, this leaves me with Outlook.

                There are countless versions of Outlook, I guess I will have to track
                down a PC I can use, or a friend who can let me remote into one.

                >> smtp_tls_session_cache_database =
                >> btree:$data_directory/smtp_tls_session_cache
                >
                > Keep if you need it.

                I wish I knew where I picked up this setting. Reading the docs at ( http://www.postfix.org/postconf.5.html
                ) does not lead me to an answer as to whether I need it or not.
                Where can I find out more about this and what the pros and cons are?

                >> 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?

                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.

                >> smtpd_tls_ask_ccert = yes
                >
                > Why?

                I wish I knew, removed, letting it use default of no.

                >> smtpd_tls_session_cache_database =
                >> btree:$data_directory/smtpd_tls_session_cache
                >
                > Keep if you need it.

                Same here as the other cache entry, not able to really find why I want
                it or do not want it for my configuration.

                >> tls_random_source = dev:/dev/urandom
                >
                > Probably the default.

                My default as per postconf -d is empty.

                > It's generally a good thing, because /dev/urandom
                > is nonblocking. Some systems might use /dev/random, which blocks and
                > can
                > hurt performance in low entropy environments (opinion on security
                > implications is mixed).

                That exactly why I chose this one, urandom, I read the wiki page on
                it, and though there is less entropy than /dev/random I liked the fact
                that calls were not blocked.

                >> 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?

                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.

                >> 465 inet n - n -
                >> - smtpd
                >> -o smtpd_tls_wrappermode=yes
                >> -o smtpd_sasl_auth_enable=yes
                >> -o smtpd_client_restrictions=permit_sasl_authenticated
                >
                > Don't use smtps port 465 unless you need it.

                Ok, I am going to comment that out, get my hands on as many email
                clients as I can, and start running some tests.

                > Here's an example from one of my servers:
                >
                > submission inet n - n - - smtpd
                > -o smtpd_tls_security_level=encrypt
                > -o smtpd_sasl_auth_enable=yes
                > -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
                >
                > smtps inet n - n - - smtpd
                > -o smtpd_tls_wrappermode=yes
                > -o smtpd_sasl_auth_enable=yes
                > -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

                What specifically about smtps was it that you ended up determining you
                needed it?

                I can not thank you enough for all your time. Have a good weekend.
                --
                Scott * If you contact me off list replace talklists@ with scott@ *
              • Jorey Bump
                ... 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
                Message 7 of 16 , May 1, 2009
                • 0 Attachment
                  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.
                Your message has been successfully submitted and would be delivered to recipients shortly.