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

Re: Suggestions on submission port config

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.