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

Catch-all virtual alias

Expand Messages
  • Christoph Kling
    Hello, I experience undesired strange of Postfix 2.10.2 using the following configuration: -- virtual_alias_domains = virtual_alias_maps = hash file with
    Message 1 of 13 , Nov 10, 2013
      Hello,

      I experience undesired strange of Postfix 2.10.2 using the following
      configuration:

      --
      virtual_alias_domains =

      virtual_alias_maps = hash file with contents:
      "@domain @anotherdomain"

      virtual_mailbox_domains = hash file with contents:
      "@anotherdomain"

      virtual_mailbox_maps = hash file with contents:
      "foo@anotherdomain"

      virtual_transport = dovecot
      --

      If I send a mail to foo@anotherdomain, it is being delivered via
      dovecot.
      If I send a mail to foo@domain, it is being forwarded to
      foo@anotherdomain and then delivered via dovecot.
      If I send a mail to bar@anotherdomain, it is being rejected.

      So far everything as expected.

      But if I send a mail to bar@domain, it is being forwarded to
      bar@anotherdomain and then delivered via dovecot, although
      virtual_mailbox_maps does not contain such an address. Thus,
      virtual_mailbox_maps is being ignored in this case. Delivery takes place
      without authorization from virtual_mailbox_maps.

      The manual for postconf(5)#smptd_reject_unlisted_sender says that 'An
      address is always considered "known" when it matches a virtual(5) alias
      or a canonical(5) mapping.'. According to this, what I saw is expected
      behavior. But should it be this way? Is there any possibility to prevent
      postfix from ignoring virtual_mailbox_maps, except providing each and
      every single destination address in virtual_alias_maps?

      The configuration described is a simplification of my actual
      configuration, which you can find without the actual hostnames at
      http://pastebin.com/8Jx0q68b

      Thank you in advance for your help!

      Regards,
      Christoph
    • Ansgar Wiechers
      ... $virtual_mailbox_domains lists *domains*, so its content should look like this: example.net User mappings, including catch-alls, should go into the
      Message 2 of 13 , Nov 10, 2013
        On 2013-11-10 Christoph Kling wrote:
        > virtual_alias_domains =
        >
        > virtual_alias_maps = hash file with contents:
        > "@domain @anotherdomain"
        >
        > virtual_mailbox_domains = hash file with contents:
        > "@anotherdomain"
        >
        > virtual_mailbox_maps = hash file with contents:
        > "foo@anotherdomain"

        $virtual_mailbox_domains lists *domains*, so its content should look
        like this:

        example.net

        User mappings, including catch-alls, should go into the respective map.
        In case of virtual mailboxes you must map the catch-all to an existing
        mailbox in $virtual_mailbox_maps, e.g.:

        foo@... example.net/foo
        bar@... example.net/bar
        @... example.net/bar

        The catch-all mapping must be the last mapping in the list, and you need
        to make sure that you re-hash the file after it's changed.

        See the VIRTUAL_README [1] for further details.

        Make sure that you don't remove the catch-all as long as you have the
        wildcard domain mapping in $virtual_alias_maps, because you'd produce
        bounces otherwise.

        A better approach (unless you really need a catch-all, which I somehow
        doubt) would be to auto-generate a virtual alias map by reading the
        virtual mailbox map and creating a mapping for each address found in it:

        foo@... foo@...
        bar@... bar@...
        ...

        This can be done with a Makefile or some other script.

        [1] http://www.postfix.org/VIRTUAL_README.html

        Regards
        Ansgar Wiechers
        --
        "Abstractions save us time working, but they don't save us time learning."
        --Joel Spolsky
      • Christoph Kling
        Dear Ansgar and everybody else, in short: I think postfix behavior reflects a bug, not a feature. Please, read again my first email. I hope to make it clear
        Message 3 of 13 , Nov 11, 2013
          Dear Ansgar and everybody else,

          in short: I think postfix' behavior reflects a bug, not a feature.
          Please, read again my first email. I hope to make it clear with the
          following remarks:

          > $virtual_mailbox_domains lists *domains*, so its content should look
          like
          > this:
          >
          > example.net

          I am sorry, you're absolutely right. Actually my mysql tables list only
          pure domain names in virtual_mailbox_domains. By accident, I added the
          '@' in my first email. Thus, there is no problem in this direction.

          > User mappings, including catch-alls, should go into the respective
          map.
          > In case of virtual mailboxes you must map the catch-all to an existing
          mailbox
          > in $virtual_mailbox_maps, e.g.:
          >
          > foo@... example.net/foo
          > bar@... example.net/bar
          > @... example.net/bar

          As described, I don't have any catch-all in virtual_mailbox_maps. What I
          have and what works perfectly is "foo@anotherdomain" in
          virtual_mailbox_maps. It is the only mailbox. Since virtual_transport is
          "dovecot", there is no need to specify the mailbox name here. However,
          if virtual_transport would be "virtual" and if I would specify mailboxes
          here, the problem would be exactly the same.

          The only catch all is in virtual_alias_maps. This catch-all forwards all
          emails from "@domain" to "@anotherdomain", not to a specific user@
          anotherdomain.

          > A better approach (unless you really need a catch-all, which I somehow
          > doubt) would be to auto-generate a virtual alias map by reading the
          virtual
          > mailbox map and creating a mapping for each address found in it:
          >
          > foo@... foo@...
          > bar@... bar@...
          > ...

          Yes, this would be a nice workaround. But it would be much better, if
          postfix would correctly handle virtual alias forwards with the pattern
          @domain -> @anotherdomain, with anotherdomain being a virtual mailbox
          domain. See my original email for a complete example.

          In fact, postfix *ignores* virtual_mailbox_maps when there is a valid
          virtual_alias_maps entry pointing to a virtual mailbox domain, thereby
          creating mailboxes that should not exist and accepting mail that should
          actually be rejected.

          I consider this a bug, not a feature. Neither the manual for
          virtual_mailbox_maps nor the one for virtual_alias_maps says that the
          restriction from virtual_mailbox_maps is being ignored if there is a
          valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I am
          wrong, but I am pretty sure. What do you think?

          Kind regards,
          Christoph
        • Ansgar Wiechers
          ... Don t do this. Ever. Postfix does not recursively resolve wildcard alias mappings, so it correctly translates addresses from one domain to the other, and
          Message 4 of 13 , Nov 11, 2013
            On 2013-11-11 Christoph Kling wrote:
            >> User mappings, including catch-alls, should go into the respective
            >> map. In case of virtual mailboxes you must map the catch-all to an
            >> existing mailbox in $virtual_mailbox_maps, e.g.:
            >>
            >> foo@... example.net/foo
            >> bar@... example.net/bar
            >> @... example.net/bar
            >
            > As described, I don't have any catch-all in virtual_mailbox_maps. What
            > I have and what works perfectly is "foo@anotherdomain" in
            > virtual_mailbox_maps. It is the only mailbox. Since virtual_transport
            > is "dovecot", there is no need to specify the mailbox name here.
            > However, if virtual_transport would be "virtual" and if I would
            > specify mailboxes here, the problem would be exactly the same.
            >
            > The only catch all is in virtual_alias_maps. This catch-all forwards
            > all emails from "@domain" to "@anotherdomain", not to a specific user@
            > anotherdomain.

            Don't do this. Ever. Postfix does not recursively resolve wildcard alias
            mappings, so it correctly translates addresses from one domain to the
            other, and bounces if the outcome is not a valid mailbox or forward.

            Besides, the VIRTUAL_README that I already referred you to clearly
            states:

            NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!!

            >> A better approach (unless you really need a catch-all, which I
            >> somehow doubt) would be to auto-generate a virtual alias map by
            >> reading the virtual mailbox map and creating a mapping for each
            >> address found in it:
            >>
            >> foo@... foo@...
            >> bar@... bar@...
            >> ...
            >
            > Yes, this would be a nice workaround. But it would be much better, if
            > postfix would correctly handle virtual alias forwards with the pattern
            > @domain -> @anotherdomain, with anotherdomain being a virtual mailbox
            > domain. See my original email for a complete example.
            >
            > In fact, postfix *ignores* virtual_mailbox_maps when there is a valid
            > virtual_alias_maps entry pointing to a virtual mailbox domain, thereby
            > creating mailboxes that should not exist and accepting mail that
            > should actually be rejected.

            No. Postfix behaves as documented, but you chose to ignore the
            documentation. Don't blame Postfix for your own negligence.

            > I consider this a bug, not a feature. Neither the manual for
            > virtual_mailbox_maps nor the one for virtual_alias_maps says that the
            > restriction from virtual_mailbox_maps is being ignored if there is a
            > valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I
            > am wrong, but I am pretty sure. What do you think?

            You're free to file a bug report, but I can practically guarantee you
            that it will be discarded, since the virtual mailbox configuration
            example in the VIRTUAL_README clearly tells you not to do what you're
            doing.

            Regards
            Ansgar Wiechers
            --
            "Abstractions save us time working, but they don't save us time learning."
            --Joel Spolsky
          • Viktor Dukhovni
            ... It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @example.org with @example.net. So I would not say that the
            Message 5 of 13 , Nov 11, 2013
              On Mon, Nov 11, 2013 at 07:18:01PM +0100, Ansgar Wiechers wrote:

              > > I consider this a bug, not a feature. Neither the manual for
              > > virtual_mailbox_maps nor the one for virtual_alias_maps says that the
              > > restriction from virtual_mailbox_maps is being ignored if there is a
              > > valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I
              > > am wrong, but I am pretty sure. What do you think?
              >
              > You're free to file a bug report, but I can practically guarantee you
              > that it will be discarded, since the virtual mailbox configuration
              > example in the VIRTUAL_README clearly tells you not to do what you're
              > doing.

              It is not entirely unreasonable to expect address validation to
              handle 1-to-1 aliasing of @... with @.... So I
              would not say that the request will be discarded, but a correct
              implementation of such rewriting would be a major change in Postfix
              internals and user interface and would be more than a "bug fix".

              Perhaps in Postfix 3.0 (yes I do recall the thread where nobody
              voted for 3.0). Arguably, since canonical mapping is restricted
              to be 1-to-1, Postfix smtpd(8) could expand canonical mappings
              before validating addresses, but it is not clear that this would
              be sufficient.

              Validation with 1-to-many mappings (virtual rewriting) is a pain.
              You pay the full cost of expanding a large group just to verify
              that it exists, such expansion can be rather time consuming. SMTP
              clients are generally more patient after "." than after "RCPT TO".

              I've built configurations where smptd(8) sees a different definition
              of virtual_alias_maps than cleanup(8). The smtpd(8) version just
              checks for a group's existence (maps mail->mail), while the cleanup(8)
              version expands the group to its list of members (maps mail->{member-maildrop}).

              Suffice it to say that for the moment people have learned to live
              with the limitation.

              Perhaps the right solution is to define a new 1-to-1 rewriting
              mechanism that is applied to "RCPT TO" directly by smtpd(8) before
              validation. This would be a more suitable mechanism for the task
              than smtpd_command_filter that would be more accurate than fiddling
              with regexps and can use additional lookup tables.

              Anyway this requires new inspiration to build just right the first
              time.

              --
              Viktor.
            • Charles Marcus
              ... Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so,
              Message 6 of 13 , Nov 11, 2013
                On 2013-11-11 2:30 PM, Viktor Dukhovni <postfix-users@...> wrote:
                It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @... with @....

                Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way...

                --

                Best regards,

                Charles
              • Christoph Kling
                Hi, I would like to thank all of you for your helpful remarks. It would be great if postfix would support such aliases in the future and I understood that the
                Message 7 of 13 , Nov 12, 2013

                  Hi,

                   

                  I would like to thank all of you for your helpful remarks. It would be great if postfix would support such aliases in the future and I understood that the current behavior is correctly documented in the virtual readme file. However, some hint in the postconf manual probably would be helpful.

                   

                  Kind regards,

                  Christoph

                   

                  From: owner-postfix-users@... [mailto:owner-postfix-users@postfix.org] On Behalf Of Charles Marcus
                  Sent: Monday, November 11, 2013 9:59 PM
                  To: postfix-users@...
                  Subject: Re: Catch-all virtual alias

                   

                  On 2013-11-11 2:30 PM, Viktor Dukhovni <postfix-users@...> wrote:

                  It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @... with @....


                  Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way...

                  --

                  Best regards,

                  Charles

                • /dev/rob0
                  ... No programming is necessary; all you need is SQL. Most simply, a query which receives input of user@example.org and then does a lookup of
                  Message 8 of 13 , Nov 12, 2013
                    On Mon, Nov 11, 2013 at 03:59:11PM -0500, Charles Marcus wrote:
                    > On 2013-11-11 2:30 PM, Viktor Dukhovni
                    > <postfix-users@...> wrote:
                    > >It is not entirely unreasonable to expect address validation
                    > >to handle 1-to-1 aliasing of @... with @....
                    >
                    > Postfixadmin, an excellent tool for managing userdbs in
                    > mysql/postgresql, has had 1-to-1 domain aliasing for a long
                    > time, and it works just fine... so, unltil postfix supports
                    > this natively, it can still be done now, and if you don't want
                    > to use postfixadmin, I'm sure a competent programmer could
                    > 'use the source' and implement it their own way...

                    No programming is necessary; all you need is SQL. Most simply, a
                    query which receives input of "user@..." and then does a
                    lookup of "user@...".

                    A well-thought-out SQL schema can automate this. Similarly, LDAP
                    offers means of doing this. For those using neither SQL nor LDAP,
                    trivial scripting can generate and maintain complete user maps.

                    As Viktor said, while a domain aliasing feature might be worth
                    considering for an eventual Postfix 3.0, it's probably not worth
                    implementing here in Postfix 2.x. Maybe a few examples added to
                    VIRTUAL_README?
                    --
                    http://rob0.nodns4.us/ -- system administration and consulting
                    Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                  • Wietse Venema
                    ... I welcome *SQL and LDAP examples. As for fixing Postfix recipient address validation, doing a half-assed job that handles only @domain- @domain and other
                    Message 9 of 13 , Nov 12, 2013
                      /dev/rob0:
                      > On Mon, Nov 11, 2013 at 03:59:11PM -0500, Charles Marcus wrote:
                      > > On 2013-11-11 2:30 PM, Viktor Dukhovni
                      > > <postfix-users@...> wrote:
                      > > >It is not entirely unreasonable to expect address validation
                      > > >to handle 1-to-1 aliasing of @... with @....
                      > >
                      > > Postfixadmin, an excellent tool for managing userdbs in
                      > > mysql/postgresql, has had 1-to-1 domain aliasing for a long
                      > > time, and it works just fine... so, unltil postfix supports
                      > > this natively, it can still be done now, and if you don't want
                      > > to use postfixadmin, I'm sure a competent programmer could
                      > > 'use the source' and implement it their own way...
                      >
                      > No programming is necessary; all you need is SQL. Most simply, a
                      > query which receives input of "user@..." and then does a
                      > lookup of "user@...".
                      >
                      > A well-thought-out SQL schema can automate this. Similarly, LDAP
                      > offers means of doing this. For those using neither SQL nor LDAP,
                      > trivial scripting can generate and maintain complete user maps.
                      >
                      > As Viktor said, while a domain aliasing feature might be worth
                      > considering for an eventual Postfix 3.0, it's probably not worth
                      > implementing here in Postfix 2.x. Maybe a few examples added to
                      > VIRTUAL_README?

                      I welcome *SQL and LDAP examples.

                      As for 'fixing' Postfix recipient address validation, doing a
                      half-assed job that handles only @domain->@domain and other 1-1
                      canonical/virtual alias mappings may not be hard, but doing a
                      complete job would require a redesign.

                      Wietse
                    • /dev/rob0
                      ... I ll do one for sqlite (which would also work for pgsql), if no one beats me to it. :) -- http://rob0.nodns4.us/ -- system administration and consulting
                      Message 10 of 13 , Nov 12, 2013
                        On Tue, Nov 12, 2013 at 11:45:51AM -0500, Wietse Venema wrote:
                        > /dev/rob0:
                        > > As Viktor said, while a domain aliasing feature might be
                        > > worth considering for an eventual Postfix 3.0, it's probably
                        > > not worth implementing here in Postfix 2.x. Maybe a few
                        > > examples added to VIRTUAL_README?
                        >
                        > I welcome *SQL and LDAP examples.

                        I'll do one for sqlite (which would also work for pgsql), if no one
                        beats me to it. :)
                        --
                        http://rob0.nodns4.us/ -- system administration and consulting
                        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                      • Noel Jones
                        ... Recipient address verification currently has some blind spots. Reducing those blind spots -- even if they can t be totally eliminated -- is still an
                        Message 11 of 13 , Nov 12, 2013
                          On 11/12/2013 10:45 AM, Wietse Venema wrote:

                          > As for 'fixing' Postfix recipient address validation, doing a
                          > half-assed job that handles only @domain->@domain and other 1-1
                          > canonical/virtual alias mappings may not be hard, but doing a
                          > complete job would require a redesign.
                          >
                          > Wietse
                          >


                          Recipient address verification currently has some blind spots.
                          Reducing those blind spots -- even if they can't be totally
                          eliminated -- is still an improvement.


                          -- Noel Jones
                        • Wietse Venema
                          ... Yes, I was just lowering expectations. A redesign is not in the budget, but the half-assed job may actually happen. Wietse
                          Message 12 of 13 , Nov 12, 2013
                            Noel Jones:
                            > On 11/12/2013 10:45 AM, Wietse Venema wrote:
                            >
                            > > As for 'fixing' Postfix recipient address validation, doing a
                            > > half-assed job that handles only @domain->@domain and other 1-1
                            > > canonical/virtual alias mappings may not be hard, but doing a
                            > > complete job would require a redesign.
                            >
                            > Recipient address verification currently has some blind spots.
                            > Reducing those blind spots -- even if they can't be totally
                            > eliminated -- is still an improvement.

                            Yes, I was just lowering expectations. A redesign is not in the
                            budget, but the half-assed job may actually happen.

                            Wietse
                          • Noel Jones
                            ... Not too slow, not too fast. Just kind of half-fast.
                            Message 13 of 13 , Nov 12, 2013
                              On 11/12/2013 2:20 PM, Wietse Venema wrote:
                              > Noel Jones:
                              >> On 11/12/2013 10:45 AM, Wietse Venema wrote:
                              >>
                              >>> As for 'fixing' Postfix recipient address validation, doing a
                              >>> half-assed job that handles only @domain->@domain and other 1-1
                              >>> canonical/virtual alias mappings may not be hard, but doing a
                              >>> complete job would require a redesign.
                              >>
                              >> Recipient address verification currently has some blind spots.
                              >> Reducing those blind spots -- even if they can't be totally
                              >> eliminated -- is still an improvement.
                              >
                              > Yes, I was just lowering expectations. A redesign is not in the
                              > budget, but the half-assed job may actually happen.
                              >
                              > Wietse
                              >


                              Not too slow, not too fast. Just kind of half-fast.
                            Your message has been successfully submitted and would be delivered to recipients shortly.