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

recipient_bcc_maps not working

Expand Messages
  • lkml@ds.gauner.org
    Hi, I ve configured recipient_bcc_maps to capture outgoing mail to some domains to debug delivery issues, i.e. some senders can t send mails to yahoo and yahoo
    Message 1 of 4 , Feb 2, 2011
    • 0 Attachment
      Hi,

      I've configured recipient_bcc_maps to capture outgoing mail to some
      domains to debug delivery issues, i.e. some senders can't send mails to
      yahoo and yahoo wants the full body. So I thought I could just capture
      these mails using recipient_bcc_maps and later forward them to yahoo.

      I've double checked the path and type of the maps and ran postmap after
      each modicication.

      The problem is that recipient_bcc_maps seems to have no effect on the
      system under investigation. On other mailservers it does work very well.

      The most notable difference between this mailserver and other I have
      tested is that this one uses several outgoing IPs via multiple transports
      in the master.cf and a "FILTER transportX:" rule in
      check_recipient_access. Maybe this interferes with recipient_bcc_maps or
      I've forgot something else.

      Best Regards,
      Dominik Schulz
    • Wietse Venema
      ... Please follow instructions in the mailing list welcome message: TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see
      Message 2 of 4 , Feb 2, 2011
      • 0 Attachment
        lkml@...:
        > Hi,
        >
        > I've configured recipient_bcc_maps to capture outgoing mail to some
        > domains to debug delivery issues, i.e. some senders can't send mails to
        > yahoo and yahoo wants the full body. So I thought I could just capture
        > these mails using recipient_bcc_maps and later forward them to yahoo.
        >
        > I've double checked the path and type of the maps and ran postmap after
        > each modicication.
        >
        > The problem is that recipient_bcc_maps seems to have no effect on the
        > system under investigation. On other mailservers it does work very well.
        >
        > The most notable difference between this mailserver and other I have
        > tested is that this one uses several outgoing IPs via multiple transports
        > in the master.cf and a "FILTER transportX:" rule in
        > check_recipient_access. Maybe this interferes with recipient_bcc_maps or
        > I've forgot something else.

        Please follow instructions in the mailing list welcome message:

        TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

        TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

        Thank you for using Postfix.
      • lkml@ds.gauner.org
        ... domains to debug delivery issues, i.e. some senders can t send mails to yahoo and yahoo wants the full body. So I thought I could just capture these mails
        Message 3 of 4 , Feb 3, 2011
        • 0 Attachment
          > lkml@...:
          >> I've configured recipient_bcc_maps to capture outgoing mail to some
          domains to debug delivery issues, i.e. some senders can't send mails to
          yahoo and yahoo wants the full body. So I thought I could just capture
          these mails using recipient_bcc_maps and later forward them to yahoo.
          >>
          >> I've double checked the path and type of the maps and ran postmap after
          each modicication.
          >>
          >> The problem is that recipient_bcc_maps seems to have no effect on the
          system under investigation. On other mailservers it does work very
          well.
          >>
          >> The most notable difference between this mailserver and other I have
          tested is that this one uses several outgoing IPs via multiple
          >> transports
          >> in the master.cf and a "FILTER transportX:" rule in
          >> check_recipient_access. Maybe this interferes with recipient_bcc_maps
          or I've forgot something else.
          >
          > Please follow instructions in the mailing list welcome message:
          > TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

          I'm sorry. Below is the information you requested. I've seen no traces in
          the logs, so I've omited them for now. If you like I can supply them
          later.

          We are using Postfix 2.7.1 from Debian squeeze.

          Below is the output from postconf -n, 'egrep -v "^#"
          /etc/postfix/master.cf | egrep -v "^$"' and the relevant maps.

          --- main.cf: ---
          alias_database = hash:/etc/aliases
          alias_maps = hash:/etc/aliases
          append_dot_mydomain = no
          biff = no
          config_directory = /etc/postfix
          debug_peer_list = 127.0.0.1
          header_checks = pcre:/etc/postfix/header-checks.pcre
          inet_interfaces = all
          mydestination = mailout-X, mailout-X.domain.tld, localhost
          myhostname = mailout-X.domain.tld
          mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
          myorigin = /etc/mailname
          readme_directory = no
          smtpd_banner = $myhostname ESMTP $mail_name
          smtpd_recipient_restrictions = check_recipient_access
          pcre:/etc/postfix/random-recipient.pcre, check_sender_access
          pcre:/etc/postfix/random-sender.pcre,
          permit_mynetworks,reject_unauth_destination
          smtpd_use_tls = no
          recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
          --- end of main.cf ---

          --- /etc/postfix/recipient_bcc ---
          @... archive@mailout-X
          @... archive@mailout-X
          @... archive@mailout-X
          --- end of /etc/postfix/recipient_bcc ---

          --- /etc/postfix/random-recipient.pcre ---
          /^([a-z0-9])(.*)@(.*)/ FILTER smtpout$1:
          --- end of /etc/postfix/random-recipient.pcre ---

          /etc/postfix/random-sender.pcre is currently empty.

          --- master.cf: ---
          egrep -v "^#" master.cf | egrep -v "^$"
          smtp inet n - - - - smtpd
          pickup fifo n - - 60 1 pickup
          cleanup unix n - - - 0 cleanup
          qmgr fifo n - n 300 1 qmgr
          tlsmgr unix - - - 1000? 1 tlsmgr
          rewrite unix - - - - - trivial-rewrite
          bounce unix - - - - 0 bounce
          defer unix - - - - 0 bounce
          trace unix - - - - 0 bounce
          verify unix - - - - 1 verify
          flush unix n - - 1000? 0 flush
          proxymap unix - - n - - proxymap
          proxywrite unix - - n - 1 proxymap
          smtp unix - - - - - smtp
          -o smtp_helo_name=HOSTNAME.DOMAIN.TLD
          -o smtp_bind_address=DDD.DDD.DDD.DDD
          smtpout0 unix - - - - - smtp
          -o smtp_helo_name=HOSTNAME.DOMAIN.TLD
          -o smtp_bind_address=DDD.DDD.DDD.DDD
          [smtpout1 .. smtpout9, smtpouta ... smtpoutz with a number of diffent IPs
          and helo names]
          relay unix - - - - - smtp
          -o smtp_fallback_relay=
          showq unix n - - - - showq
          error unix - - - - - error
          retry unix - - - - - error
          discard unix - - - - - discard
          local unix - n n - - local
          virtual unix - n n - - virtual
          lmtp unix - - - - - lmtp
          anvil unix - - - - 1 anvil
          scache unix - - - - 1 scache
          maildrop unix - n n - - pipe
          flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
          --- end of master.cf ---

          Best Regards,
          Dominik Schulz
        • Jeroen Geilman
          ... Sadly, the LOGS are the most essential part of the information you could provide. Be sure to include as much of one or two messages as possible, from the
          Message 4 of 4 , Feb 3, 2011
          • 0 Attachment
            On 2/3/11 9:18 AM, lkml@... wrote:
            >> lkml@...:
            >>> I've configured recipient_bcc_maps to capture outgoing mail to some
            > domains to debug delivery issues, i.e. some senders can't send mails to
            > yahoo and yahoo wants the full body. So I thought I could just capture
            > these mails using recipient_bcc_maps and later forward them to yahoo.
            >>> I've double checked the path and type of the maps and ran postmap after
            > each modicication.
            >>> The problem is that recipient_bcc_maps seems to have no effect on the
            > system under investigation. On other mailservers it does work very
            > well.
            >>> The most notable difference between this mailserver and other I have
            > tested is that this one uses several outgoing IPs via multiple
            >>> transports
            >>> in the master.cf and a "FILTER transportX:" rule in
            >>> check_recipient_access. Maybe this interferes with recipient_bcc_maps
            > or I've forgot something else.
            >> Please follow instructions in the mailing list welcome message:
            >> TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
            > I'm sorry. Below is the information you requested. I've seen no traces in
            > the logs, so I've omited them for now.

            Sadly, the LOGS are the most essential part of the information you could
            provide.
            Be sure to include as much of one or two messages as possible, from the
            point they enter the postfix system until they exit.

            > If you like I can supply them
            > later.
            >
            > We are using Postfix 2.7.1 from Debian squeeze.
            >
            > Below is the output from postconf -n, 'egrep -v "^#"
            > /etc/postfix/master.cf | egrep -v "^$"' and the relevant maps.
            >
            > --- main.cf: ---
            > alias_database = hash:/etc/aliases
            > alias_maps = hash:/etc/aliases
            > append_dot_mydomain = no
            > biff = no
            > config_directory = /etc/postfix
            > debug_peer_list = 127.0.0.1
            > header_checks = pcre:/etc/postfix/header-checks.pcre
            > inet_interfaces = all
            > mydestination = mailout-X, mailout-X.domain.tld, localhost
            > myhostname = mailout-X.domain.tld
            > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
            > myorigin = /etc/mailname
            > readme_directory = no
            > smtpd_banner = $myhostname ESMTP $mail_name
            > smtpd_recipient_restrictions = check_recipient_access
            > pcre:/etc/postfix/random-recipient.pcre, check_sender_access
            > pcre:/etc/postfix/random-sender.pcre,
            > permit_mynetworks,reject_unauth_destination
            > smtpd_use_tls = no
            > recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
            > --- end of main.cf ---
            >
            > --- /etc/postfix/recipient_bcc ---
            > @... archive@mailout-X
            > @... archive@mailout-X
            > @... archive@mailout-X
            > --- end of /etc/postfix/recipient_bcc ---
            >
            > --- /etc/postfix/random-recipient.pcre ---
            > /^([a-z0-9])(.*)@(.*)/ FILTER smtpout$1:

            This seems unfortunate.
            Dividing work over multiple files/directories/processes usually works
            best when you start at the most-significant end of the data, but email
            addresses aren't divided evenly across the possibilities.
            The first letter of email addresses will follow the normal incidence of
            letter occurence, with a strong bias towards e, r, s, n etc (in English,
            anyway).

            A number as the first character of an address will be rare verging on
            non-occurring; this means up to 25% of these outputs will be used less
            than 1% of the time, making it an unbalanced load balancing mechanism.

            I would look into some sort of hashing method instead.


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