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

Re: Suggestions on submission port config

Expand Messages
  • 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 1 of 16 , May 1, 2009
      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 2 of 16 , May 1, 2009
        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.