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

Concurency limits

Expand Messages
  • James Cloos
    I working with an application which collects data and emails me the results. Reading it in a mailinglist-like fashion is optimal for me. It can generate a
    Message 1 of 7 , Jul 7, 2014
      I working with an application which collects data and emails me the
      results. Reading it in a mailinglist-like fashion is optimal for me.

      It can generate a large number of mails in a short time, so I'm trying
      to limit how many concurrent sockets pf on that box opens with my MXs.

      Each subset of messages has a different +extension in the localpart.

      Ideally, I'd like it to open one to each of the equal-priority MXs,
      starttls with each, and dump the mails between them until the queue
      drains.

      I tried setting:

      smtp_destination_concurrency_limit = 2
      smtp_connection_cache_destinations = jhcloos.com

      but still get as many Verified TLS connection established messages in
      the logs as status=sent lines.

      And netstat agrees that many sockets are used in parallel.

      Do any of:

      smtp_dns_support_level=dnssec
      smtp_use_tls=yes
      smtp_enforce_tls=yes
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      smtp_tls_security_level = dane
      smtp_tls_note_starttls_offer = yes

      interfere with concurrency limits?

      That box has pf 2.11.1.

      -JimC
      --
      James Cloos <cloos@...> OpenPGP: 0x997A9F17ED7DAEA6
    • lists@rhsoft.net
      ... that is nonsense and don t say anyhting about *concurrent* connections
      Message 2 of 7 , Jul 7, 2014
        Am 08.07.2014 00:17, schrieb James Cloos:
        > I working with an application which collects data and emails me the
        > results. Reading it in a mailinglist-like fashion is optimal for me.
        >
        > It can generate a large number of mails in a short time, so I'm trying
        > to limit how many concurrent sockets pf on that box opens with my MXs.
        >
        > Each subset of messages has a different +extension in the localpart.
        >
        > Ideally, I'd like it to open one to each of the equal-priority MXs,
        > starttls with each, and dump the mails between them until the queue
        > drains.
        >
        > I tried setting:
        >
        > smtp_destination_concurrency_limit = 2
        > smtp_connection_cache_destinations = jhcloos.com
        >
        > but still get as many Verified TLS connection established messages in
        > the logs as status=sent lines

        that is nonsense and don't say anyhting about *concurrent* connections
      • Viktor Dukhovni
        ... What sort of limit did you have in mind. The default is 20 per nexthop domain (per recipient when the transports recipient concurrency is 1). Split
        Message 3 of 7 , Jul 7, 2014
          On Mon, Jul 07, 2014 at 06:17:05PM -0400, James Cloos wrote:

          > It can generate a large number of mails in a short time, so I'm trying
          > to limit how many concurrent sockets pf on that box opens with my MXs.

          What sort of limit did you have in mind. The default is 20 per
          nexthop domain (per recipient when the transports recipient
          concurrency is 1). Split randomly across the domain's MX hosts.
          This is unlikely to be a problem.

          > Each subset of messages has a different +extension in the localpart.

          This would only matter if you set the transport's recipient
          concurrency to 1. Then mail is queued by recipient, rather than
          by domain.

          > Ideally, I'd like it to open one to each of the equal-priority MXs,
          > starttls with each, and dump the mails between them until the queue
          > drains.

          If you set the concurrency limit to equal the MX host count, you
          get roughly this on average, but each message is delivered over a
          separate connection, and the connection distribution is random,
          not round-robin.

          > I tried setting:
          >
          > smtp_destination_concurrency_limit = 2
          > smtp_connection_cache_destinations = jhcloos.com

          TLS and connection caching are mutually exclusive.

          > but still get as many Verified TLS connection established messages in
          > the logs as status=sent lines.

          See above. However, at most two delivery agents have open connections
          at any time with the above settings.

          > Do any of:
          >
          > smtp_use_tls=yes
          > smtp_enforce_tls=yes

          These are obsolete, and should be removed from main.cf. They are
          only used when smtp_tls_security_level is empty.

          > smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
          > smtp_tls_security_level = dane

          This turns on opportunistic DANE TLS.

          > smtp_tls_note_starttls_offer = yes

          This is not needed when TLS is on by default.

          > interfere with concurrency limits?

          No, but TLS and connection caching are mutually exclusive (for destinations
          that support STARTTLS, non-TLS destinations are still cached).

          --
          Viktor.
        • James Cloos
          ... VD What sort of limit did you have in mind. The default is 20 per VD nexthop domain (per recipient when the transports recipient VD concurrency is 1).
          Message 4 of 7 , Jul 7, 2014
            >>>>> "VD" == Viktor Dukhovni <postfix-users@...> writes:

            VD> What sort of limit did you have in mind. The default is 20 per
            VD> nexthop domain (per recipient when the transports recipient
            VD> concurrency is 1). Split randomly across the domain's MX hosts.
            VD> This is unlikely to be a problem.

            One or two sockets per MX.

            >> Each subset of messages has a different +extension in the localpart.

            VD> This would only matter if you set the transport's recipient
            VD> concurrency to 1. Then mail is queued by recipient, rather than
            VD> by domain.

            That was my impression, but just in case I read it wrong it seemed
            useful to note the fact.

            >> Ideally, I'd like it to open one to each of the equal-priority MXs,
            >> starttls with each, and dump the mails between them until the queue
            >> drains.

            VD> If you set the concurrency limit to equal the MX host count, you
            VD> get roughly this on average, but each message is delivered over a
            VD> separate connection, and the connection distribution is random,
            VD> not round-robin.

            That is exactly what I attempted with the below configs.

            >> smtp_destination_concurrency_limit = 2
            >> smtp_connection_cache_destinations = jhcloos.com

            VD> TLS and connection caching are mutually exclusive.

            >> but still get as many Verified TLS connection established messages in
            >> the logs as status=sent lines.

            VD> See above. However, at most two delivery agents have open connections
            VD> at any time with the above settings.

            I got more than that. The vendor saw more than a dozen concurrent
            outgoings before I added the above two configs. Which was a problem,
            until I explained that I was only sending to myself.

            And while testing, I saw more ESTABLISHED at a time, too. Even after
            adding the above two lines.

            >> Do any of:
            >>
            >> smtp_use_tls=yes
            >> smtp_enforce_tls=yes

            VD> These are obsolete, and should be removed from main.cf. They are
            VD> only used when smtp_tls_security_level is empty.

            Cool.

            >> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
            >> smtp_tls_security_level = dane

            VD> This turns on opportunistic DANE TLS.

            Intentionally. I like using that better than smtp_tls_policy_maps,
            given that I publish tlsa for my MXs.

            >> smtp_tls_note_starttls_offer = yes

            VD> This is not needed when TLS is on by default.

            Like the use_tls, it was copied from old configs which have been
            incrementally updated.

            >> interfere with concurrency limits?

            VD> No, but TLS and connection caching are mutually exclusive (for
            VD> destinations that support STARTTLS, non-TLS destinations are still
            VD> cached).

            Any chance of changing that in future versions?

            There should be no reason to have to use separate connections per
            message just because tls is used.

            -JimC
            --
            James Cloos <cloos@...> OpenPGP: 0x997A9F17ED7DAEA6
          • James Cloos
            ... ln that is nonsense and don t say anyhting about *concurrent* connections I don t know what you think is nonsense. The MXs also show one mail per socket,
            Message 5 of 7 , Jul 7, 2014
              >>>>> "ln" == lists@rhsoft net <lists@...> writes:

              >> but still get as many Verified TLS connection established messages in
              >> the logs as status=sent lines

              ln> that is nonsense and don't say anyhting about *concurrent* connections

              I don't know what you think is nonsense.

              The MXs also show one mail per socket, and as I noted elsewhere netstat
              shows several concurrent ESTABLISHED to each MX.

              -JimC
              --
              James Cloos <cloos@...> OpenPGP: 0x997A9F17ED7DAEA6
            • Viktor Dukhovni
              ... Postfix has no per-MX concurrency limits, only per-destination limits, which split across the MX hosts somewhat randomly. At times some MX hosts may see
              Message 6 of 7 , Jul 7, 2014
                On Mon, Jul 07, 2014 at 08:38:02PM -0400, James Cloos wrote:

                > VD> What sort of limit did you have in mind. The default is 20 per
                > VD> nexthop domain (per recipient when the transports recipient
                > VD> concurrency is 1). Split randomly across the domain's MX hosts.
                > VD> This is unlikely to be a problem.
                >
                > One or two sockets per MX.

                Postfix has no per-MX concurrency limits, only per-destination
                limits, which split across the MX hosts somewhat randomly. At times
                some MX hosts may see more than their "fair" share of connections.
                Subject to the usual statistical considerations.

                > VD> If you set the concurrency limit to equal the MX host count, you
                > VD> get roughly this on average, but each message is delivered over a
                > VD> separate connection, and the connection distribution is random,
                > VD> not round-robin.
                >
                > That is exactly what I attempted with the below configs.
                >
                > >> smtp_destination_concurrency_limit = 2
                > >> smtp_connection_cache_destinations = jhcloos.com

                These settings require a "postfix reload" to update the queue
                manager configuration.

                The cache setting is irrelevant given TLS support. The concurrency
                limit is however enforced, per nexthop destination. Note, that
                when a single MX host supports multiple MX domains, it will see
                that many connections per domain.

                Without detailed log analysis, and relevant transport configuration
                details, your anecdotal observations with netstat are not useful.

                > VD> No, but TLS and connection caching are mutually exclusive (for
                > VD> destinations that support STARTTLS, non-TLS destinations are still
                > VD> cached).
                >
                > Any chance of changing that in future versions?

                Not likely in 2.12, this is a difficult problem.

                > There should be no reason to have to use separate connections per
                > message just because tls is used.

                Migrating SSL encrypted connections between processes is rather
                difficult. We'd need a reverse TLS proxy in Postfix that handles
                multiple outgoing TLS sessions in a single process, and mechanisms
                to push per-connection policy to the proxy and query the resulting
                security state. I don't see this happening in 2.12.

                --
                Viktor.
              • lists@rhsoft.net
                ... as many Verified TLS connection established messages in the logs as status=sent lines is nonsense - what has that do do with concurency limits ... and
                Message 7 of 7 , Jul 8, 2014
                  Am 08.07.2014 02:40, schrieb James Cloos:
                  >>>>>> "ln" == lists@rhsoft net <lists@...> writes:
                  >
                  >>> but still get as many Verified TLS connection established messages in
                  >>> the logs as status=sent lines
                  >
                  > ln> that is nonsense and don't say anyhting about *concurrent* connections
                  >
                  > I don't know what you think is nonsense.

                  "as many Verified TLS connection established messages in the logs as
                  status=sent lines" is nonsense - what has that do do with
                  "concurency limits"

                  > The MXs also show one mail per socket, and as I noted elsewhere netstat
                  > shows several concurrent ESTABLISHED to each MX

                  and this MX servers are very likely MX for several domains
                  expected behavior -> per-destination limits
                Your message has been successfully submitted and would be delivered to recipients shortly.