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

Suggestions on submission port config

Expand Messages
  • Scott Haneda
    Hello, mail_version = 2.5.5, Dovecot for pop and imap, myqsl as the auth backend. I am a little confused about main.cf and master.cf. Is there overlap in some
    Message 1 of 16 , Apr 24, 2009
    • 0 Attachment
      Hello, mail_version = 2.5.5, Dovecot for pop and imap, myqsl as the
      auth backend.

      I am a little confused about main.cf and master.cf. Is there overlap
      in some of the settings? Do some settings exist in both files, or at
      least are interchangable? If this is the case, under what conditions
      do you decide to do so?

      I successfully sent emails through this system as unauthenticated,
      authenticated, with tls, and with ssl. This is a migration, and I
      would like to have minimal email client settings needing change. My
      old server did not have SSL or TLS.

      Old Server:
      No SSL, No TLS
      port 25 = normal inbound, plus smtp auth'd users
      port 587 = forced auth'd users

      I am willing to disallow user connection to port 25. How do I do
      this? In main.cf or master.cf? Right now, I believe I only have this:
      [snip... master.cf ]
      smtp inet n - n - - smtpd
      I believe I need to add a restriction in there to stop clients from
      connecting?

      For port 587 submission, I want to offer SSL, TLS, and non encrypted
      to cover the users who will not want to change their settings. I can
      not seem to get this to work, it is either no encryption, or forced
      encryption.

      [snip... master.cf ]
      submission inet n - n - - smtpd
      -o smtpd_tls_security_level=encrypt
      -o smtpd_sasl_auth_enable=yes
      -o smtpd_client_restrictions=permit_sasl_authenticated
      -o milter_macro_daemon_name=ORIGINATING

      * Do I even need the milter line?

      Port 465, I believe will be reserved exclusively for SSL? Port 587
      does the TLS, is that correct? Or is the SSL just wrapping around the
      TLS?

      [snip... master.cf ]
      465 inet n - n - - smtpd
      -o smtpd_tls_wrappermode=yes
      -o smtpd_sasl_auth_enable=yes
      -o smtpd_client_restrictions=permit_sasl_authenticated,reject
      -o milter_macro_daemon_name=ORIGINATING

      * Do I need this milter line?

      In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse,
      Kerberos, and Password. In Thunderbird I notices there are no such
      options. Which are used in Thunderbird? What is the best to use, or
      is it only applicable if you are choosing to not use SSL/TLS?

      I have been pretty up and down the docs, this is somehow not making a
      lot of sense. I think once I understand what crosses over in config
      from main.cf and master.cf, it will make more sense.

      postconf -n
      alias_maps = hash:/opt/local/etc/postfix/aliases
      biff = no
      broken_sasl_auth_clients = yes
      command_directory = /opt/local/sbin
      config_directory = /opt/local/etc/postfix
      daemon_directory = /opt/local/libexec/postfix
      data_directory = /opt/local/var/lib/postfix
      debug_peer_level = 2
      debug_peer_list = 127.0.0.1
      default_privs = nobody
      disable_vrfy_command = yes
      html_directory = no
      inet_interfaces = all
      invalid_hostname_reject_code = 450
      mail_owner = _postfix
      mailq_path = /opt/local/bin/mailq
      manpage_directory = /opt/local/share/man
      maps_rbl_reject_code = 450
      message_size_limit = 0
      mydestination = localhost
      myhostname = catalyst.hostwizard.com
      mynetworks = 64.84.37.0/26
      newaliases_path = /opt/local/bin/newaliases
      non_fqdn_reject_code = 450
      queue_directory = /opt/local/var/spool/postfix
      readme_directory = /opt/local/share/postfix/readme
      sample_directory = /opt/local/share/postfix/sample
      sendmail_path = /opt/local/sbin/sendmail
      setgid_group = _postdrop
      smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
      smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
      smtp_tls_security_level = may
      smtp_tls_session_cache_database = btree:$data_directory/
      smtp_tls_session_cache
      smtpd_data_restrictions = reject_unauth_pipelining,
      reject_multi_recipient_bounce, permit
      smtpd_helo_required = yes
      smtpd_recipient_restrictions = permit_mynetworks
      permit_sasl_authenticated reject_unauth_destination permit
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_authenticated_header = yes
      smtpd_sasl_exceptions_networks = $mynetworks
      smtpd_sasl_local_domain = $myhostname
      smtpd_sasl_path = private/auth
      smtpd_sasl_security_options = noanonymous
      smtpd_sasl_type = dovecot
      smtpd_tls_ask_ccert = yes
      smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem
      smtpd_tls_key_file = /opt/local/etc/ssl/private/postfix.pem
      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_security_level = may
      smtpd_tls_session_cache_database = btree:$data_directory/
      smtpd_tls_session_cache
      tls_random_source = dev:/dev/urandom
      unknown_local_recipient_reject_code = 550
      virtual_alias_maps = mysql:/opt/local/etc/postfix/mysql-virtual-alias-
      maps.cf,mysql:/opt/local/etc/postfix/mysql-email2email.cf
      virtual_gid_maps = static:5000
      virtual_mailbox_base = /opt/local/var/vmail
      virtual_mailbox_domains = mysql:/opt/local/etc/postfix/mysql-virtual-
      mailbox-domains.cf
      virtual_mailbox_maps = mysql:/opt/local/etc/postfix/mysql-virtual-
      mailbox-maps.cf
      virtual_minimum_uid = static:5000
      virtual_transport = dovecot
      virtual_uid_maps = static:5000

      --
      Scott * If you contact me off list replace talklists@ with scott@ *
    • Jorey Bump
      ... From master(5) [http://www.postfix.org/master.5.html]: -o name=value Override the named main.cf configuration parameter. The parameter value can refer
      Message 2 of 16 , Apr 24, 2009
      • 0 Attachment
        Scott Haneda wrote, at 04/24/2009 07:58 AM:

        > I am a little confused about main.cf and master.cf. Is there overlap in
        > some of the settings? Do some settings exist in both files, or at least
        > are interchangable? If this is the case, under what conditions do you
        > decide to do so?

        From master(5) [http://www.postfix.org/master.5.html%5d:

        -o name=value
        Override the named main.cf configuration
        parameter. The parameter value can refer to
        other parameters as $name etc., just like in
        main.cf. See postconf(5) for syntax.

        As implied, it's useful when you need to override the settings in
        main.cf to get different behaviour appropriate to the service you're
        setting up in master.cf (submission, reinjection from proxy/filter, etc.).

        > I successfully sent emails through this system as unauthenticated,
        > authenticated, with tls, and with ssl. This is a migration, and I would
        > like to have minimal email client settings needing change. My old
        > server did not have SSL or TLS.
        >
        > Old Server:
        > No SSL, No TLS
        > port 25 = normal inbound, plus smtp auth'd users
        > port 587 = forced auth'd users
        >
        > I am willing to disallow user connection to port 25. How do I do this?
        > In main.cf or master.cf? Right now, I believe I only have this:
        > [snip... master.cf ]
        > smtp inet n - n - - smtpd
        > I believe I need to add a restriction in there to stop clients from
        > connecting?

        There was a recent thread on this subject, worth reading:

        http://www.mail-archive.com/postfix-users@.../msg06230.html

        > For port 587 submission, I want to offer SSL, TLS, and non encrypted to
        > cover the users who will not want to change their settings. I can not
        > seem to get this to work, it is either no encryption, or forced encryption.
        >
        > [snip... master.cf ]
        > submission inet n - n - - smtpd
        > -o smtpd_tls_security_level=encrypt
        > -o smtpd_sasl_auth_enable=yes
        > -o smtpd_client_restrictions=permit_sasl_authenticated
        > -o milter_macro_daemon_name=ORIGINATING

        Use:

        -o smtpd_tls_security_level=may
        -o smtpd_tls_auth_only=no

        I think it's normally a bad idea not to enforce TLS on the submission
        port, but if you're using a secure mechanism and want to prevent weaker
        ones, add:

        -o smtpd_sasl_security_options=noanonymous,noplaintext
        -o smtpd_sasl_tls_security_options=noanonymous

        > * Do I even need the milter line?

        Good question. It may depend on whether or not you use milters. I don't,
        but I leave it in because I don't want issues later if I decide to
        deploy a milter.

        > Port 465, I believe will be reserved exclusively for SSL? Port 587 does
        > the TLS, is that correct? Or is the SSL just wrapping around the TLS?
        >
        > [snip... master.cf ]
        > 465 inet n - n - - smtpd
        > -o smtpd_tls_wrappermode=yes
        > -o smtpd_sasl_auth_enable=yes
        > -o smtpd_client_restrictions=permit_sasl_authenticated,reject
        > -o milter_macro_daemon_name=ORIGINATING

        This is for legacy support. I suggest you don't activate it until you're
        sure you need it. Wrapper mode is different from offering STARTTLS.
        Nearly all modern clients support STARTTLS. If someone absolutely needs
        port 465, that could be a red flag that the user needs an upgrade.
        However, some webmail programs might have poor support for STARTTLS,
        forcing you to enable smtps if you require an encrypted connection.

        > In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse,
        > Kerberos, and Password. In Thunderbird I notices there are no such
        > options. Which are used in Thunderbird? What is the best to use, or is
        > it only applicable if you are choosing to not use SSL/TLS?

        Thunderbird has a "Use secure authentication" checkbox that supports
        multiple mechanisms (independent of SSL/TLS). Unfortunately, *it*
        decides which one to use, which I find very frustrating. I'm happy for
        mail clients to select the best mechanisms available for easy
        autoconfiguration, but it would be nice to have the ability to set them
        explicitly (for troubleshooting or security reasons).

        In any case, it's good practice to check this box if the server supports
        secure mechanisms, for a little extra protection beyond SSL/TLS.

        > I have been pretty up and down the docs, this is somehow not making a
        > lot of sense. I think once I understand what crosses over in config
        > from main.cf and master.cf, it will make more sense.
        >
        > postconf -n

        > smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
        > smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem

        If you're not using client certificate authentication (and you probably
        aren't), delete those lines.

        > smtp_tls_security_level = may

        This is good.

        > smtpd_recipient_restrictions = permit_mynetworks
        > permit_sasl_authenticated reject_unauth_destination permit

        You can remove permit_sasl_authenticated from here if you don't want to
        offer authenticated submission on port 25...

        > smtpd_sasl_auth_enable = yes

        ...and change this to no (or remove the line, as no is the default).

        > smtpd_sasl_authenticated_header = yes
        > smtpd_sasl_exceptions_networks = $mynetworks
        > smtpd_sasl_local_domain = $myhostname
        > smtpd_sasl_path = private/auth
        > smtpd_sasl_security_options = noanonymous
        > smtpd_sasl_type = dovecot

        I'd probably leave these in main.cf, just to keep master.cf simple, but
        it's your choice. Also, you can probably drop
        smtpd_sasl_exceptions_networks, as it won't make sense if you disable
        SMTP AUTH on port 25 and require authentication on port 587.
      • Scott Haneda
        Thanks for this, this is getting me on track, comments interspersed below... ... I have a little affliction against man type pages, they never seem to make a
        Message 3 of 16 , Apr 24, 2009
        • 0 Attachment
          Thanks for this, this is getting me on track, comments interspersed
          below...

          On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote:

          > Scott Haneda wrote, at 04/24/2009 07:58 AM:
          >
          >> I am a little confused about main.cf and master.cf. Is there
          >> overlap in
          >> some of the settings? Do some settings exist in both files, or at
          >> least
          >> are interchangable? If this is the case, under what conditions do
          >> you
          >> decide to do so?
          >
          > From master(5) [http://www.postfix.org/master.5.html%5d:
          >
          > -o name=value
          > Override the named main.cf configuration
          > parameter. The parameter value can refer to
          > other parameters as $name etc., just like in
          > main.cf. See postconf(5) for syntax.
          >
          > As implied, it's useful when you need to override the settings in
          > main.cf to get different behaviour appropriate to the service you're
          > setting up in master.cf (submission, reinjection from proxy/filter,
          > etc.).

          I have a little affliction against man type pages, they never seem to
          make a lot of sense to me :) This section does though. Just to be
          clear, this is a full blown over-ride, in that deleting the
          corresponding value from main.cf would do nothing to the server, so
          long as it exists in master.cf?

          [snip...]

          >> I am willing to disallow user connection to port 25. How do I do
          >> this?
          >> In main.cf or master.cf? Right now, I believe I only have this:
          >> [snip... master.cf ]
          >> smtp inet n - n - - smtpd
          >> I believe I need to add a restriction in there to stop clients from
          >> connecting?
          >
          > There was a recent thread on this subject, worth reading:
          >
          > http://www.mail-archive.com/postfix-users@.../msg06230.html

          Nice, thanks again, that was very telling. I will use that as a
          reference on how to best set this up, I think I still have some
          general questions below, as a result of my never having dealt with SSL/
          TLS other than on ftp servers and SSL in the http space.

          >> For port 587 submission, I want to offer SSL, TLS, and non
          >> encrypted to
          >> cover the users who will not want to change their settings. I can
          >> not
          >> seem to get this to work, it is either no encryption, or forced
          >> encryption.
          >>
          >> [snip... master.cf ]
          >> submission inet n - n - - smtpd
          >> -o smtpd_tls_security_level=encrypt
          >> -o smtpd_sasl_auth_enable=yes
          >> -o smtpd_client_restrictions=permit_sasl_authenticated
          >> -o milter_macro_daemon_name=ORIGINATING
          >
          > Use:
          >
          > -o smtpd_tls_security_level=may
          > -o smtpd_tls_auth_only=no
          >
          > I think it's normally a bad idea not to enforce TLS on the submission
          > port, but if you're using a secure mechanism and want to prevent
          > weaker
          > ones, add:
          >
          > -o smtpd_sasl_security_options=noanonymous,noplaintext
          > -o smtpd_sasl_tls_security_options=noanonymous

          If you do not like a lack of TLS enforcement on the submission port
          what do you suggest for users who just do not care enough to use any
          TLS? You let them work on port 25? I could go that route, but I am
          really trying to find a way to do traffic isolation. If I know no
          client connections are made on 25, from a troubleshooting perspective
          alone, it seems to make things simpler on me.

          My mailserver has a setting where I can disable auth on port 25.
          Maybe I will do this pre-migration, which would allow me to force all
          my users to change to port 25. The hobbly little server I am using
          now does not offer any way for me to look and see what users are
          connecting on 25 still. I think most are on 587 as a result of most
          ISP's filtering 25.

          Maybe a little tcpdump would get me those numbers.

          >> * Do I even need the milter line?
          >
          > Good question. It may depend on whether or not you use milters. I
          > don't,
          > but I leave it in because I don't want issues later if I decide to
          > deploy a milter.

          Quick research seems to lead me to believe milter is for mail
          filtering, hence the name. Since I plan to have a proxy sit in front
          of my system, it should be safe to never use milter at all?

          I may want to auto file IMAP email to a junk mail folder, but I
          believe that would be done in dovecot, not postfix.

          >> Port 465, I believe will be reserved exclusively for SSL? Port 587
          >> does
          >> the TLS, is that correct? Or is the SSL just wrapping around the
          >> TLS?
          >>
          >> [snip... master.cf ]
          >> 465 inet n - n - - smtpd
          >> -o smtpd_tls_wrappermode=yes
          >> -o smtpd_sasl_auth_enable=yes
          >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
          >> -o milter_macro_daemon_name=ORIGINATING
          >
          > This is for legacy support. I suggest you don't activate it until
          > you're
          > sure you need it. Wrapper mode is different from offering STARTTLS.
          > Nearly all modern clients support STARTTLS. If someone absolutely
          > needs
          > port 465, that could be a red flag that the user needs an upgrade.
          > However, some webmail programs might have poor support for STARTTLS,
          > forcing you to enable smtps if you require an encrypted connection.

          Glad you brought up webmail. I am going to use Roundcube, on the same
          machine, worst case, on a close machine, in the same subnet. Since I
          have the nynetworks setting set to allow mail, all should be ok? I do
          not want to deal with AUTH for SMTP in webmail, it is going to be
          local to local, I see no point in securing that part. Is that correct?

          I am confused about your comments about 465. Reading it makes me
          think that 465 is sort of a last resort option. I am not
          understanding the difference between SSL and TLS. If I was setting up
          a email client, and could use TLS versus SSL, my logic would be to use
          SSL, it seems the better option, but I do not know why.

          Are you saying SSL email is the lesser of the options, and I should
          use TLS when I can?

          So the ideal situation is using TLS on a non 25 submission port?

          Do you know how this related to Apple Mail? There is no setting in
          the SMTP section to opt for SSL versus TLS? "Use SSL" is the only
          checkbox there is. I take it if you do not select that, it will use
          TLS if it can, but do so in a invisible way?

          It probably is this setting that has lead me down the road of thinking
          SSL is better, as Apple Mail offers what appears to be no encryption,
          or SSL, there is no implicit TLS setting.

          Looking at Outlook settings: http://www.math.uwaterloo.ca/mfcf/announcements/images/outlook2.png
          It appears in the same case, SSL is going to be selected, as the
          better way, I see no way to use TLS. Maybe I am not groking any of
          this, any brief explanation of this sure would help.

          >> In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse,
          >> Kerberos, and Password. In Thunderbird I notices there are no such
          >> options. Which are used in Thunderbird? What is the best to use,
          >> or is
          >> it only applicable if you are choosing to not use SSL/TLS?
          >
          > Thunderbird has a "Use secure authentication" checkbox that supports
          > multiple mechanisms (independent of SSL/TLS). Unfortunately, *it*
          > decides which one to use, which I find very frustrating.

          I am glad you brought up "Use secure authentication", what exactly
          does this setting do? In Thunderbird, there is none, optional TLS,
          and SSL, and then this "use secure auth" setting. That is a lot of
          control, and totally unclear on what setting in postfix that secure
          auth checkbox is going to run up against.

          Apple Mail does not even have such a setting, so I assume it is one of
          the encryption modes that kicks it in?

          > I'm happy for
          > mail clients to select the best mechanisms available for easy
          > autoconfiguration, but it would be nice to have the ability to set
          > them
          > explicitly (for troubleshooting or security reasons).
          >
          > In any case, it's good practice to check this box if the server
          > supports
          > secure mechanisms, for a little extra protection beyond SSL/TLS.

          What more do I need to do in postfix cf files to support this
          setting? Any downsides as far as performance and load?

          >> I have been pretty up and down the docs, this is somehow not making a
          >> lot of sense. I think once I understand what crosses over in config
          >> from main.cf and master.cf, it will make more sense.
          >>
          >> postconf -n
          >
          >> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
          >> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
          >
          > If you're not using client certificate authentication (and you
          > probably
          > aren't), delete those lines.

          Well now you threw me for a loop :) I am a small ISP, and I will buy a
          emailserver.company.example.com SSL cert. As it is now, in email
          clients, I get a box pop up asking me to approve my current self
          signed one as a non known untrusted authority. I just select accept
          always and move on.

          So removing those certs above just removes the certificate trust
          issue, but does not change any of the encryption methods I have going
          on? In apache, I can not enable SSL, as far as I know, without a
          cert. I was under the impression, if I want to offer SSL, I am going
          to need those certs?

          >> smtp_tls_security_level = may
          >
          > This is good.

          Thanks. I am going through each config option and reading on each
          one, trying to get to a default fallback for as many as possible, and
          then understanding the rest that I have to have.

          >> smtpd_recipient_restrictions = permit_mynetworks
          >> permit_sasl_authenticated reject_unauth_destination permit
          >
          > You can remove permit_sasl_authenticated from here if you don't want
          > to
          > offer authenticated submission on port 25...

          In my context of using Dovecot, and not using the cyrus sasl thingy,
          where I see mention of _sasl_ in a config line, that is in reference
          to both SSL and TLS?

          >> smtpd_sasl_auth_enable = yes
          >
          > ...and change this to no (or remove the line, as no is the default).

          Thanks, I will have to look up this setting again.

          >> smtpd_sasl_authenticated_header = yes
          >> smtpd_sasl_exceptions_networks = $mynetworks
          >> smtpd_sasl_local_domain = $myhostname
          >> smtpd_sasl_path = private/auth
          >> smtpd_sasl_security_options = noanonymous
          >> smtpd_sasl_type = dovecot
          >
          > I'd probably leave these in main.cf, just to keep master.cf simple,
          > but
          > it's your choice. Also, you can probably drop
          > smtpd_sasl_exceptions_networks, as it won't make sense if you disable
          > SMTP AUTH on port 25 and require authentication on port 587.


          Thanks so much for this. As a side note, there are not a lot of
          people running postfix with dovecot on OS X Client. Postfix of course
          is default in OS X Server. This is all a result of me trying to built
          out a one command port installer for both, on OS X. I finally have it
          mostly working, but want to get a "sane" set of config options that I
          can point people to as a basis to start.
          --
          Scott * If you contact me off list replace talklists@ with scott@ *
        • Larry Stone
          ... Every connection made to port 25 is from a client. Some are internal clients (usually users) and some are external clients (usually other mailservers but
          Message 4 of 16 , Apr 24, 2009
          • 0 Attachment
            On 4/24/09 6:41 PM, Scott Haneda at talklists@... wrote:

            > If you do not like a lack of TLS enforcement on the submission port
            > what do you suggest for users who just do not care enough to use any
            > TLS? You let them work on port 25? I could go that route, but I am
            > really trying to find a way to do traffic isolation. If I know no
            > client connections are made on 25, from a troubleshooting perspective
            > alone, it seems to make things simpler on me.

            Every connection made to port 25 is from a client. Some are internal clients
            (usually users) and some are external clients (usually other mailservers but
            acting as a client from the view of your mailserver). But they are all
            clients. If you think of users as clients and external mailservers as
            something else, you'll have trouble configuring things correctly.

            --
            Larry Stone
            lstone19@...
            http://www.stonejongleux.com/
          • Scott Haneda
            ... Right, but that is a tad pedantic given the context of my other emails :) The context it that case would have been a person, as in a client of mine, or an
            Message 5 of 16 , Apr 24, 2009
            • 0 Attachment
              On Apr 24, 2009, at 4:50 PM, Larry Stone wrote:

              > On 4/24/09 6:41 PM, Scott Haneda at talklists@... wrote:
              >
              >> If you do not like a lack of TLS enforcement on the submission port
              >> what do you suggest for users who just do not care enough to use any
              >> TLS? You let them work on port 25? I could go that route, but I am
              >> really trying to find a way to do traffic isolation. If I know no
              >> client connections are made on 25, from a troubleshooting perspective
              >> alone, it seems to make things simpler on me.
              >
              > Every connection made to port 25 is from a client. Some are internal
              > clients
              > (usually users) and some are external clients (usually other
              > mailservers but
              > acting as a client from the view of your mailserver). But they are all
              > clients. If you think of users as clients and external mailservers as
              > something else, you'll have trouble configuring things correctly.

              Right, but that is a tad pedantic given the context of my other
              emails :) The context it that case would have been a person, as in a
              client of mine, or an email client. For clarity, in my referenced
              post above, when I said "client", I meant a desktop email client, such
              as Outlook, Mail, Entourage, Thunderbird etc.
              --
              Scott * If you contact me off list replace talklists@ with scott@ *
            • Barney Desmond
              ... Not quite. It s an override for when you want to change the settings for a particular daemon. Overrides in master.cf don t propagate out to the rest of
              Message 6 of 16 , Apr 24, 2009
              • 0 Attachment
                2009/4/25 Scott Haneda <talklists@...>:
                > I have a little affliction against man type pages, they never seem to make a
                > lot of sense to me :)  This section does though.  Just to be clear, this is
                > a full blown over-ride, in that deleting the corresponding value from
                > main.cf would do nothing to the server, so long as it exists in master.cf?

                Not quite. It's an override for when you want to change the settings
                for a particular daemon. Overrides in master.cf don't "propagate" out
                to the rest of the config though. If you want a setting, put it in
                main.cf. If a particular process needs an override, *then* it goes in
                master.cf. A relevant example:

                For spam-filtering most people fill out smtpd_recipient_restrictions.
                smtpd_recipient_restrictions will be used for any smtpd process, which
                in master.cf is the lines like this:
                smtp inet n - - - - smtpd
                submission inet n - - - - smtpd
                smtps inet n - - - - smtpd

                A lot of the time you'd like a different set of
                smtpd_recipient_restrictions for the submission port. *That's* when
                you override it; you DO NOT delete the smtpd_recipient_restrictions
                from main.cf! Otherwise you'll get the default restrictions for your
                smtp and smtps ports.

                > If you do not like a lack of TLS enforcement on the submission port what do
                > you suggest for users who just do not care enough to use any TLS?  You let
                > them work on port 25?  I could go that route, but I am really trying to find
                > a way to do traffic isolation.  If I know no client connections are made on
                > 25, from a troubleshooting perspective alone, it seems to make things
                > simpler on me.
                >
                > My mailserver has a setting where I can disable auth on port 25.  Maybe I
                > will do this pre-migration, which would allow me to force all my users to
                > change to port 25.  The hobbly little server I am using now does not offer
                > any way for me to look and see what users are connecting on 25 still.  I
                > think most are on 587 as a result of most ISP's filtering 25.

                There's a few distinct concepts here:

                SSL and TLS. While it's not entirely accurate, it's easiest to think
                of it in this way: SSL is an encrypted pipe that goes around the smtp
                session. SSL is negotiated before SMTP starts and is transparent to
                the MTA at each end. This is why you can use tools like stunnel to
                setup transparent security for HTTP, SMTP, etc. TLS is negotiated
                in-band, at least for SMTP. The session starts in plaintext, the
                server offers STARTTLS in its reply to EHLO, the client can choose to
                initiate negotiation by sending "STARTTLS", then the crypto kicks in
                and the session is protected. Each side then keeps talking SMTP as
                usual.
                http://en.wikipedia.org/wiki/STARTTLS

                Port 25 == regular SMTP, this must always be enabled if you want to
                receive mail from the internet
                Port 465 == de-facto port for running SSL-mode SMTP
                Port 587 == usual port for running "TLS" SMTP - this is exactly the
                same as port 25 however! You can talk plain SMTP to port 587 if you
                want, try it in a telnet session.

                Because port 25 and port 587 are configured separately in master.cf,
                you can have different settings. You can't enforce crypto on port 25,
                but you can do that on port 587 if you want. You can enforce the
                requirement to perform auth on port 587 if you want.


                Auth and crypto: these are separate things. MTAs can use opportunistic
                encryption across the internet even if they don't know each other;
                this is confidentiality without authentication. Given that regular
                mail transit is already unauthenticated, this can only be a net gain.
                Authentication is what you want your users to do before they can relay
                mail. In the context of SMTP it just means they prove their username
                and password to you, one way or another.

                Obviously it's bad if customers send their username and password in
                the clear, which is why you can tackle this in a couple of ways.

                1. Require them to use a "secure" authentication protocol - this does
                *not* necessarily imply crypto, which is where a lot of confusion
                stems from. If you send me your password in plaintext, that's
                "insecure". If we perform a challenge-response session, you send me a
                hash that allows me to verify your password, but your password was not
                transmitted, so attackers can't steal it - that's "secure". Due to
                various reasons relating to secure storage of passwords, using an
                insecure auth protocol means I don't have to store a plaintext copy of
                your password on the server; that's a Good Thing. A "secure" auth
                protocol like CRAM-MD5 requires the server to have a plaintext or
                effectively-plaintext copy of your password, and that's not as nice.
                Note that even if I use a secure auth protocol, the rest of the mail
                session is unprotected and can be read by an attacker sniffing the
                wire.

                2. The alternative is to wrap everything in a crypto pipe - this is
                SSL or TLS. Once the whole session is encrypted we don't care how
                authentication happens, as confidentiality is provided externally.

                It's obvious that there's a 2x2 matrix of auth+crypto options here. If
                you're trying to be very flexible then you're probably interested in
                stopping the one possibility that could leak passwords - no-crypto
                while using insecure auth.

                > Glad you brought up webmail.  I am going to use Roundcube, on the same
                > machine, worst case, on a close machine, in the same subnet.  Since I have
                > the nynetworks setting set to allow mail, all should be ok?  I do not want
                > to deal with AUTH for SMTP in webmail, it is going to be local to local, I
                > see no point in securing that part.  Is that correct?

                This really depends how the webmail software implements the SMTP
                client side; I've not touched Roundcube so I can't say. If you're
                working on a trusted network then you don't need crypto and it's safe
                to let mail through by virtue of permit_mynetworks. It might still be
                beneficial to have authentication happening though. Depending on how
                Roundcube sends the mail, you may or may not have much of a
                paper-trail if you need to track down a rogue user with a compromised
                account (eg. if mail were submitted using the "sendmail" method, and
                users have someway of hiding their details, you might only see maillog
                entries from the "apache" user, and no way of knowing which webmail
                account is compromised).

                >>> In Apple Mail, there are auth options of ntlm, md5 Challenge-Reponse,
                >>> Kerberos, and Password.  In Thunderbird I notices there are no such
                >>> options.  Which are used in Thunderbird?  What is the best to use, or is
                >>> it only applicable if you are choosing to not use SSL/TLS?
                >>
                >> Thunderbird has a "Use secure authentication" checkbox that supports
                >> multiple mechanisms (independent of SSL/TLS). Unfortunately, *it*
                >> decides which one to use, which I find very frustrating.
                >
                > I am glad you brought up "Use secure authentication", what exactly does this
                > setting do?  In Thunderbird, there is none, optional TLS, and SSL, and then
                > this "use secure auth" setting.  That is a lot of control, and totally
                > unclear on what setting in postfix that secure auth checkbox is going to run
                > up against.
                >
                > Apple Mail does not even have such a setting, so I assume it is one of the
                > encryption modes that kicks it in?

                This is that crypto vs. auth thing again, hopefully it's a bit clearer
                now. I've not used mac mail myself, but my understanding is that it
                uses a bit of voodoo and works out the best parameters it can (ie. it
                just tries STARTTLS if offered by the server). Don't quote me on that
                though. As for auth options, "password" is the plaintext one that's
                okay to use on an unencrypted session.

                >> I'm happy for
                >> mail clients to select the best mechanisms available for easy
                >> autoconfiguration, but it would be nice to have the ability to set them
                >> explicitly (for troubleshooting or security reasons).
                >>
                >> In any case, it's good practice to check this box if the server supports
                >> secure mechanisms, for a little extra protection beyond SSL/TLS.
                >
                > What more do I need to do in postfix cf files to support this setting?  Any
                > downsides as far as performance and load?

                This depends on what you want your security policy to be. One useful
                main.cf option is smtpd_tls_auth_only - when TLS is optional, it'll
                only offer authentication if the connection is encrypted. (obviously
                it's always safe to offer authentication if encryption is mandatory).
                The catch is that authentication isn't strictly handled by postfix.
                Your SASL backend (cyrus or dovecot) specifies what authentication
                protocols are offered; I believe this is because it's the SASL daemon
                that has to deal with the password backend, so it's the right place
                for that sort of policy. You can't offer CRAM-MD5 if the passwords are
                stored in a hashed form; postfix has no knowledge of the password
                storage, so authentication can't be handled in postfix (though sasl
                can be tweaked a little).

                >>> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
                >>> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
                >>
                >> If you're not using client certificate authentication (and you probably
                >> aren't), delete those lines.
                >
                > Well now you threw me for a loop :) I am a small ISP, and I will buy a
                > emailserver.company.example.com SSL cert.  As it is now, in email clients, I
                > get a box pop up asking me to approve my current self signed one as a non
                > known untrusted authority.  I just select accept always and move on.
                >
                > So removing those certs above just removes the certificate trust issue, but
                > does not change any of the encryption methods I have going on?  In apache, I
                > can not enable SSL, as far as I know, without a cert.  I was under the
                > impression, if I want to offer SSL, I am going to need those certs?

                Correct, a paid-for cert will sidestep the trust issue for your users.
                It's the same here as it is in apache. Crypto certs are just "dumb
                data" - it's primarily key material, it doesn't affect how your crypto
                works, or how strong it is, etc.

                I think you misinterpreted that comment though. "If you're not using
                client certificate authentication, delete those lines". What was meant
                was, "if postfix isn't using certificates to authenticate ITSELF to
                other servers, delete these lines". Postfix can talk to other MTAs
                with crypto as well, this is the `smtp_tls_security_level` setting -
                notice the "smtp_" prefix on the config options, it's not "smtpd_".
                The thing is, you can do crypto with or without certs. A cert is just
                a combination of (optionally) signed identify data tied to key
                material. If you don't care about identities (and for MTA-to-MTA
                traffic on the public internet, we don't), you can negotiate an
                anonymous TLS session and everything works as you expect it should. By
                setting smtp_tls_cert_file (I think) you're telling postfix to
                negotiate a non-anonymous TLS session, which the other end may baulk
                on if it doesn't have a cert, or can't verify your cert's signer, or
                for any number of reasons.

                From the docs: http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
                "Do not configure client certificates unless you *must* present client
                TLS certificates to one or more servers. Client certificates are not
                usually needed, and can cause problems in configurations that work
                well without them. The recommended setting is to let the defaults
                stand" (all empty)

                >>> smtpd_recipient_restrictions = permit_mynetworks
                >>> permit_sasl_authenticated    reject_unauth_destination    permit
                >>
                >> You can remove permit_sasl_authenticated from here if you don't want to
                >> offer authenticated submission on port 25...
                >
                > In my context of using Dovecot, and not using the cyrus sasl thingy, where I
                > see mention of _sasl_ in a config line, that is in reference to both SSL and
                > TLS?

                Of course I can see no reason not to offer authentication on port 25,
                so long as the passwords are safe, for reasons described above. As
                we've already established, SASL is completely separate from SSL/TLS.

                >>> smtpd_sasl_authenticated_header = yes
                >>> smtpd_sasl_exceptions_networks = $mynetworks
                >>> smtpd_sasl_local_domain = $myhostname
                >>> smtpd_sasl_path = private/auth
                >>> smtpd_sasl_security_options = noanonymous
                >>> smtpd_sasl_type = dovecot
                >>
                >> I'd probably leave these in main.cf, just to keep master.cf simple, but
                >> it's your choice. Also, you can probably drop
                >> smtpd_sasl_exceptions_networks, as it won't make sense if you disable
                >> SMTP AUTH on port 25 and require authentication on port 587.

                I agree with this suggestion. You can keep sane settings in main.cf,
                it's nicer to leave master.cf alone. You also *probably* don't need to
                define smtpd_sasl_exceptions_networks.


                An example from my config, if it helps.


                # we can allow relaying by forcing senders to authenticate first (by
                permit_sasl_authenticated in smtpd_recipient_restrictions)
                smtpd_sasl_auth_enable = yes
                smtpd_sasl_security_options = noanonymous <-- this is the default, BTW
                smtpd_tls_security_level = may <-- offer but don't require TLS
                broken_sasl_auth_clients = yes

                # server TLS parameters
                smtpd_tls_key_file = /etc/ssl/yoshino.meidokon.net_key
                smtpd_tls_cert_file = /etc/ssl/yoshino.meidokon.net_crt
                smtpd_tls_auth_only = yes <-- as mentioned, user can only auth on a
                secure connection
                smtpd_tls_loglevel = 1
                smtpd_tls_received_header = yes

                # client TLS parameters, forward mail via TLS if possible
                smtp_tls_security_level = may



                These parameters will apply to all smtpd processes
                (smtp,smtps,submission) in master.cf unless you override the specific
                settings there. You may choose to enforce crypto on port 587 with "-o
                smtpd_tls_security_level=encrypt" but it's not technically necessary.
                You'll usually add "-o smtpd_tls_wrappermode=yes" to the smtps
                definition to get "SSL" mode working. I've personally got "-o
                smtpd_client_restrictions=permit_sasl_authenticated,reject" for my
                submission port.
              • Jorey Bump
                ... Yes. But keep in mind that most settings have a default value. It s healthy to define a base configuration in main.cf, where your needs differ from the
                Message 7 of 16 , Apr 24, 2009
                • 0 Attachment
                  Scott Haneda wrote, at 04/24/2009 07:41 PM:
                  > Thanks for this, this is getting me on track, comments interspersed
                  > below...
                  >
                  > On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote:
                  >
                  >> Scott Haneda wrote, at 04/24/2009 07:58 AM:
                  >>
                  >>> I am a little confused about main.cf and master.cf. Is there overlap in
                  >>> some of the settings? Do some settings exist in both files, or at least
                  >>> are interchangable? If this is the case, under what conditions do you
                  >>> decide to do so?
                  >>
                  >> From master(5) [http://www.postfix.org/master.5.html%5d:
                  >>
                  >> -o name=value
                  >> Override the named main.cf configuration
                  >> parameter. The parameter value can refer to
                  >> other parameters as $name etc., just like in
                  >> main.cf. See postconf(5) for syntax.
                  >>
                  >> As implied, it's useful when you need to override the settings in
                  >> main.cf to get different behaviour appropriate to the service you're
                  >> setting up in master.cf (submission, reinjection from proxy/filter,
                  >> etc.).
                  >
                  > I have a little affliction against man type pages, they never seem to
                  > make a lot of sense to me :) This section does though. Just to be
                  > clear, this is a full blown over-ride, in that deleting the
                  > corresponding value from main.cf would do nothing to the server, so long
                  > as it exists in master.cf?

                  Yes. But keep in mind that most settings have a default value. It's
                  healthy to define a base configuration in main.cf, where your needs
                  differ from the defaults, then only apply overrides in master.cf where
                  necessary.

                  >>> For port 587 submission, I want to offer SSL, TLS, and non encrypted to
                  >>> cover the users who will not want to change their settings.
                  >>
                  >> Use:
                  >>
                  >> -o smtpd_tls_security_level=may
                  >> -o smtpd_tls_auth_only=no
                  >>
                  >> I think it's normally a bad idea not to enforce TLS on the submission
                  >> port, but if you're using a secure mechanism and want to prevent weaker
                  >> ones, add:
                  >>
                  >> -o smtpd_sasl_security_options=noanonymous,noplaintext
                  >> -o smtpd_sasl_tls_security_options=noanonymous
                  >
                  > If you do not like a lack of TLS enforcement on the submission port what
                  > do you suggest for users who just do not care enough to use any TLS?

                  I suggest they use it if they want to send mail. :)

                  Since one of the purposes of the submission port is to support road
                  warriors, I feel it should be as secure as possible and the entire
                  communication should be encrypted.

                  > You let them work on port 25?

                  In some cases, I allow the use of a secure mechanism without TLS on port
                  25. This protects the login, but not the message contents. I don't allow
                  unencrypted plaintext logins.

                  > I could go that route, but I am really
                  > trying to find a way to do traffic isolation. If I know no client
                  > connections are made on 25, from a troubleshooting perspective alone, it
                  > seems to make things simpler on me.

                  I think it's reasonable. Just give your users advance notice so they can
                  change their settings.

                  > Glad you brought up webmail. I am going to use Roundcube, on the same
                  > machine, worst case, on a close machine, in the same subnet. Since I
                  > have the nynetworks setting set to allow mail, all should be ok? I do
                  > not want to deal with AUTH for SMTP in webmail, it is going to be local
                  > to local, I see no point in securing that part. Is that correct?

                  It's up to you. I use SMTP AUTH for webmail, partly because it provides
                  better logging for troubleshooting.

                  > I am confused about your comments about 465. Reading it makes me think
                  > that 465 is sort of a last resort option. I am not understanding the
                  > difference between SSL and TLS. If I was setting up a email client, and
                  > could use TLS versus SSL, my logic would be to use SSL, it seems the
                  > better option, but I do not know why.
                  >
                  > Are you saying SSL email is the lesser of the options, and I should use
                  > TLS when I can?

                  I'm saying that smtps (wrapper mode on port 465) is deprecated in favor
                  of STARTTLS on ports 25 or 587.

                  > So the ideal situation is using TLS on a non 25 submission port?

                  Ideally, STARTTLS on the standardized submission port 587.

                  > Do you know how this related to Apple Mail? There is no setting in the
                  > SMTP section to opt for SSL versus TLS? "Use SSL" is the only checkbox
                  > there is. I take it if you do not select that, it will use TLS if it
                  > can, but do so in a invisible way?

                  Default autoconfiguration appears to use ports 25, 465, & 587 and SSL if
                  detected. The server I tested supports all of these and the mechanism
                  list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration, Apple
                  Mail used STARTTLS and the PLAIN mechanism on port 25 to send a message.

                  I assume it follows an algorithm to determine a fallback strategy for
                  trying the other ports if its first choice is not available. Although I
                  would have preferred it start with port 587, the choice it made is
                  acceptably secure. If you only offer port 587, it probably won't pose
                  any problems (as long as it remembers the other ports are unavailable).

                  In any case, you can set the port & mechanism explicitly, and it will
                  negotiate TLS/SSL appropriately for either wrapper mode or STARTTLS.

                  > It probably is this setting that has lead me down the road of thinking
                  > SSL is better, as Apple Mail offers what appears to be no encryption, or
                  > SSL, there is no implicit TLS setting.
                  >
                  > Looking at Outlook settings:
                  > http://www.math.uwaterloo.ca/mfcf/announcements/images/outlook2.png
                  > It appears in the same case, SSL is going to be selected, as the better
                  > way, I see no way to use TLS. Maybe I am not groking any of this, any
                  > brief explanation of this sure would help.

                  Don't make assumptions based on the nonstandardized vocabulary found in
                  MUAs. In this context, "SSL" is meaningless and interchangeable with
                  "TLS" (technically, SSL evolved into TLS). STARTTLS is preferable to
                  smtps (SSL wrapper mode on port 465). But if you need to support smtps
                  for legacy clients, go ahead.

                  >> Thunderbird has a "Use secure authentication" checkbox that supports
                  >> multiple mechanisms (independent of SSL/TLS). Unfortunately, *it*
                  >> decides which one to use, which I find very frustrating.
                  >
                  > I am glad you brought up "Use secure authentication", what exactly does
                  > this setting do? In Thunderbird, there is none, optional TLS, and SSL,
                  > and then this "use secure auth" setting. That is a lot of control, and
                  > totally unclear on what setting in postfix that secure auth checkbox is
                  > going to run up against.

                  Sorry, my bad. "Use secure authentication" is only displayed in the
                  Server Settings area, which applies to POP/IMAP. Still, Thunderbird will
                  use secure mechanisms if available for SMTP. For example, if you have
                  active kerberos tickets for the SMTP server, I believe it will use them
                  for authentication. IIRC, there's a lot of imperfect magic that goes on
                  behind the scenes, and some room for improvement. It's especially
                  important to only offer mechanisms you actually support.

                  > Apple Mail does not even have such a setting, so I assume it is one of
                  > the encryption modes that kicks it in?

                  Apple Mail lets you specify which mechanism to use. During
                  autoconfiguration, it will choose from the list your server advertises.
                  Note that this list may differ depending on the presence of encryption.
                  Apple Mail appears to negotiate encryption if available, then choose
                  from the advertised list.

                  >> In any case, it's good practice to check this box if the server supports
                  >> secure mechanisms, for a little extra protection beyond SSL/TLS.
                  >
                  > What more do I need to do in postfix cf files to support this setting?
                  > Any downsides as far as performance and load?

                  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.

                  >>> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
                  >>> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
                  >>
                  >> If you're not using client certificate authentication (and you probably
                  >> aren't), delete those lines.
                  >
                  > Well now you threw me for a loop :) I am a small ISP, and I will buy a
                  > emailserver.company.example.com SSL cert. As it is now, in email
                  > clients, I get a box pop up asking me to approve my current self signed
                  > one as a non known untrusted authority. I just select accept always and
                  > move on.
                  >
                  > So removing those certs above just removes the certificate trust issue,
                  > but does not change any of the encryption methods I have going on? In
                  > apache, I can not enable SSL, as far as I know, without a cert. I was
                  > under the impression, if I want to offer SSL, I am going to need those
                  > certs?

                  No, you're thinking of smtpd_tls_*_file, which you still need. I'm
                  suggesting you might not need smtp_tls_*_file, which is used when
                  postfix is the client to other systems.

                  > In my context of using Dovecot, and not using the cyrus sasl thingy,
                  > where I see mention of _sasl_ in a config line, that is in reference to
                  > both SSL and TLS?

                  No. SASL is not SSL/TLS.
                • Scott Haneda
                  Barney, ( and Jorey ), thanks so much for your help in understanding this, moving to postfix is something I have needed to do for some time, glad to finally
                  Message 8 of 16 , Apr 30, 2009
                  • 0 Attachment
                    Barney, ( and Jorey ), thanks so much for your help in understanding
                    this, moving to postfix is something I have needed to do for some
                    time, glad to finally get down to it. I had to step away for a few
                    days and get some other work done, but made some good progress last
                    night. I have some more clarifications thought if you do not mind.

                    On Apr 24, 2009, at 9:35 PM, Barney Desmond wrote:

                    > 2009/4/25 Scott Haneda <talklists@...>:
                    >> If you do not like a lack of TLS enforcement on the submission port
                    >> what do
                    >>
                    >> [snip... on SSL/TLS methods]
                    >> think most are on 587 as a result of most ISP's filtering 25.
                    >
                    > There's a few distinct concepts here:
                    > [snip... Explanation of SSL/TLS]

                    I am hesitant to detract and add more to this, but here goes. My
                    current email server does not support SSL/TLS. I have 250-AUTH CRAM-
                    MD5 DIGEST-MD5 NTLM PLAIN LOGIN

                    ( Does the order of my methods matter? )

                    I do have some auth methods in regards to the user/pass, but from what
                    I understand, the data is always in the clear. My current setup is
                    *mostly* MTA to MTA on port 25, there are a handful of users whose
                    ISP's have not filtered 25, so those users are still on port 25.

                    I can force auth on 25, but with no way of testing that before
                    toggling the setting, I am not anxious to do so. tcpdump would be the
                    only way, and a little too much of a pain to deal with.

                    The reason I want to force all users to 587, and allow auth and crypto
                    on 587, and not mandate crypto exclusive, is that is how 99% of my
                    users are set now, 587 using md5-challenge response.

                    This has been done at suggestion of the developer of my current
                    server. What happens is, under heavy MTA load on port 25, I will run
                    out of connection slots on port 25. By moving users to 587, I do not
                    care about port 25 connection slots. MTA's will try again later if
                    busy.

                    What I do not want, is MUA users getting a server busy response on
                    port 25 just because mail volume is high that day. The general
                    suggested idea from the developer of my mail server is to move all
                    users to port 587, and only have MTA mail on port 25.

                    Hopefully this issue of running out of connections is not much an
                    issue in postfix. I also have a setting of "limit x connections from
                    same host". If I have an office of users, logging in over a LAN,
                    where their public IP is a fixed IP, and they all have private IP's,
                    my current mail server sees them all as many connections from the same
                    IP, and they get too many simultaneous connections errors. ( How does
                    postfix deal with this? )

                    Because of this, I can not limit connections from same host on port 25
                    to a reasonable number to slow dictionary attacks and the like, as the
                    office of 100 employees is going to hit a wall really soon.

                    By moving them to 587, I have more control.

                    Maybe I am just jaded in how my old email server forced me down a
                    path, and I should not worry about this, and allow 25 and 587 to
                    behave identical, with one exception in that 587 would disallow
                    explicitly any non authenticated connections.

                    I think I can force auth and crypto on 587 and not hassle my MUA users
                    one bit; then allow auth no crypto on 25, and also open it to non auth
                    non crypto for MTA chatting. Not sure if that is possible, to allow
                    non auth MTA mail on 25, but also tell MUA clients they must at
                    minimum, auth.

                    What do you guys think?

                    My end goal here is to get this all working, and then change these
                    ports to, for example, 25 -> 2525 and 587 -> 587587 unless there is
                    some other convention. I am going to put a anti spam proxy in front
                    of all this.

                    I just do not want to add too much to my learning curve, so first, get
                    postfix to where I understand it, then toggle the ports and put the
                    proxy in. It should blindly pass the traffic, I assume in much the
                    same way stunnel does.

                    I am open to any and all advice on this matter to make this work
                    best. I have a feeling later on down the road I will need to learn
                    exactly what things to disable in postfix, as it should not do any
                    bouncing at all, anything that will lead to backsplatter, since I am
                    putting a proxy ahead of it.

                    > 2. The alternative is to wrap everything in a crypto pipe - this is
                    > SSL or TLS. Once the whole session is encrypted we don't care how
                    > authentication happens, as confidentiality is provided externally.
                    >
                    > It's obvious that there's a 2x2 matrix of auth+crypto options here. If
                    > you're trying to be very flexible then you're probably interested in
                    > stopping the one possibility that could leak passwords - no-crypto
                    > while using insecure auth.

                    Correct. I was actually not aware that something like password, md5-*
                    etc was even a legitimate way of protecting yourself. I understand
                    the data channel is plain text, but the user and pass being hashed in
                    some way, I had assumed it would be trivial to crack, something akin
                    to base64. Good to know it is a lot more than that.

                    >>> I'm happy for
                    >>> mail clients to select the best mechanisms available for easy
                    >>> autoconfiguration, but it would be nice to have the ability to set
                    >>> them
                    >>> explicitly (for troubleshooting or security reasons).
                    >>>
                    >>> In any case, it's good practice to check this box if the server
                    >>> supports
                    >>> secure mechanisms, for a little extra protection beyond SSL/TLS.
                    >>
                    >> What more do I need to do in postfix cf files to support this
                    >> setting? Any
                    >> downsides as far as performance and load?
                    >
                    > This depends on what you want your security policy to be. One useful
                    > main.cf option is smtpd_tls_auth_only - when TLS is optional, it'll
                    > only offer authentication if the connection is encrypted. (obviously
                    > it's always safe to offer authentication if encryption is mandatory).
                    > The catch is that authentication isn't strictly handled by postfix.
                    > Your SASL backend (cyrus or dovecot) specifies what authentication
                    > protocols are offered; I believe this is because it's the SASL daemon
                    > that has to deal with the password backend, so it's the right place
                    > for that sort of policy. You can't offer CRAM-MD5 if the passwords are
                    > stored in a hashed form; postfix has no knowledge of the password
                    > storage, so authentication can't be handled in postfix (though sasl
                    > can be tweaked a little).

                    I have been playing with smtpd_tls_auth_only to ill results. I have
                    no setting in main.cf now, meaning it is defaulting to
                    smtpd_tls_auth_only = no

                    If I understand the docs:
                    "When TLS encryption is optional in the Postfix SMTP server, do
                    not announce or accept
                    SASL authentication over unencrypted connections."

                    I think I want this to "no" anyway, is that correct given my end goals
                    here? Or maybe I want this as "yes", and then over ride certain parts
                    in the master.cf?

                    >>>> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
                    >>>> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
                    >>>
                    >>> If you're not using client certificate authentication (and you
                    >>> probably
                    >>> aren't), delete those lines.
                    >>
                    >> Well now you threw me for a loop :) I am a small ISP, and I will
                    >> buy a
                    >> emailserver.company.example.com SSL cert. As it is now, in email
                    >> clients, I
                    >> get a box pop up asking me to approve my current self signed one as
                    >> a non
                    >> known untrusted authority. I just select accept always and move on.
                    >>
                    >> So removing those certs above just removes the certificate trust
                    >> issue, but
                    >> does not change any of the encryption methods I have going on? In
                    >> apache, I
                    >> can not enable SSL, as far as I know, without a cert. I was under
                    >> the
                    >> impression, if I want to offer SSL, I am going to need those certs?
                    >
                    > Correct, a paid-for cert will sidestep the trust issue for your users.
                    > It's the same here as it is in apache. Crypto certs are just "dumb
                    > data" - it's primarily key material, it doesn't affect how your crypto
                    > works, or how strong it is, etc.

                    Interesting, good to know. I have been mistaken then, in that I
                    thought the cert itself provided the public and private keys, that
                    were used as a basis for the encryption, sort of like a salt. Is what
                    you are saying is these just prove identity and trust, but do not in
                    any way create encryption?

                    > I think you misinterpreted that comment though. "If you're not using
                    > client certificate authentication, delete those lines". What was meant
                    > was, "if postfix isn't using certificates to authenticate ITSELF to
                    > other servers, delete these lines".

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

                    This tells me it is working on the MUA level. But are you also
                    saying, inbound SMTP connections from other MUA's also have to get
                    past these certs as well? And that a inbound server will depend on
                    their configs if they are to accept self-signed ones, and may even
                    have issues with genuine CA based ones as well?

                    What is the correct way to not use certs for MTA's, but to present one
                    to the MUA?

                    Perhaps I should just do as you say, which is not provide any cert. I
                    doubt a single one of my users wants to deal with them. Is it correct
                    they are gaining nothing other than proof I am who I say I am? SSL
                    and TLS will continue to work if I comment out those two lines?

                    > Postfix can talk to other MTAs
                    > with crypto as well, this is the `smtp_tls_security_level` setting -
                    > notice the "smtp_" prefix on the config options, it's not "smtpd_".

                    So if I remove the two above cert lines, then smtp_tls_security_level
                    which I have set to "may", no longer needs to be set, and could sit on
                    the default, or set to none? This is a setting for inbound and
                    possibly outbound MTA traffic, basic non auth'd port 25 stuff, this
                    gives the ability to 'credentialize' that traffic, but is not easily
                    supported?

                    > The thing is, you can do crypto with or without certs. A cert is just
                    > a combination of (optionally) signed identify data tied to key
                    > material. If you don't care about identities (and for MTA-to-MTA
                    > traffic on the public internet, we don't), you can negotiate an
                    > anonymous TLS session and everything works as you expect it should. By
                    > setting smtp_tls_cert_file (I think) you're telling postfix to
                    > negotiate a non-anonymous TLS session, which the other end may baulk
                    > on if it doesn't have a cert, or can't verify your cert's signer, or
                    > for any number of reasons.

                    I think I more or less reiterated what you are saying. Thanks. If
                    there are any other points of clarification, I would appreciate them.

                    >>>> smtpd_sasl_authenticated_header = yes
                    >>>> smtpd_sasl_exceptions_networks = $mynetworks
                    >>>> smtpd_sasl_local_domain = $myhostname
                    >>>> smtpd_sasl_path = private/auth
                    >>>> smtpd_sasl_security_options = noanonymous
                    >>>> smtpd_sasl_type = dovecot
                    >>>
                    >>> I'd probably leave these in main.cf, just to keep master.cf
                    >>> simple, but
                    >>> it's your choice. Also, you can probably drop
                    >>> smtpd_sasl_exceptions_networks, as it won't make sense if you
                    >>> disable
                    >>> SMTP AUTH on port 25 and require authentication on port 587.
                    >
                    > I agree with this suggestion. You can keep sane settings in main.cf,
                    > it's nicer to leave master.cf alone. You also *probably* don't need to
                    > define smtpd_sasl_exceptions_networks.

                    I took out smtpd_sasl_exceptions_networks and let it fall on the
                    defaults to no ill effects, thanks.

                    > An example from my config, if it helps.
                    >
                    > # we can allow relaying by forcing senders to authenticate first (by
                    > permit_sasl_authenticated in smtpd_recipient_restrictions)
                    > smtpd_sasl_auth_enable = yes
                    > smtpd_sasl_security_options = noanonymous <-- this is the default,
                    > BTW
                    > smtpd_tls_security_level = may <-- offer but don't require TLS
                    > broken_sasl_auth_clients = yes

                    Thanks, I have some minor diffs, since my initial plan was to be more
                    strict about port 25. However, depending on what I learn from new
                    dialogue, this may change.

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

                    > # client TLS parameters, forward mail via TLS if possible
                    > smtp_tls_security_level = may

                    I had this one already I believe.

                    > These parameters will apply to all smtpd processes
                    > (smtp,smtps,submission) in master.cf unless you override the specific
                    > settings there. You may choose to enforce crypto on port 587 with "-o
                    > smtpd_tls_security_level=encrypt" but it's not technically necessary.
                    > You'll usually add "-o smtpd_tls_wrappermode=yes" to the smtps
                    > definition to get "SSL" mode working. I've personally got "-o
                    > smtpd_client_restrictions=permit_sasl_authenticated,reject" for my
                    > submission port.

                    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?

                    Just in case:
                    alias_maps = hash:/opt/local/etc/postfix/aliases
                    biff = no
                    broken_sasl_auth_clients = yes
                    command_directory = /opt/local/sbin
                    config_directory = /opt/local/etc/postfix
                    daemon_directory = /opt/local/libexec/postfix
                    data_directory = /opt/local/var/lib/postfix
                    disable_vrfy_command = yes
                    mail_owner = _postfix
                    mailq_path = /opt/local/bin/mailq
                    message_size_limit = 0
                    mydestination = $myhostname, localhost.$mydomain,
                    localhost
                    myhostname = catalyst.example.com
                    mynetworks = 64.84.37.0/26
                    newaliases_path = /opt/local/bin/newaliases
                    queue_directory = /opt/local/var/spool/postfix
                    readme_directory = /opt/local/share/postfix/readme
                    sample_directory = /opt/local/share/postfix/sample
                    sendmail_path = /opt/local/sbin/sendmail
                    setgid_group = _postdrop
                    smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
                    smtp_tls_key_file = /opt/local/etc/ssl/private/
                    dovecot.pem
                    smtp_tls_security_level = may
                    smtp_tls_session_cache_database = btree:$data_directory/
                    smtp_tls_session_cache
                    smtpd_helo_required = yes
                    smtpd_recipient_restrictions = permit_mynetworks
                    permit_sasl_authenticated reject_unauth_destination permit
                    smtpd_sasl_authenticated_header = yes
                    smtpd_sasl_local_domain = $myhostname
                    smtpd_sasl_path = private/auth
                    smtpd_sasl_security_options = noanonymous
                    smtpd_sasl_type = dovecot
                    smtpd_tls_ask_ccert = yes
                    smtpd_tls_cert_file = /opt/local/etc/ssl/certs/postfix.pem
                    smtpd_tls_key_file = /opt/local/etc/ssl/private/
                    postfix.pem
                    smtpd_tls_loglevel = 0
                    smtpd_tls_received_header = yes
                    smtpd_tls_security_level = may
                    smtpd_tls_session_cache_database = btree:$data_directory/
                    smtpd_tls_session_cache
                    tls_random_source = dev:/dev/urandom
                    virtual_alias_maps = mysql:/opt/local/etc/postfix/mysql-
                    virtual-alias-maps.cf,mysql:/opt/local/etc/postfix/mysql-email2email.cf
                    virtual_gid_maps = static:5000
                    virtual_mailbox_base = /opt/local/var/vmail
                    virtual_mailbox_domains = mysql:/opt/local/etc/postfix/mysql-
                    virtual-mailbox-domains.cf
                    virtual_mailbox_maps = mysql:/opt/local/etc/postfix/mysql-
                    virtual-mailbox-maps.cf
                    virtual_minimum_uid = static:5000
                    virtual_transport = dovecot
                    virtual_uid_maps = static:5000

                    master.cf:
                    smtp inet n - n -
                    - smtpd
                    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

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

                    pickup fifo n - n 60
                    1 pickup
                    cleanup unix n - n -
                    0 cleanup
                    qmgr fifo n - n 300
                    1 qmgr
                    tlsmgr unix - - n 1000?
                    1 tlsmgr
                    rewrite unix - - n -
                    - trivial-rewrite
                    bounce unix - - n -
                    0 bounce
                    defer unix - - n -
                    0 bounce
                    trace unix - - n -
                    0 bounce
                    verify unix - - n -
                    1 verify
                    flush unix n - n 1000?
                    0 flush
                    proxymap unix - - n -
                    - proxymap
                    proxywrite unix - - n -
                    1 proxymap
                    smtp unix - - n -
                    - smtp
                    relay unix - - n -
                    - smtp
                    -o smtp_fallback_relay=
                    showq unix n - n -
                    - showq
                    error unix - - n -
                    - error
                    retry unix - - n -
                    - error
                    discard unix - - n -
                    - discard
                    local unix - n n -
                    - local
                    virtual unix - n n -
                    - virtual
                    lmtp unix - - n -
                    - lmtp
                    anvil unix - - n -
                    1 anvil
                    scache unix - - n -
                    1 scache

                    dovecot unix - n n -
                    - pipe
                    flags=DRhu user=_vmail:_vmail argv=/opt/local/libexec/dovecot/
                    deliver -d ${recipient}

                    --
                    Scott * If you contact me off list replace talklists@ with scott@ *
                  • Scott Haneda
                    Jorey, thanks for your email also. Sorry for the delay, but you and Barney have been hugely instrumental in getting me on track with this. ... I am in a bad
                    Message 9 of 16 , Apr 30, 2009
                    • 0 Attachment
                      Jorey, thanks for your email also. Sorry for the delay, but you and
                      Barney have been hugely instrumental in getting me on track with this.

                      On Apr 24, 2009, at 9:43 PM, Jorey Bump wrote:
                      > Scott Haneda wrote, at 04/24/2009 07:41 PM:
                      >> Thanks for this, this is getting me on track, comments interspersed
                      >> below...
                      >>
                      >> On Apr 24, 2009, at 6:51 AM, Jorey Bump wrote:
                      >>
                      >>> Scott Haneda wrote, at 04/24/2009 07:58 AM:
                      >>>
                      >>>> For port 587 submission, I want to offer SSL, TLS, and non
                      >>>> encrypted to
                      >>>> cover the users who will not want to change their settings.
                      >>>
                      >>> Use:
                      >>>
                      >>> -o smtpd_tls_security_level=may
                      >>> -o smtpd_tls_auth_only=no
                      >>>
                      >>> I think it's normally a bad idea not to enforce TLS on the
                      >>> submission
                      >>> port, but if you're using a secure mechanism and want to prevent
                      >>> weaker
                      >>> ones, add:
                      >>>
                      >>> -o smtpd_sasl_security_options=noanonymous,noplaintext
                      >>> -o smtpd_sasl_tls_security_options=noanonymous
                      >>
                      >> If you do not like a lack of TLS enforcement on the submission port
                      >> what
                      >> do you suggest for users who just do not care enough to use any TLS?
                      >
                      > I suggest they use it if they want to send mail. :)
                      >
                      > Since one of the purposes of the submission port is to support road
                      > warriors, I feel it should be as secure as possible and the entire
                      > communication should be encrypted.

                      I am in a bad spot in this regard, because of some of the faults of my
                      current email server. It is pushed a bit to move users to 587, but
                      the server does not support SSL/TLS. It would be very hard for me to
                      get them to all change their settings to use SSL/TLS. I would love to
                      make 587 the default secure port, I just do not thing I can put my
                      users in that situation.

                      If postfix can log in a way that I can tell what is going on, and over
                      time, I can make a call a day, and convert people over to TLS,
                      eventually I will flip this switch.

                      >> You let them work on port 25?
                      >
                      > In some cases, I allow the use of a secure mechanism without TLS on
                      > port
                      > 25. This protects the login, but not the message contents. I don't
                      > allow
                      > unencrypted plaintext logins.

                      I am leaning back on this idea again. Have to hash that out from the
                      standpoint of a proxy. I am just do not know if I gain anything by
                      putting all user MUA traffic on a non port 25 port. I know the proxy
                      tries to learn from users sending emails, and white list the
                      recipients, I do not know if that learning is port bound or not.

                      >> Glad you brought up webmail. I am going to use Roundcube, on the
                      >> same
                      >> machine, worst case, on a close machine, in the same subnet. Since I
                      >> have the nynetworks setting set to allow mail, all should be ok? I
                      >> do
                      >> not want to deal with AUTH for SMTP in webmail, it is going to be
                      >> local
                      >> to local, I see no point in securing that part. Is that correct?
                      >
                      > It's up to you. I use SMTP AUTH for webmail, partly because it
                      > provides
                      > better logging for troubleshooting.

                      Good point. What webmail are you using? Does it globally SMTP AUTH
                      via a config file and a smtp account, or is each user login it's own
                      SMTP AUTH case, which is where you are picking up the logging data
                      specific to the sender under that specific account?

                      >> I am confused about your comments about 465. Reading it makes me
                      >> think
                      >> that 465 is sort of a last resort option. I am not understanding the
                      >> difference between SSL and TLS. If I was setting up a email
                      >> client, and
                      >> could use TLS versus SSL, my logic would be to use SSL, it seems the
                      >> better option, but I do not know why.
                      >>
                      >> Are you saying SSL email is the lesser of the options, and I should
                      >> use
                      >> TLS when I can?
                      >
                      > I'm saying that smtps (wrapper mode on port 465) is deprecated in
                      > favor
                      > of STARTTLS on ports 25 or 587.

                      Good to know. For some reason, SSL sounds the better way to go in my
                      head, and in the heads of a lot of people I talk to. Strange, because
                      when I think about it, how it sends out a STARTTLS, and moves on from
                      there, that seems a better policy, less prone to problems as well.

                      >> Do you know how this related to Apple Mail? There is no setting in
                      >> the
                      >> SMTP section to opt for SSL versus TLS? "Use SSL" is the only
                      >> checkbox
                      >> there is. I take it if you do not select that, it will use TLS if it
                      >> can, but do so in a invisible way?
                      >
                      > Default autoconfiguration appears to use ports 25, 465, & 587 and
                      > SSL if
                      > detected. The server I tested supports all of these and the mechanism
                      > list is PLAIN LOGIN CRAM-MD5 DIGEST-MD5. After autoconfiguration,
                      > Apple
                      > Mail used STARTTLS and the PLAIN mechanism on port 25 to send a
                      > message.

                      Are there are good reasons to support PLAIN and LOGIN and PASSWORD? I
                      have told all our users to use MD5 Challenge Response. Maybe I would
                      aid Apple Mail in figuring out which to pick, it seems to always fall
                      back on PASSWORD iirc. Perhaps other desktop clients do not support
                      md5 mechanisms.

                      > I assume it follows an algorithm to determine a fallback strategy for
                      > trying the other ports if its first choice is not available.
                      > Although I
                      > would have preferred it start with port 587, the choice it made is
                      > acceptably secure. If you only offer port 587, it probably won't pose
                      > any problems (as long as it remembers the other ports are
                      > unavailable).

                      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.

                      >> It probably is this setting that has lead me down the road of
                      >> thinking
                      >> SSL is better, as Apple Mail offers what appears to be no
                      >> encryption, or
                      >> SSL, there is no implicit TLS setting.
                      >>
                      >> Looking at Outlook settings:
                      >> http://www.math.uwaterloo.ca/mfcf/announcements/images/outlook2.png
                      >> It appears in the same case, SSL is going to be selected, as the
                      >> better
                      >> way, I see no way to use TLS. Maybe I am not groking any of this,
                      >> any
                      >> brief explanation of this sure would help.
                      >
                      > Don't make assumptions based on the nonstandardized vocabulary found
                      > in
                      > MUAs. In this context, "SSL" is meaningless and interchangeable with
                      > "TLS" (technically, SSL evolved into TLS). STARTTLS is preferable to
                      > smtps (SSL wrapper mode on port 465). But if you need to support
                      > smtps
                      > for legacy clients, go ahead.

                      Thanks, that explains where some of my confusion comes from, in that
                      the terms are interchangeable in some contexts.

                      >>> In any case, it's good practice to check this box if the server
                      >>> supports
                      >>> secure mechanisms, for a little extra protection beyond SSL/TLS.
                      >>
                      >> What more do I need to do in postfix cf files to support this
                      >> setting?
                      >> Any downsides as far as performance and load?
                      >
                      > 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?

                      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?

                      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?

                      >>>> smtp_tls_cert_file = /opt/local/etc/ssl/certs/dovecot.pem
                      >>>> smtp_tls_key_file = /opt/local/etc/ssl/private/dovecot.pem
                      >>>
                      >>> If you're not using client certificate authentication (and you
                      >>> probably
                      >>> aren't), delete those lines.
                      >>
                      >> Well now you threw me for a loop :) I am a small ISP, and I will
                      >> buy a
                      >> emailserver.company.example.com SSL cert. As it is now, in email
                      >> clients, I get a box pop up asking me to approve my current self
                      >> signed
                      >> one as a non known untrusted authority. I just select accept
                      >> always and
                      >> move on.
                      >>
                      >> So removing those certs above just removes the certificate trust
                      >> issue,
                      >> but does not change any of the encryption methods I have going on?
                      >> In
                      >> apache, I can not enable SSL, as far as I know, without a cert. I
                      >> was
                      >> under the impression, if I want to offer SSL, I am going to need
                      >> those
                      >> certs?
                      >
                      > No, you're thinking of smtpd_tls_*_file, which you still need. I'm
                      > suggesting you might not need smtp_tls_*_file, which is used when
                      > postfix is the client to other systems.

                      Slowly beginning to grasp this, thanks for the *'s, this is making a
                      lot more sense.

                      Thanks again, see my one previous email if you need a postconf dump
                      for any reason.
                      --
                      Scott * If you contact me off list replace talklists@ with scott@ *
                    • 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.