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

sender_bcc_maps and performance

Expand Messages
  • Rocco Scappatura
    Hello, I have enabled sender_bcc_maps in my main.cf. The lookup file has just 2 entries. I have noticed that the number of message in active queue grews as
    Message 1 of 3 , Jul 1 5:48 AM
    • 0 Attachment
      Hello,

      I have enabled "sender_bcc_maps" in my main.cf. The lookup file has just
      2 entries.

      I have noticed that the number of message in active queue grews as soon
      as I enable this feature.

      Is it so expensive? I otherwise can't figure out why active queues
      grows. Infact, I have verified that no configuration error are in mail
      log.

      rocsca
    • Victor Duchovni
      ... What fraction of your traffic is sent by these 2 entries. Do you have content filters downstream of the cleanup service that adds the bcc addresses? Report
      Message 2 of 3 , Jul 1 10:01 AM
      • 0 Attachment
        On Wed, Jul 01, 2009 at 02:48:00PM +0200, Rocco Scappatura wrote:

        > Hello,
        >
        > I have enabled "sender_bcc_maps" in my main.cf. The lookup file has just
        > 2 entries.

        What fraction of your traffic is sent by these 2 entries. Do you have
        content filters downstream of the cleanup service that adds the bcc
        addresses? Report your configuration:

        http://www.postfix.org/DEBUG_README.html#mail

        > I have noticed that the number of message in active queue grews as soon
        > as I enable this feature.

        Your observations are flawed, this processing happens before the message
        enters the active queue, so more latency upstream would actually reduce
        the size of the active queue unless you significantly increase the
        number of output messages per input message, which suggests a misconfigured
        content filter or similar.

        --
        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.
      • Rocco Scappatura
        Thanks Victor, ... A neglegible one. Yes, I have set up a content filter (amavisd-new). Anyway, here is my postconf output: alias_maps = hash:/etc/aliases
        Message 3 of 3 , Jul 2 1:28 AM
        • 0 Attachment
          Thanks Victor,

          >
          > On Wed, Jul 01, 2009 at 02:48:00PM +0200, Rocco Scappatura wrote:
          >
          > > Hello,
          > >
          > > I have enabled "sender_bcc_maps" in my main.cf. The lookup file has
          > just
          > > 2 entries.
          >
          > What fraction of your traffic is sent by these 2 entries. Do you have
          > content filters downstream of the cleanup service that adds the bcc
          > addresses? Report your configuration:
          >
          > http://www.postfix.org/DEBUG_README.html#mail
          >

          A neglegible one. Yes, I have set up a content filter (amavisd-new).
          Anyway, here is my postconf output:

          alias_maps = hash:/etc/aliases
          anvil_rate_time_unit = 60s
          bounce_size_limit = 1
          command_directory = /usr/sbin
          config_directory = /etc/postfix
          content_filter = smtp-amavis:[127.0.0.1]:10024
          daemon_directory = /usr/libexec/postfix
          debug_peer_level = 2
          default_process_limit = 150
          html_directory = no
          inet_interfaces = $myhostname, localhost
          local_recipient_maps = unix:passwd.byname $alias_maps
          mail_owner = postfix
          mail_spool_directory = /var/spool/mail
          mailq_path = /usr/bin/mailq
          manpage_directory = /usr/local/man
          message_size_limit = 35840000
          minimal_backoff_time = 1800s
          mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
          mydomain = av2.sttspa.it
          myhostname = av2.sttspa.it
          mynetworks = /etc/postfix/relayzahra2
          myorigin = $mydomain
          newaliases_path = /usr/bin/newaliases
          proxy_read_maps = $local_recipient_maps $mydestination
          $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
          $virtual_mailbox_domains $relay_recipient_maps $relay_domains
          $canonical_maps $sender_canonical_maps $recipient_canonical_maps
          $relocated_maps $transport_maps $mynetworks
          proxy:mysql:/etc/postfix/mysql-check-recipient-access.cf
          proxy:mysql:/etc/postfix/mysql-check-client-access.cf
          proxy:mysql:/etc/postfix/mysql-check-sender-access.cf
          proxy:mysql:/etc/postfix/mysql-relay-recipients.cf
          proxy:mysql:/etc/postfix/mysql-transport.cf
          proxy:mysql:/etc/postfix/mysql-check-client-filter-access.cf
          queue_directory = /var/spool/postfix
          readme_directory = no
          relay_domains = proxy:mysql:/etc/postfix/mysql-relay-domains.cf
          relay_recipient_maps =
          proxy:mysql:/etc/postfix/mysql-relay-recipients.cf
          sample_directory = /etc/postfix
          sender_bcc_maps = hash:/etc/postfix/sender_bcc
          sendmail_path = /usr/sbin/sendmail
          setgid_group = postdrop
          smtp_connect_timeout = 30s
          smtp_discard_ehlo_keyword_address_maps =
          hash:/etc/postfix/mta_workarounds
          smtpd_banner = $myhostname
          smtpd_client_connection_count_limit = 50
          smtpd_client_connection_rate_limit = 100
          smtpd_client_event_limit_exceptions = <list of IPs>
          smtpd_client_message_rate_limit = 60
          smtpd_client_recipient_rate_limit = 250
          smtpd_client_restrictions = check_client_access
          proxy:mysql:/etc/postfix/mysql-check-client-filter-access.cf
          smtpd_end_of_data_restrictions =
          smtpd_helo_restrictions =
          smtpd_recipient_restrictions = check_client_access
          proxy:mysql:/etc/postfix/mysql-check-client-access.cf
          permit_mynetworks permit_sasl_authenticated
          reject_unauth_destination reject_non_fqdn_sender
          reject_non_fqdn_recipient reject_unlisted_sender
          reject_unlisted_recipient reject_unknown_sender_domain
          reject_invalid_hostname reject_rbl_client zen.spamhaus.org
          reject_rbl_client list.dsbl.org
          smtpd_sasl_auth_enable = yes
          smtpd_sender_restrictions = check_sender_access
          proxy:mysql:/etc/postfix/mysql-check-sender-access.cf
          check_recipient_access
          proxy:mysql:/etc/postfix/mysql-check-sender-access.cf
          check_recipient_access
          proxy:mysql:/etc/postfix/mysql-check-recipient-access.cf
          strict_rfc821_envelopes = yes
          transport_maps = proxy:mysql:/etc/postfix/mysql-transport.cf
          unknown_local_recipient_reject_code = 550
          unverified_recipient_reject_code = 550

          > > I have noticed that the number of message in active queue grews as
          > soon
          > > as I enable this feature.
          >
          > Your observations are flawed, this processing happens before the
          > message
          > enters the active queue, so more latency upstream would actually
          reduce
          > the size of the active queue unless you significantly increase the
          > number of output messages per input message, which suggests a
          > misconfigured
          > content filter or similar.

          OK. I have applied configuration updating during a congested moment.. I
          fear that this has increased congestion as result.

          Then I have rolled back modifications and all (slowly) have returned to
          work normally.

          Finally, I have applied again configuration modification (which uses
          'sender_bcc_maps') yesterday night and tomorrow all works fine without
          (at least at the moment) active queue congestion.

          What it could be happen?

          Thanks,

          rocsca
        Your message has been successfully submitted and would be delivered to recipients shortly.