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

Re: Delivery to command in aliases ignored ?

Expand Messages
  • Kajetan Dolinar
    Hi, Viktor, Thank you very much for your answer. I did run the command, as you suggested, but the result may be seen ... # postmap -q test
    Message 1 of 12 , Mar 27, 2013
    • 0 Attachment
      Hi, Viktor,

      Thank you very much for your answer. I did run the command, as you suggested, but the result may be seen ...

      #  postmap -q test hash:/var/lib/mailman/data/aliases
      "|/usr/lib/mailman/mail/mailman post test"

      this is exactly what i would like to have ... the delivery of mail intended for the test to the command, as indicated by the above line. However, i've just checked once more, the same error is there if I send mail for the test@... mailing list.

      Kajetan

      2013/3/27 Viktor Dukhovni <postfix-users@...>
      On Wed, Mar 27, 2013 at 12:26:36AM +0100, Kajetan Dolinar wrote:

      > Greetings to everyone,
      >
      > I have a working Postfix + Cyrus system tested (has got some history of
      > usage) but I want to add the Mailman system to it. However, it seems that I
      > cannot get mail through to the Mailman system past the Mailman's aliases,
      > i.e. the delivery to commands which Mailman uses to process the requests
      > seems to never happen. I keep on getting the following error, no matter
      > what I do:
      >
      > "postfix/local[17255]: 554A7300A53: to=<test@...>, relay=local, ...
      > status=bounced (unknown user: "test")"
      >
      > test@... is the address of the mailing list. The essential
      > configuration parameters are as follows:
      >
      > alias_maps = hash:/var/lib/mailman/data/aliases

      The command:

              $ postmap -q test hash:/var/lib/mailman/data/aliases

      will likely produce no results.  Add a "test" alias to the table
      if you mail for "test" to be delivered to some specific alias.
      Cleary there is no such user.

      > local_recipient_maps = $alias_maps
      > unknown_local_recipient_reject_code = 550
      > transport_maps = hash:/etc/postfix/transport

      This part is working, the message was delivered via local(8).

      >     * local

      --
              Viktor.

    • Kajetan Dolinar
      Hi all, Viktor, I don t know if this has reached the list (I haven t got the replica of the mail from the list) so please excuse me for sending it again.
      Message 2 of 12 , Mar 29, 2013
      • 0 Attachment
        Hi all, Viktor, I don't know if this has reached the list (I haven't got the replica of the mail from the list) so please excuse me for sending it again.

        Viktor, thank you very much for your answer. I did run the command, as you suggested, and the result was expected:

        #  postmap -q test hash:/var/lib/mailman/data/
        aliases
        "|/usr/lib/mailman/mail/mailman post test"

        This is exactly what i would like to have ... the delivery of mail intended for the test@... to the command, as indicated by the above line. However, i've just checked once more, the same error is there if I send mail for the test@... mailing list. It just says that test user is unknown.

        Indeed, I don't have a UNIX user by that name in my machine; but, as far as I was able to figure out, the aliases delivery to command should not have problems with that, especially if I set local_recipient_maps to the enpty value. Do I miss anything?

        Kajetan
      • Wietse Venema
        ... The alias_maps parameter is used ONLY for domains in mydestination. Wietse
        Message 3 of 12 , Mar 29, 2013
        • 0 Attachment
          Kajetan Dolinar:
          > Hi all, Viktor, I don't know if this has reached the list (I haven't got
          > the replica of the mail from the list) so please excuse me for sending it
          > again.
          >
          > Viktor, thank you very much for your answer. I did run the command, as you
          > suggested, and the result was expected:
          >
          > # postmap -q test hash:/var/lib/mailman/data/
          > aliases
          > "|/usr/lib/mailman/mail/mailman post test"
          >
          > This is exactly what i would like to have ... the delivery of mail intended
          > for the test@... to the command, as indicated by the above line.
          > However, i've just checked once more, the same error is there if I send
          > mail for the test@... mailing list. It just says that test user is
          > unknown.
          >
          > Indeed, I don't have a UNIX user by that name in my machine; but, as far as
          > I was able to figure out, the aliases delivery to command should not have
          > problems with that, especially if I set local_recipient_maps to the enpty
          > value. Do I miss anything?

          The alias_maps parameter is used ONLY for domains in mydestination.

          Wietse
        • Viktor Dukhovni
          ... The OP explicitly routes the address in question to the local transport. However, local(8) treats a queue-file recipient address (one resolved to
          Message 4 of 12 , Mar 29, 2013
          • 0 Attachment
            On Fri, Mar 29, 2013 at 07:02:44AM -0400, Wietse Venema wrote:

            > The alias_maps parameter is used ONLY for domains in mydestination.

            The OP explicitly routes the address in question to the "local"
            transport. However, local(8) treats a queue-file recipient
            address (one resolved to local(8) via the transport switch)
            in the same way it treats in the same way it treats the same
            address on the right side of an alias:

            somealias: test@...

            so indeed if example.com does not match mydestination, the address
            won't be subject to alias expansion, even though it resolves to
            the local transport. The solution is along the lines of:

            main.cf:
            indexed = ${default_database_type}:${config_directory}/
            virtual_alias_maps = ${indexed}virtual
            mydestination = local.invalid
            myorigin = example.com

            virtual:
            test@... test@...

            with this only addresses explicitly rewritten to "local.invalid"
            are delivered via the "local" transport and subjected to alias
            expansion. If you have recursive aliases in your aliases(5)
            file, you need to be careful to avoid loops:

            # This loops:
            user: user, bccuser

            # This delivers to user's local mailbox and to bccuser@...
            user: user@..., bccuser

            --
            Viktor.
          • Kajetan Dolinar
            Hi Viktor, Wietse, Thanks for your answers. I ve configured the local.invalid destination, as Viktor has siggested, and removed the default local transport
            Message 5 of 12 , Apr 1, 2013
            • 0 Attachment
              Hi Viktor, Wietse,

              Thanks for your answers. I've configured the local.invalid destination, as Viktor has siggested, and removed the default local transport from the transport file, the virtual aliases for test@... mailing list have been accomodated to direct the mail to local.invalid destination, but I still get the bounce:

              Apr  1 15:03:36 kompotela postfix/local[17508]: F38B8300CF3: to=<test@...>, orig_to=<test@...>, relay=local, delay=0.28, delays=0.12/0.02/0/0.14, dsn=5.1.1, status=bounced (unknown user: "test")

              local_recipient_maps is empty.

              Kajetan

              2013/3/29 Viktor Dukhovni <postfix-users@...>
              On Fri, Mar 29, 2013 at 07:02:44AM -0400, Wietse Venema wrote:

              > The alias_maps parameter is used ONLY for domains in mydestination.

              The OP explicitly routes the address in question to the "local"
              transport.  However, local(8) treats a queue-file recipient
              address (one resolved to local(8) via the transport switch)
              in the same way it treats in the same way it treats the same
              address on the right side of an alias:

                      somealias:      test@...

              so indeed if example.com does not match mydestination, the address
              won't be subject to alias expansion, even though it resolves to
              the local transport.  The solution is along the lines of:

                      main.cf:
                              indexed = ${default_database_type}:${config_directory}/
                              virtual_alias_maps = ${indexed}virtual
                              mydestination = local.invalid
                              myorigin = example.com

                      virtual:
                              test@...        test@...

              with this only addresses explicitly rewritten to "local.invalid"
              are delivered via the "local" transport and subjected to alias
              expansion.  If you have recursive aliases in your aliases(5)
              file, you need to be careful to avoid loops:

                      # This loops:
                      user:   user, bccuser

                      # This delivers to user's local mailbox and to bccuser@...
                      user: user@..., bccuser

              --
                      Viktor.

            • Viktor Dukhovni
              ... local_recipient_maps is irrelevant, you can stop worrying about it, it is used used in smtpd(8) recipient validation, not in local(8) delivery. You need to
              Message 6 of 12 , Apr 1, 2013
              • 0 Attachment
                On Mon, Apr 01, 2013 at 03:16:17PM +0200, Kajetan Dolinar wrote:


                > Thanks for your answers. I've configured the local.invalid destination, as
                > Viktor has siggested, and removed the default local transport from the
                > transport file, the virtual aliases for test@... mailing list have
                > been accomodated to direct the mail to local.invalid destination, but I
                > still get the bounce:
                >
                > Apr 1 15:03:36 kompotela postfix/local[17508]: F38B8300CF3:
                > to=<test@...>, orig_to=<test@...>, relay=local, delay=0.28,
                > delays=0.12/0.02/0/0.14, dsn=5.1.1, status=bounced (unknown user: "test")
                >
                > local_recipient_maps is empty.

                local_recipient_maps is irrelevant, you can stop worrying about
                it, it is used used in smtpd(8) recipient validation, not in local(8)
                delivery.

                You need to repost your updated configuration. It looks like you
                don't have local.invalid listed in mydestination or your aliases
                table is not right.

                aliases:
                test: ???

                postconf -n: ???

                transport: ???

                --
                Viktor.
              • Kajetan Dolinar
                Hi Viktor, all, By a detailed and systematic search into my main.cf, I have found out that I had a stale alias_maps setting somewhere in the bushes amidst the
                Message 7 of 12 , Apr 1, 2013
                • 0 Attachment
                  Hi Viktor, all,

                  By a detailed and systematic search into my main.cf, I have found out that I had a stale alias_maps setting somewhere in the bushes amidst the comments and other settings. The first setting in the file was the correct setting (doing the mailman job) and the second one was the stale one, which remained valid in the runtime of the local process. I appologize for the confusion.

                  Things work well now. However, without your advice on local.invalid destination it would never work and it would be quite a hard time for me to figure that out. Thank you very much. And, yes, I already have some experience with MTAs: I did a complete and successful installation, and for years I'd done maintenance and all the rest, of the qmail system; I may say that I like Postfix more and I would like to thank you for that great job you did for us.

                  Good luck
                  Kajetan


                  2013/4/1 Viktor Dukhovni <postfix-users@...>
                  On Mon, Apr 01, 2013 at 03:16:17PM +0200, Kajetan Dolinar wrote:


                  > Thanks for your answers. I've configured the local.invalid destination, as
                  > Viktor has siggested, and removed the default local transport from the
                  > transport file, the virtual aliases for test@... mailing list have
                  > been accomodated to direct the mail to local.invalid destination, but I
                  > still get the bounce:
                  >
                  > Apr  1 15:03:36 kompotela postfix/local[17508]: F38B8300CF3:
                  > to=<test@...>, orig_to=<test@...>, relay=local, delay=0.28,
                  > delays=0.12/0.02/0/0.14, dsn=5.1.1, status=bounced (unknown user: "test")
                  >
                  > local_recipient_maps is empty.

                  local_recipient_maps is irrelevant, you can stop worrying about
                  it, it is used used in smtpd(8) recipient validation, not in local(8)
                  delivery.

                  You need to repost your updated configuration.  It looks like you
                  don't have local.invalid listed in mydestination or your aliases
                  table is not right.

                          aliases:
                                  test: ???

                          postconf -n: ???

                          transport: ???

                  --
                          Viktor.

                • Charles Marcus
                  ... This is *precisely* why you should always use postconf -n output (both for your *own* troubleshooting efforts, as well as for when asking for help here).
                  Message 8 of 12 , Apr 4, 2013
                  • 0 Attachment
                    On 2013-04-01 10:21 AM, Kajetan Dolinar <dolinar.kajetan@...> wrote:
                    By a detailed and systematic search into my main.cf, I have found out that I had a stale alias_maps setting somewhere in the bushes amidst the comments and other settings. The first setting in the file was the correct setting (doing the mailman job) and the second one was the stale one, which remained valid in the runtime of the local process. I appologize for the confusion.

                    This is *precisely* why you should always use postconf -n output (both for your *own* troubleshooting efforts, as well as for when asking for help here).

                    Using postcinf -n would have shown you immediately (before you even got to the point of asking for help here) your problem.

                    Incidentally, this is why I always leave the original main.cf as is and append *all* of my custom settings to the very end of the file...

                    -- 
                    
                    Best regards,
                    
                    Charles


                  • Reindl Harald
                    ... or if you want a REALLY clean main.cf copy the shipped somewhere in a docs folder and write a COMPLETE own which is EXPLICIT see below a example which is
                    Message 9 of 12 , Apr 4, 2013
                    • 0 Attachment
                      Am 04.04.2013 20:35, schrieb Charles Marcus:
                      > On 2013-04-01 10:21 AM, Kajetan Dolinar <dolinar.kajetan@...> wrote:
                      >> By a detailed and systematic search into my main.cf <http://main.cf>, I have found out that I had a stale
                      >> alias_maps setting somewhere in the bushes amidst the comments and other settings. The first setting in the file
                      >> was the correct setting (doing the mailman job) and the second one was the stale one, which remained valid in the
                      >> runtime of the local process. I appologize for the confusion.
                      >
                      > This is *precisely* why you should always use postconf -n output (both for your *own* troubleshooting efforts, as
                      > well as for when asking for help here).
                      >
                      > Using postcinf -n would have shown you immediately (before you even got to the point of asking for help here) your
                      > problem.
                      >
                      > Incidentally, this is why I always leave the original main.cf as is and append *all* of my custom settings to the
                      > very end of the file...

                      or if you want a REALLY clean "main.cf" copy the shipped somewhere in
                      a docs folder and write a COMPLETE own which is EXPLICIT

                      see below a example which is clear and does not need any comment line, well
                      this is a setup which does not provide smtp on the network but any other of
                      my machines looks identical with a smtpd-block after the smtp-ones

                      why should i want any random line in a servers config which was not
                      explicitly written by myself which implicates i understand it independent
                      if we speak about postfix, dovecot, mysql, apache?

                      myhostname = <servers name>
                      mydomain = <servers domain>
                      myorigin = $mydomain
                      mynetworks = 127.0.0.0/8
                      smtpd_banner = $myhostname ESMTP
                      mail_name = MTA

                      relayhost = [my-relayhost]:587
                      smtp_sasl_auth_enable = yes
                      smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

                      smtp_use_tls = yes
                      smtp_tls_loglevel = 1
                      smtp_tls_cert_file = /etc/postfix/certs/localhost.pem
                      smtp_tls_key_file = /etc/postfix/certs/localhost.pem
                      smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
                      smtp_tls_security_level = may
                      smtp_tls_note_starttls_offer = yes
                      smtp_tls_session_cache_timeout = 3600s
                      smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache

                      enable_long_queue_ids = yes
                      smtpd_discard_ehlo_keywords = silent-discard, etrn, dsn, vrfy, enhancedstatuscodes
                      smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
                      smtpd_recipient_limit = 500
                      disable_vrfy_command = yes

                      mydestination =
                      alias_maps = hash:/etc/aliases
                      alias_database = hash:/etc/aliases
                      sender_canonical_maps = hash:/etc/postfix/canonical

                      double_bounce_sender = double-bounce@<servers domain>
                      address_verify_sender = postmaster@<servers domain>
                      empty_address_recipient = postmaster@<servers domain>
                      unknown_local_recipient_reject_code = 550
                      unverified_recipient_reject_code = 550
                      unknown_hostname_reject_code = 501
                      unknown_address_reject_code = 550
                      bounce_template_file = /etc/postfix/bounce.cf
                      message_size_limit = 10485760

                      body_checks_size_limit = 1024
                      in_flow_delay = 0
                      queue_run_delay = 300
                      minimal_backoff_time = 900
                      maximal_backoff_time = 3600
                      inet_protocols = ipv4

                      readme_directory = /usr/share/doc/postfix-2.10.0/README_FILES
                      sample_directory = /usr/share/doc/postfix-2.10.0/samples
                      sendmail_path = /usr/sbin/sendmail
                      html_directory = no
                      setgid_group = postdrop
                      manpage_directory = /usr/share/man
                      newaliases_path = /usr/bin/newaliases
                      mailq_path = /usr/bin/mailq

                      queue_directory = /var/spool/postfix
                      command_directory = /usr/sbin
                      daemon_directory = /usr/libexec/postfix
                      data_directory = /var/lib/postfix
                      mail_owner = postfix
                    • Wietse Venema
                      ... Postfix has improved over time but it does not warn about multiple entries for the same parameter. It probably should warn, especially when multiple
                      Message 10 of 12 , Apr 4, 2013
                      • 0 Attachment
                        Charles Marcus:
                        > On 2013-04-01 10:21 AM, Kajetan Dolinar <dolinar.kajetan@...> wrote:
                        > > By a detailed and systematic search into my main.cf <http://main.cf>,
                        > > I have found out that I had a stale alias_maps setting somewhere in
                        > > the bushes amidst the comments and other settings. The first setting
                        > > in the file was the correct setting (doing the mailman job) and the
                        > > second one was the stale one, which remained valid in the runtime of
                        > > the local process. I appologize for the confusion.
                        >
                        > This is *precisely* why you should always use postconf -n output (both
                        > for your *own* troubleshooting efforts, as well as for when asking for
                        > help here).
                        >
                        > Using postconf -n would have shown you immediately (before you even got
                        > to the point of asking for help here) your problem.
                        >
                        > Incidentally, this is why I always leave the original main.cf as is and
                        > append *all* of my custom settings to the very end of the file...

                        Postfix has improved over time but it does not warn about multiple
                        entries for the same parameter. It probably should warn, especially
                        when multiple entries for the same parameter have different values.

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