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

/usr/sbin/sendmail requeue and address expansion

Expand Messages
  • kj
    Hi guys, I m chasing my tail on this one. The setup is pretty simple virtual hosting, with virtual_alias_maps in a file virtuals which works fine, except
    Message 1 of 7 , Feb 26, 2009
    • 0 Attachment
      Hi guys,

      I'm chasing my tail on this one. The setup is pretty simple virtual
      hosting, with virtual_alias_maps in a file 'virtuals' which works fine,
      except for one line:

      bob@... bob, john, dave

      When sending a mail to bob@..., bob receives one copy of the
      mail, but john and dave each receives two. I understand the problem:
      postfix does the recipient expansion, sends it off to spamassassin.
      Spamassassin requeues the mail via the sendmail binary, so postfix
      treats it as a new mail.

      The log goes something like this (I separated the before and after parts
      for easier reading):

      Feb 26 13:26:24 mail postfix/smtpd[21425]: connect from
      mx1.some_host.com[XXX.xxx.XXX.xxx]
      Feb 26 13:26:24 mail postfix/smtpd[21425]: E0C6F9614DC:
      client=mx1.some_host.com[XXX.xxx.XXX.xxx]
      Feb 26 13:26:24 mail postfix/cleanup[21427]: E0C6F9614DC:
      message-id=<1235651181.6478.13.camel@kula>
      Feb 26 13:26:24 mail postfix/qmgr[23052]: E0C6F9614DC:
      from=<peter@some_host.com>, size=1560, nrcpt=3 (queue active)
      Feb 26 13:26:24 mail postfix/smtpd[21425]: disconnect from
      mx1.some_host.com[XXX.xxx.XXX.xxx]
      Feb 26 13:26:29 mail postfix/pipe[21354]: E0C6F9614DC:
      to=<john@...>, orig_to=<bob@...>, relay=spamassassin,
      delay=4.9, delays=0.17
      /0/0/4.7, dsn=2.0.0, status=sent (delivered via spamassassin service)
      Feb 26 13:26:29 mail postfix/pipe[21354]: E0C6F9614DC:
      to=<bob@...>, relay=spamassassin, delay=4.9,
      delays=0.17/0/0/4.7, dsn=2.0.0, status=sen
      t (delivered via spamassassin service)
      Feb 26 13:26:29 mail postfix/pipe[21354]: E0C6F9614DC:
      to=<dave@...>, orig_to=<bob@...>, relay=spamassassin,
      delay=4.9, delays=0.17/
      0/0/4.7, dsn=2.0.0, status=sent (delivered via spamassassin service)
      Feb 26 13:26:29 mail postfix/qmgr[23052]: E0C6F9614DC: removed

      Feb 26 13:26:24 mail spamd[21308]: spamd: connection from localhost
      [127.0.0.1] at port 42070
      Feb 26 13:26:24 mail spamd[21308]: spamd: setuid to spamassassin succeeded
      Feb 26 13:26:24 mail spamd[21308]: spamd: processing message
      <1235651181.6478.13.camel@kula> for spamassassin:511
      Feb 26 13:26:29 mail spamd[21308]: spamd: clean message (-2.2/5.0) for
      spamassassin:511 in 4.7 seconds, 1522 bytes.
      Feb 26 13:26:29 mail spamd[21308]: spamd: result: . -2 - AWL,BAYES_00
      scantime=4.7,size=1522,user=spamassassin,uid=511,required_score=5.0,rhost=localhost,
      raddr=127.0.0.1,rport=42070,mid=<1235651181.6478.13.camel@kula>,bayes=0.000000,autolearn=ham
      Feb 26 13:26:29 mail postfix/pickup[18649]: A18069614F3: uid=511
      from=<peter@some_host.com>

      Feb 26 13:26:29 mail postfix/cleanup[21427]: A18069614F3:
      message-id=<1235651181.6478.13.camel@kula>
      Feb 26 13:26:29 mail postfix/qmgr[23052]: A18069614F3:
      from=<peter@some_host.com>, size=1880, nrcpt=5 (queue active)
      Feb 26 13:26:29 mail postfix/local[21364]: A18069614F3:
      to=<john@...>, relay=local, delay=0.01, delays=0.01/0/0/0,
      dsn=2.0.0, status=sent (deli
      vered to maildir)
      Feb 26 13:26:29 mail postfix/local[21368]: A18069614F3:
      to=<bob@...>, relay=local, delay=0.01, delays=0.01/0/0/0,
      dsn=2.0.0, status=sent (deli
      vered to maildir)
      Feb 26 13:26:29 mail postfix/local[21364]: A18069614F3:
      to=<dave@...>, orig_to=<bob@...>, relay=local,
      delay=0.02, delays=0.01/0/0/0
      , dsn=2.0.0, status=sent (delivered to maildir)
      Feb 26 13:26:29 mail postfix/local[21368]: A18069614F3:
      to=<john@...>, orig_to=<bob@...>, relay=local,
      delay=0.02, delays=0.01/0/0/
      0, dsn=2.0.0, status=sent (delivered to maildir)
      Feb 26 13:26:29 mail postfix/local[21435]: A18069614F3:
      to=<dave@...>, relay=local, delay=0.02, delays=0.01/0.01/0/0,
      dsn=2.0.0, status=sent (de
      livered to maildir)
      Feb 26 13:26:29 mail postfix/qmgr[23052]: A18069614F3: removed

      I tried setting receive_override_options = no_address_mappings but this
      kills address expansion both before and after filtering. Is there a
      way to disable it only on one side of the content_filter?

      Config is included at the bottom.

      Thanks
      --kj

      # postconf -n
      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      command_directory = /usr/sbin
      config_directory = /etc/postfix
      daemon_directory = /usr/libexec/postfix
      debug_peer_level = 2
      home_mailbox = Maildir/
      html_directory = no
      inet_interfaces = all
      mail_owner = postfix
      mailbox_size_limit = 256000000
      mailq_path = /usr/bin/mailq.postfix
      manpage_directory = /usr/share/man
      mydestination = hash:/etc/postfix/mydomains
      mydomain = example.com
      mynetworks = , 127.0.0.0/8
      myorigin = $mydomain
      newaliases_path = /usr/bin/newaliases.postfix
      queue_directory = /var/spool/postfix
      readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
      sample_directory = /usr/share/doc/postfix-2.3.3/samples
      sendmail_path = /usr/sbin/sendmail.postfix
      setgid_group = postdrop
      smtp_sasl_security_options = noplaintext
      smtpd_banner = $myhostname ESMTP $mail_name
      smtpd_recipient_restrictions = permit_sasl_authenticated,
      permit_mynetworks, reject_unauth_destination, reject_rbl_client
      zen.spamhaus.org
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_local_domain = $myhostname
      smtpd_sasl_security_options = noanonymous
      unknown_local_recipient_reject_code = 550
      virtual_alias_domains = mail.example.com
      virtual_alias_maps = hash:/etc/postfix/virtual

      Spamassassin is integrated with the followingin master.conf:

      smtp inet n - n - - smtpd
      -o content_filter=spamassassin
      ......
      spamassassin unix - n n - - pipe
      user=spamassassin argv=/usr/bin/spamc -f -e
      /usr/sbin/sendmail -oi -f ${sender} ${recipient}
    • Wietse Venema
      Look for receive_override_options in the MASTER.CF file examples of the FILTER_README documentation. Wietse
      Message 2 of 7 , Feb 26, 2009
      • 0 Attachment
        Look for receive_override_options in the MASTER.CF file
        examples of the FILTER_README documentation.

        Wietse
      • postfix@corwyn.net
        ... As you guess below, it s being expanded twice ... You need to disable it on one side, but then enable it on the other. In addition to
        Message 3 of 7 , Feb 26, 2009
        • 0 Attachment
          At 08:53 AM 2/26/2009, kj wrote:
          >When sending a mail to bob@..., bob receives one copy of the
          >mail, but john and dave each receives two. I understand the
          >problem: postfix does the recipient expansion, sends it off to spamassassin.
          >Spamassassin requeues the mail via the sendmail binary, so postfix
          >treats it as a new mail.

          As you guess below, it's being expanded twice

          >I tried setting receive_override_options = no_address_mappings but
          >this kills address expansion both before and after filtering. Is
          >there a way to disable it only on one side of the content_filter?

          You need to disable it on one side, but then enable it on the other.
          In addition to receive_override_options = no_address_mappings in main.cf

          Add something like
          -o receive_override_options=

          to the other side that you've defined in master.cf

          Rick
        • Magnus Bäck
          On Thursday, February 26, 2009 at 16:54 CET, postfix@corwyn.net wrote: [...] ... I would suggest selectively disabling the address rewriting instead of the
          Message 4 of 7 , Feb 26, 2009
          • 0 Attachment
            On Thursday, February 26, 2009 at 16:54 CET,
            postfix@... wrote:

            [...]

            > You need to disable it on one side, but then enable it on the other.
            > In addition to receive_override_options = no_address_mappings in
            > main.cf
            >
            > Add something like
            > -o receive_override_options=
            >
            > to the other side that you've defined in master.cf

            I would suggest selectively disabling the address rewriting instead of
            the other way around. The risk of error is greater if rewriting is
            disabled by default.

            --
            Magnus Bäck
            magnus@...
          • Charles Marcus
            ... Hmmm, ok, I ll bite, since I may do this some day soon... If this is better, why does The Book - and more importantly, the official docs (FILTER_README)
            Message 5 of 7 , Feb 27, 2009
            • 0 Attachment
              On 2/26/2009 11:00 AM, Magnus Bäck wrote:
              >> You need to disable it on one side, but then enable it on the other.
              >> In addition to receive_override_options = no_address_mappings in
              >> main.cf
              >>
              >> Add something like
              >> -o receive_override_options=
              >>
              >> to the other side that you've defined in master.cf

              > I would suggest selectively disabling the address rewriting instead of
              > the other way around. The risk of error is greater if rewriting is
              > disabled by default.

              Hmmm, ok, I'll bite, since I may do this some day soon...

              If this is better, why does 'The Book' - and more importantly, the
              official docs (FILTER_README) - say to do it the other way?

              --

              Best regards,

              Charles
            • mouss
              ... maybe because at the time it was written, it was hoped that people really read the whole thing and understand it. now, I think too many people had problems
              Message 6 of 7 , Feb 27, 2009
              • 0 Attachment
                Charles Marcus a écrit :
                > On 2/26/2009 11:00 AM, Magnus Bäck wrote:
                >>> You need to disable it on one side, but then enable it on the other.
                >>> In addition to receive_override_options = no_address_mappings in
                >>> main.cf
                >>>
                >>> Add something like
                >>> -o receive_override_options=
                >>>
                >>> to the other side that you've defined in master.cf
                >
                >> I would suggest selectively disabling the address rewriting instead of
                >> the other way around. The risk of error is greater if rewriting is
                >> disabled by default.
                >
                > Hmmm, ok, I'll bite, since I may do this some day soon...
                >
                > If this is better, why does 'The Book' - and more importantly, the
                > official docs (FILTER_README) - say to do it the other way?
                >

                maybe because at the time it was written, it was hoped that people
                really read the whole thing and understand it.

                now, I think too many people had problems with this, and the docs should
                be changed to propose "the other wy": disable rewrite in master.cf
                (maybe via a ${var}).
              • kj
                ... Thanks Wietse, adding it to the smtp line in master.cf instead solve the problem. Sorry for my late reply - I wrote it and then went off on a long weekend
                Message 7 of 7 , Mar 2, 2009
                • 0 Attachment
                  Wietse Venema wrote:
                  > Look for receive_override_options in the MASTER.CF file
                  > examples of the FILTER_README documentation.
                  >
                  > Wietse
                  >

                  Thanks Wietse, adding it to the smtp line in master.cf instead solve
                  the problem.

                  Sorry for my late reply - I wrote it and then went off on a long weekend
                  without ever hitting send.

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