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

Re: Delivery to command in aliases ignored ?

Expand Messages
  • Viktor Dukhovni
    ... 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
    Message 1 of 12 , Mar 26, 2013
    • 0 Attachment
      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, 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.