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

Re: Delivery to command in aliases ignored ?

Expand Messages
  • Wietse Venema
    ... The alias_maps parameter is used ONLY for domains in mydestination. Wietse
    Message 1 of 12 , Mar 29, 2013
      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 2 of 12 , Mar 29, 2013
        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 3 of 12 , Apr 1, 2013
          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 4 of 12 , Apr 1, 2013
            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 5 of 12 , Apr 1, 2013
              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 6 of 12 , Apr 4, 2013
                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 7 of 12 , Apr 4, 2013
                  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 8 of 12 , Apr 4, 2013
                    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.