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

Re: delivering mail to separate users

Expand Messages
  • Simon Brereton
    On Dec 19, 2012 10:06 PM, Viktor Dukhovni ... Sweet, thanks! Simon
    Message 1 of 14 , Dec 19, 2012
    • 0 Attachment


      On Dec 19, 2012 10:06 PM, "Viktor Dukhovni" <postfix-users@...> wrote:
      >
      > On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote:
      >
      > > One of the clients I support is getting a consultant to do some
      > > sensitive work for them and so one of the directors wants to get a
      > > copy of all the mails sent to this new mail box.
      > >
      > > At first, I though I would simply set up the new mailbox (all domains
      > > are virtual) and then add an alias to virtual_alias_maps like:
      > >
      > > newuser@...   director@...,newuser@...
      > >
      > > But it occurs to me that this will create a loop - no?
      >
      > No, there is no loop, virtual alias expansion eliminates exactly
      > this kind of loop and delivers email to the leaf address and
      > to its peers.

      Sweet, thanks!

      Simon

    • Simon Brereton
      ... Viktor When I do this mail is only delivered to newuser@example.org and not director@example.org as well. I did postmap the virtual_alias_maps. Is there
      Message 2 of 14 , Dec 19, 2012
      • 0 Attachment
        On 19 December 2012 22:05, Viktor Dukhovni <postfix-users@...> wrote:
        > On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote:
        >
        >> One of the clients I support is getting a consultant to do some
        >> sensitive work for them and so one of the directors wants to get a
        >> copy of all the mails sent to this new mail box.
        >>
        >> At first, I though I would simply set up the new mailbox (all domains
        >> are virtual) and then add an alias to virtual_alias_maps like:
        >>
        >> newuser@... director@...,newuser@...
        >>
        >> But it occurs to me that this will create a loop - no?
        >
        > No, there is no loop, virtual alias expansion eliminates exactly
        > this kind of loop and delivers email to the leaf address and
        > to its peers.
        >
        > --
        > Viktor.

        Viktor

        When I do this mail is only delivered to newuser@... and not
        director@... as well.

        I did postmap the virtual_alias_maps. Is there something else I should I do?

        Thanks.

        Simon
      • Viktor Dukhovni
        ... No, but you ve likely misconfigured other elements of the system. To test the table contents: 1. postconf -h virtual_alias_maps If this contains no
        Message 3 of 14 , Dec 20, 2012
        • 0 Attachment
          On Thu, Dec 20, 2012 at 12:24:30AM -0500, Simon Brereton wrote:

          > >> newuser@... director@..., newuser@...
          > >>
          > >> But it occurs to me that this will create a loop - no?
          > >
          > > No, there is no loop, virtual alias expansion eliminates exactly
          > > this kind of loop and delivers email to the leaf address and
          > > to its peers.
          >
          > When I do this mail is only delivered to newuser@... and not
          > director@... as well.
          >
          > I did postmap the virtual_alias_maps. Is there something else I should I do?

          No, but you've likely misconfigured other elements of the system.

          To test the table contents:

          1. postconf -h virtual_alias_maps

          If this contains no unexpanded ${variable} references, just set

          maps=$(postconf -h virtual_alias_maps)

          Otherwise, figure out what the variables expand to and set

          maps="type1:table1 type2:table2 ..."

          for all the maps in resulting from the expansion.


          2. Run:

          $ postmap -fq newuser@... $maps

          To check that the result of the expansion of the user via
          $virtual_alias_maps.

          3. Make sure you have not disabled virtual_alias_maps expansion via:

          receive_override_options=no_address_mappings

          4. Check your logs (http://www.postfix.org/DEBUG_README.html#mail)
          you'll see how many recipients each message expands to, from
          what original addresses, and how each recipient was or failed to be
          delivered.

          --
          Viktor.
        • Simon Brereton
          ... I think this is ok. Output is: mail:/etc/postfix# postconf -h virtual_alias_maps proxy:mysql:/etc/postfix/Mail-Alias.cf,
          Message 4 of 14 , Dec 20, 2012
          • 0 Attachment
            On 20 December 2012 08:07, Viktor Dukhovni <postfix-users@...> wrote:
            > On Thu, Dec 20, 2012 at 12:24:30AM -0500, Simon Brereton wrote:
            >
            >> >> newuser@... director@..., newuser@...
            >> >>
            >> >> But it occurs to me that this will create a loop - no?
            >> >
            >> > No, there is no loop, virtual alias expansion eliminates exactly
            >> > this kind of loop and delivers email to the leaf address and
            >> > to its peers.
            >>
            >> When I do this mail is only delivered to newuser@... and not
            >> director@... as well.
            >>
            >> I did postmap the virtual_alias_maps. Is there something else I should I do?
            >
            > No, but you've likely misconfigured other elements of the system.
            >
            > To test the table contents:
            >
            > 1. postconf -h virtual_alias_maps
            >
            > If this contains no unexpanded ${variable} references, just set
            >
            > maps=$(postconf -h virtual_alias_maps)
            >
            > Otherwise, figure out what the variables expand to and set
            >
            > maps="type1:table1 type2:table2 ..."
            >
            > for all the maps in resulting from the expansion.

            I think this is ok. Output is:
            mail:/etc/postfix# postconf -h virtual_alias_maps
            proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases

            > 2. Run:
            >
            > $ postmap -fq newuser@... $maps
            >
            > To check that the result of the expansion of the user via
            > $virtual_alias_maps.

            Here I ran into problems.
            mail:/etc/postfix# postmap -fq newuser@... $maps
            postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
            [-q key] [map_type:]file...
            postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
            config_dir] [-d key] [-q key] [map_type:]file...
            mail:/etc/postfix#
            mail:/etc/postfix# postmap -fq newuser@... virtual_alias_maps
            postmap: fatal: open database virtual_alias_maps.db: No such file or directory
            postfix/postmap[31146]: fatal: open database virtual_alias_maps.db:
            No such file or directory

            But it pays to read the error messages, so...
            mail:/etc/postfix# postmap -fq newuser@... virtual_user_aliases
            director@...,newuser@...

            Which looks good to me.

            > 3. Make sure you have not disabled virtual_alias_maps expansion via:
            >
            > receive_override_options=no_address_mappings

            I'm pretty sure this isn't disabled because a different virtual_alias
            in the file works (maps to one local domain and one external one).

            > 4. Check your logs (http://www.postfix.org/DEBUG_README.html#mail)
            > you'll see how many recipients each message expands to, from
            > what original addresses, and how each recipient was or failed to be
            > delivered.


            I did check the logs, which is how I know it wasn't delivered to both users :)

            Here's the (sanitized) log out put from a test from the postmaster
            account to the newuser.

            Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: connect from
            localhost[127.0.0.1]
            Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: setting up TLS
            connection from localhost[127.0.0.1]
            Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: Anonymous TLS
            connection established from localhost[127.0.0.1]: TLSv1 with cipher
            DHE-RSA-AES256-SHA (256/256 bits)
            Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: 0F96ADC6001:
            client=localhost[127.0.0.1], sasl_method=LOGIN,
            sasl_username=postmaster@...
            Dec 20 17:16:32 mail postfix/cleanup[31208]: 0F96ADC6001:
            message-id=<20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>
            Dec 20 17:16:32 mail postfix/qmgr[17306]: 0F96ADC6001:
            from=<postmaster@...>, size=934, nrcpt=1 (queue active)
            Dec 20 17:16:32 mail dkimproxy.out[11740]: connect from 127.0.0.1
            Dec 20 17:16:32 mail dovecot: imap-login: Login:
            user=<postmaster@...>, method=PLAIN, rip=127.0.0.1, secured
            Dec 20 17:16:32 mail postfix/smtpd[31210]: connect from localhost[127.0.0.1]
            Dec 20 17:16:32 mail postfix/smtp[31209]: discarding EHLO keywords:
            8BITMIME STARTTLS
            Dec 20 17:16:32 mail postfix/smtpd[31210]: 22D2FDC6003:
            client=localhost[127.0.0.1]
            Dec 20 17:16:32 mail postfix/submission/smtpd[31207]: disconnect from
            localhost[127.0.0.1]
            Dec 20 17:16:32 mail dovecot: IMAP(postmaster@...):
            Disconnected: Logged out bytes=693/384
            Dec 20 17:16:33 mail dkimproxy.out[11740]: DKIM signing - signed;
            message-id=<20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>,
            signer=<@...>, from=<postmaster@...>
            Dec 20 17:16:33 mail postfix/cleanup[31208]: 22D2FDC6003:
            message-id=<20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>
            Dec 20 17:16:33 mail postfix/qmgr[17306]: 22D2FDC6003:
            from=<postmaster@...>, size=1679, nrcpt=1 (queue active)
            Dec 20 17:16:33 mail postfix/smtp[31209]: 0F96ADC6001:
            to=<newuser@...>, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1,
            delays=1/0/0.08/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
            22D2FDC6003)
            Dec 20 17:16:33 mail postfix/qmgr[17306]: 0F96ADC6001: removed
            Dec 20 17:16:33 mail postfix/smtpd[31210]: disconnect from localhost[127.0.0.1]
            Dec 20 17:16:33 mail amavisd-new[30893]: (30893-06) ESMTP::10024
            /var/lib/amavis/tmp/amavis-20121220T165156-30893:
            <postmaster@...> -> <newuser@...> SIZE=1679 Received:
            from mail.example.org ([127.0.0.1]) by amavisd.example.org
            (mail.example.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
            for <newuser@...>; Thu, 20 Dec 2012 17:16:33 +0000 (UTC)
            Dec 20 17:16:33 mail amavisd-new[30893]: (30893-06) dkim: VALID
            Author+Sender+MailFrom signature by i=@..., From:
            <postmaster@...>, a=rsa-sha256, c=relaxed/simple, s=dkim,
            d=example.org
            Dec 20 17:16:33 mail amavisd-new[30893]: (30893-06) Checking:
            Y2ejeojM6xRO [127.0.0.1] <postmaster@...> ->
            <newuser@...>
            Dec 20 17:16:33 mail amavisd-new[30893]: (30893-06) p001 1
            Content-Type: text/plain, size: 17 B, name:
            Dec 20 17:16:35 mail amavisd-new[30893]: (30893-06) bounce
            unverifiable, <postmaster@...> -> <newuser@...>
            Dec 20 17:16:35 mail amavisd-new[30893]: (30893-06) SPAM-TAG,
            <postmaster@...> -> <newuser@...>, No, score=-3
            tagged_above=-9999 required=4 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9,
            DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
            Dec 20 17:16:35 mail postfix/smtpd[31216]: connect from localhost[127.0.0.1]
            Dec 20 17:16:35 mail postfix/smtpd[31216]: 78DB2DC6001:
            client=localhost[127.0.0.1]
            Dec 20 17:16:36 mail postfix/cleanup[31208]: 78DB2DC6001:
            message-id=<20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>
            Dec 20 17:16:36 mail postfix/qmgr[17306]: 78DB2DC6001:
            from=<postmaster@...>, size=2508, nrcpt=1 (queue active)
            Dec 20 17:16:36 mail postfix/smtpd[31216]: disconnect from localhost[127.0.0.1]
            Dec 20 17:16:36 mail amavisd-new[30893]: (30893-06) FWD via SMTP:
            <postmaster@...> -> <newuser@...>,BODY=7BIT 250 2.0.0
            Ok, id=30893-06, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
            78DB2DC6001
            Dec 20 17:16:36 mail amavisd-new[30893]: (30893-06) Passed CLEAN,
            [127.0.0.1] [207.237.161.138] <postmaster@...> ->
            <newuser@...>, Message-ID:
            <20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>,
            mail_id: Y2ejeojM6xRO, Hits: -3, size: 1679, queued_as: 78DB2DC6001,
            dkim_id=@..., 3346 ms
            Dec 20 17:16:36 mail amavisd-new[30893]: (30893-06) TIMING-SA total
            2256 ms - parse: 1.16 (0.1%), extract_message_metadata: 4 (0.2%),
            get_uri_detail_list: 0.45 (0.0%), tests_pri_-1000: 1.93 (0.1%),
            tests_pri_-950: 1.04 (0.0%), tests_pri_-900: 0.78 (0.0%),
            tests_pri_-400: 11 (0.5%), check_bayes: 10 (0.5%), tests_pri_0: 2033
            (90.1%), check_spf: 0.38 (0.0%), check_dcc: 134 (6.0%), check_razor2:
            1796 (79.6%), check_pyzor: 78 (3.5%), tests_pri_500: 56 (2.5%),
            poll_dns_idle: 50 (2.2%), learn: 139 (6.2%), get_report: 0.73 (0.0%)
            Dec 20 17:16:36 mail postfix/smtp[31211]: 22D2FDC6003:
            to=<newuser@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=4.4,
            delays=1/0/0/3.3, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=30893-06,
            from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 78DB2DC6001)
            Dec 20 17:16:36 mail postfix/qmgr[17306]: 22D2FDC6003: removed
            Dec 20 17:16:36 mail amavisd-new[30893]: (30893-06) TIMING [total 3349
            ms] - SMTP greeting: 1 (0%)0, SMTP EHLO: 0 (0%)0, SMTP pre-MAIL: 0
            (0%)0, SMTP pre-DATA-flush: 1 (0%)0, SMTP DATA: 38 (1%)1, check_init:
            0 (0%)1, digest_hdr: 2 (0%)1, digest_body_dkim: 14 (0%)2, gen_mail_id:
            1 (0%)2, mime_decode: 4 (0%)2, get-file-type1: 9 (0%)2, parts_decode:
            0 (0%)2, check_header: 1 (0%)2, AV-scan-1: 1 (0%)2, spam-wb-list: 1
            (0%)2, SA parse: 2 (0%)2, SA check: 2252 (67%)70, update_cache: 4
            (0%)70, decide_mail_destiny: 1 (0%)70, fwd-connect: 3 (0%)70,
            fwd-mail-pip: 1001 (30%)100, fwd-rcpt-pip: 0 (0%)100, fwd-data-chkpnt:
            0 (0%)100, write-header: 1 (0%)100, fwd-data-contents: 0 (0%)100,
            fwd-end-chkpnt: 4 (0%)100, prepare-dsn: 0 (0%)100, main_log_entry: 5
            (0%)100, update_snmp: 1 (0%)100, SMTP pre-response: 0 (0%)100, SMTP
            response: 0 (0%)100, unlink-1-files: 0 (0%)100, rundown: 0 (0%)100
            Dec 20 17:16:36 mail dovecot: deliver(newuser@...):
            msgid=<20121220121630.Horde.zri5FlyZnp9Q00fu59eCg-A@...>:
            postmaster@...: saved mail to INBOX
            Dec 20 17:16:36 mail postfix/pipe[31264]: 78DB2DC6001:
            to=<newuser@...>, relay=dovecot, delay=1.1, delays=1/0/0/0.05,
            dsn=2.0.0, status=sent (delivered via dovecot service)
            Dec 20 17:16:36 mail postfix/qmgr[17306]: 78DB2DC6001: removed

            Normally, if there was alias rewriting done, I would see:
            Dec 20 16:59:37 mail postfix/pipe[31069]: 7A68ADC6003:
            to=<director@...>, orig_to=<pa@...>, relay=dovecot,
            delay=1, delays=1/0/0/0.01, dsn=2.0.0, status=sent (delivered via
            dovecot service)

            Order shouldn't matter in the alias file, and if it does, I surely
            have it the right way around. I did reload postfix after doing the
            postmapping.

            Simon
          • Viktor Dukhovni
            ... So you have two tables mysql and a hash table. ... After setting maps to the exact list tables you configured. $ postmap -fq newuser@example.com
            Message 5 of 14 , Dec 20, 2012
            • 0 Attachment
              On Thu, Dec 20, 2012 at 12:25:03PM -0500, Simon Brereton wrote:

              > >> I did postmap the virtual_alias_maps. Is there something else I should I do?
              > >
              > > No, but you've likely misconfigured other elements of the system.
              >
              > I think this is ok. Output is:
              > mail:/etc/postfix# postconf -h virtual_alias_maps
              > proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases

              So you have two tables mysql and a hash table.

              > > $ postmap -fq newuser@... $maps

              After setting "maps" to the exact list tables you configured.

              $ postmap -fq newuser@... \
              mysql:/etc/postfix/Mail-Alias.cf \
              hash:/etc/postfix/virtual_user_aliases

              You almost certainly have an entry for "newuser@..."
              in the mysql table that hides any data in the hash table. Perhaps
              you should list the hash table first, if you want it to take
              precedence over mysql.

              > >
              > > To check that the result of the expansion of the user via
              > > $virtual_alias_maps.
              >
              > Here I ran into problems.
              > mail:/etc/postfix# postmap -fq newuser@... $maps
              > postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
              > [-q key] [map_type:]file...
              > postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
              > config_dir] [-d key] [-q key] [map_type:]file...

              I'm disappointed you could not then figure it out by reading the manpage,
              or parsing the "usage:" message.

              postmap -q key map [optionally more maps]

              --
              Viktor.
            • Simon Brereton
              ... With postfix it s always the simple solution. I should have seen that. Reversing the order works now - and is in fact the more correct approach. Thanks!
              Message 6 of 14 , Dec 20, 2012
              • 0 Attachment
                On 20 December 2012 12:44, Viktor Dukhovni <postfix-users@...> wrote:
                > On Thu, Dec 20, 2012 at 12:25:03PM -0500, Simon Brereton wrote:
                >
                >> >> I did postmap the virtual_alias_maps. Is there something else I should I do?
                >> >
                >> > No, but you've likely misconfigured other elements of the system.
                >>
                >> I think this is ok. Output is:
                >> mail:/etc/postfix# postconf -h virtual_alias_maps
                >> proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases
                >
                > So you have two tables mysql and a hash table.
                >
                >> > $ postmap -fq newuser@... $maps
                >
                > After setting "maps" to the exact list tables you configured.
                >
                > $ postmap -fq newuser@... \
                > mysql:/etc/postfix/Mail-Alias.cf \
                > hash:/etc/postfix/virtual_user_aliases
                >
                > You almost certainly have an entry for "newuser@..."
                > in the mysql table that hides any data in the hash table. Perhaps
                > you should list the hash table first, if you want it to take
                > precedence over mysql.

                With postfix it's always the simple solution. I should have seen
                that. Reversing the order works now - and is in fact the more correct
                approach. Thanks!

                Dec 20 18:17:49 mail dovecot: deliver(director@...):
                msgid=<20121220131743.Horde.1YqSdFyZnp9Q01ZHFAB0eeA@...>:
                postmaster@...: saved mail to INBOX
                Dec 20 18:17:49 mail postfix/pipe[31973]: 777B5DC6001:
                to=<director@...>, relay=dovecot, delay=1, delays=1/0/0/0.01,
                dsn=2.0.0, status=sent (delivered via dovecot service)
                Dec 20 18:17:49 mail dovecot: deliver(newuser@...):
                msgid=<20121220131743.Horde.1YqSdFyZnp9Q01ZHFAB0eeA@...>:
                postmaster@...: saved mail to INBOX
                Dec 20 18:17:49 mail postfix/pipe[31974]: 777B5DC6001:
                to=<newuser@...>, relay=dovecot, delay=1,
                delays=1/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot
                service)
                Dec 20 18:17:49 mail dovecot: deliver(director@...):
                msgid=<20121220131743.Horde.1YqSdFyZnp9Q01ZHFAB0eeA@...>:
                postmaster@...: saved mail to INBOX
                Dec 20 18:17:49 mail postfix/pipe[31976]: 777B5DC6001:
                to=<director@...>, orig_to=<newuser@...>,
                relay=dovecot, delay=1, delays=1/0.01/0/0.01, dsn=2.0.0, status=sent
                (delivered via dovecot service)
                Dec 20 18:17:49 mail postfix/qmgr[31903]: 777B5DC6001: removed


                >> >
                >> > To check that the result of the expansion of the user via
                >> > $virtual_alias_maps.
                >>
                >> Here I ran into problems.
                >> mail:/etc/postfix# postmap -fq newuser@... $maps
                >> postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
                >> [-q key] [map_type:]file...
                >> postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
                >> config_dir] [-d key] [-q key] [map_type:]file...
                >
                > I'm disappointed you could not then figure it out by reading the manpage,
                > or parsing the "usage:" message.
                >
                > postmap -q key map [optionally more maps]

                That disappointment is hard to bear, but not unexpected sadly. I've
                had another look and I still don't get it. Except that $maps can't be
                expanded by the shell. I feel sure there should be a way to check not
                just a single file (as I did), but the actual entry from main.cf - but
                I'm not able to find it. Sorry.

                Simon
              • Viktor Dukhovni
                ... Of course it can be expanded by the shell, it is a shell variable after all. $ maps= .... $ postmap -fq key $maps If it were not for the possibility of
                Message 7 of 14 , Dec 20, 2012
                • 0 Attachment
                  On Thu, Dec 20, 2012 at 01:39:07PM -0500, Simon Brereton wrote:


                  > >> > To check that the result of the expansion of the user via
                  > >> > $virtual_alias_maps.
                  > >>
                  > >> Here I ran into problems.
                  > >> mail:/etc/postfix# postmap -fq newuser@... $maps
                  > >> postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
                  > >> [-q key] [map_type:]file...
                  > >> postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
                  > >> config_dir] [-d key] [-q key] [map_type:]file...
                  > >
                  > > I'm disappointed you could not then figure it out by reading the manpage,
                  > > or parsing the "usage:" message.
                  > >
                  > > postmap -q key map [optionally more maps]
                  >
                  > That disappointment is hard to bear, but not unexpected sadly. I've
                  > had another look and I still don't get it. Except that $maps can't be
                  > expanded by the shell.

                  Of course it can be expanded by the shell, it is a shell variable
                  after all.

                  $ maps="...."
                  $ postmap -fq key $maps

                  If it were not for the possibility of unexpanded "${parameter}" values
                  in "postconf -h" output you could write:

                  $ maps=$(postconf -h virtual_alias_maps)
                  $ postmap -fq key $maps

                  I've not looked too closely at what it would take for "postconf"
                  to be able to perform fully recursive parameter expansion. It is
                  apparently a bit tricky (from past conversations with Wietse). It
                  would be useful however.

                  --
                  Viktor.
                • Wietse Venema
                  ... I restructured the postconf code 12 months ago, to add support for unknown parameter warnings, service-dependent parameter names
                  Message 8 of 14 , Dec 21, 2012
                  • 0 Attachment
                    Viktor Dukhovni:
                    > I've not looked too closely at what it would take for "postconf"
                    > to be able to perform fully recursive parameter expansion. It is
                    > apparently a bit tricky (from past conversations with Wietse). It
                    > would be useful however.

                    I restructured the postconf code 12 months ago, to add support for
                    "unknown parameter" warnings, service-dependent parameter names
                    (foo_destination_concurrency_limit etc.), and master.cf.

                    Thanks to this, it is no longer a problem to add support for parameter
                    expansion. I'll have a fully-working version by the end of the day.

                    Wietse
                  • Viktor Dukhovni
                    ... Happy new year to you too! Thanks for the holiday present. It ll make life easier to tell people to report: $ postconf -q user@example.com $(postconf -Rh
                    Message 9 of 14 , Dec 21, 2012
                    • 0 Attachment
                      On Fri, Dec 21, 2012 at 03:10:11PM -0500, Wietse Venema wrote:

                      > Viktor Dukhovni:
                      > > I've not looked too closely at what it would take for "postconf"
                      > > to be able to perform fully recursive parameter expansion. It is
                      > > apparently a bit tricky (from past conversations with Wietse). It
                      > > would be useful however.
                      >
                      > I restructured the postconf code 12 months ago, to add support for
                      > "unknown parameter" warnings, service-dependent parameter names
                      > (foo_destination_concurrency_limit etc.), and master.cf.
                      >
                      > Thanks to this, it is no longer a problem to add support for parameter
                      > expansion. I'll have a fully-working version by the end of the day.

                      Happy new year to you too! Thanks for the holiday present.

                      It'll make life easier to tell people to report:

                      $ postconf -q user@... $(postconf -Rh virtual_alias_maps|tr ',' ' ')

                      (and similar recipes) than to have to explain the details in a series
                      of posts...

                      --
                      Viktor.
                    • Simon Brereton
                      On Dec 21, 2012 6:13 PM, Viktor Dukhovni ... For people archive viewers should read people like me Thanks Wietse! Simon ...
                      Message 10 of 14 , Dec 21, 2012
                      • 0 Attachment


                        On Dec 21, 2012 6:13 PM, "Viktor Dukhovni" <postfix-users@...> wrote:
                        >
                        > On Fri, Dec 21, 2012 at 03:10:11PM -0500, Wietse Venema wrote:
                        >
                        > > Viktor Dukhovni:
                        > > > I've not looked too closely at what it would take for "postconf"
                        > > > to be able to perform fully recursive parameter expansion. It is
                        > > > apparently a bit tricky (from past conversations with Wietse). It
                        > > > would be useful however.
                        > >
                        > > I restructured the postconf code 12 months ago, to add support for
                        > > "unknown parameter" warnings, service-dependent parameter names
                        > > (foo_destination_concurrency_limit etc.), and master.cf.
                        > >
                        > > Thanks to this, it is no longer a problem to add support for parameter
                        > > expansion. I'll have a fully-working version by the end of the day.
                        >
                        > Happy new year to you too!  Thanks for the holiday present.
                        >
                        > It'll make life easier to tell people to report:

                        For "people" archive viewers should read "people like me"

                        Thanks Wietse!

                        Simon

                        >   $ postconf -q user@... $(postconf -Rh virtual_alias_maps|tr ',' ' ')
                        >
                        > (and similar recipes) than to have to explain the details in a series
                        > of posts...
                        >
                        > --
                        >         Viktor.

                      • Wietse Venema
                        ... OK, the 20121224 Christmas edition does this and more, and it also produces more warnings. As for the latter I wonder if it will freak out people and
                        Message 11 of 14 , Dec 24, 2012
                        • 0 Attachment
                          Viktor Dukhovni:
                          > Happy new year to you too! Thanks for the holiday present.
                          >
                          > It'll make life easier to tell people to report:
                          >
                          > $ postconf -q user@... $(postconf -Rh virtual_alias_maps|tr ',' ' ')
                          >
                          > (and similar recipes) than to have to explain the details in a series
                          > of posts...

                          OK, the 20121224 Christmas edition does this and more, and it also
                          produces more warnings. As for the latter I wonder if it will freak
                          out people and would need to be shut up at install/upgrade time.

                          Below is a fragment from the current RELEASE_NOTES file.

                          Wietse

                          Major changes with snapshot 20121224
                          ====================================

                          The postconf command has been updated to make trouble-shooting (and
                          support) easier. In summary, use "postconf -Mnxf" and "postconf
                          -nxf" to review master.cf and main.cf parameter settings with
                          expanded parameter values.

                          - "postconf -x" now expands $name in main.cf and master.cf parameter
                          values.

                          - "postconf -Mn" now shows only master.cf entries with "-o name=value"
                          parameter settings.

                          - postconf warns about attempts to modify a read-only parameter
                          (process_name, process_id) in main.cf or master.cf.

                          - postconf warns about an undefined $name in a parameter value in
                          main.cf or master.cf (except for backwards-compatibility parameters
                          such as $virtual_maps).
                        • Ralf Hildebrandt
                          ... Didn t freak me out, but instead it listed an actual error. So it s no big deal. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße
                          Message 12 of 14 , Dec 28, 2012
                          • 0 Attachment
                            * Wietse Venema <postfix-users@...>:

                            > OK, the 20121224 Christmas edition does this and more, and it also
                            > produces more warnings. As for the latter I wonder if it will freak
                            > out people and would need to be shut up at install/upgrade time.

                            Didn't freak me out, but instead it listed an actual error. So it's no
                            big deal.


                            --
                            [*] sys4 AG

                            http://sys4.de, +49 (89) 30 90 46 64
                            Franziskanerstraße 15, 81669 München

                            Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                            Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
                            Aufsichtsratsvorsitzender: Joerg Heidrich
                          Your message has been successfully submitted and would be delivered to recipients shortly.