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

Re: Transport Maps Ignored After Upgrade

Expand Messages
  • Eric Cunningham
    I think I ve found a/the fix for re-enabling the original behavior of my transport maps and MX relaying. I added .$mydomain to mydestination in main.cf. This
    Message 1 of 26 , May 1, 2009
    • 0 Attachment
      I think I've found a/the fix for re-enabling the original behavior of my
      transport maps and MX relaying. I added .$mydomain to mydestination in
      main.cf. This is in addition to $mydomain which was already in
      mydestination.

      $mydomain vs. .$mydomain is subtle but apparently important.
    • Victor Duchovni
      ... Postfix will never search for .example.com domains in the $mydestination list, so this change has no effect. Perhaps in making this change you also
      Message 2 of 26 , May 1, 2009
      • 0 Attachment
        On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:

        > I think I've found a/the fix for re-enabling the original behavior of my
        > transport maps and MX relaying. I added .$mydomain to mydestination in
        > main.cf. This is in addition to $mydomain which was already in
        > mydestination.
        >
        > $mydomain vs. .$mydomain is subtle but apparently important.

        Postfix will never search for ".example.com" domains in the
        $mydestination list, so this change has no effect. Perhaps in making
        this change you also triggered other changes that solved the problem.

        Now, in fact, if you don't set "relay_domains" explicitly, as a matter
        of regrettable backwards compatibility requirements, the value of
        $relay_domains defaults to to "$mydestination" and in the context of
        "$relay_domains", ".example.com" keys do come into play given an
        appropriate setting of parent_domain_matches_subdomains.

        The right solution is to set relay_domains explicitly and correctly,
        rather than rely on side-effects from $mydestination.

        Secondly, it appears that you have changed the default value of
        parent_domain_matches_subdomains. You should review this parameter
        and make sure you understand its impact.

        --
        Viktor.

        Disclaimer: off-list followups get on-list replies or get ignored.
        Please do not ignore the "Reply-To" header.

        To unsubscribe from the postfix-users list, visit
        http://www.postfix.org/lists.html or click the link below:
        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

        If my response solves your problem, the best way to thank me is to not
        send an "it worked, thanks" follow-up. If you must respond, please put
        "It worked, thanks" in the "Subject" so I can delete these quickly.
      • Eric Cunningham
        Thanks Victor. Ok, so I: - removed .$mydomain from $mydestination - have set relay_domains = $mydestination, $mynetworks - have set
        Message 3 of 26 , May 5, 2009
        • 0 Attachment
          Thanks Victor. Ok, so I:

          - removed .$mydomain from $mydestination
          - have set relay_domains = $mydestination, $mynetworks
          - have set parent_domain_matches_subdomains to it's default
          - have added permit_mx_backup to smtpd_recipient_restrictions
          - set permit_mx_backup_networks = $mynetworks

          but I'm still unable to have email accepted for MX'ed hosts or those
          hosts listed in my transport file due to "Relay access denied." Which,
          of these, or any other parameters, should I focus on to correct the
          denial? I've attached a fresh postconf -n for a more detailed & updated
          picture.

          Regards,
          -Eric

          Victor Duchovni wrote:
          > On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:
          >
          >> I think I've found a/the fix for re-enabling the original behavior of my
          >> transport maps and MX relaying. I added .$mydomain to mydestination in
          >> main.cf. This is in addition to $mydomain which was already in
          >> mydestination.
          >>
          >> $mydomain vs. .$mydomain is subtle but apparently important.
          >
          > Postfix will never search for ".example.com" domains in the
          > $mydestination list, so this change has no effect. Perhaps in making
          > this change you also triggered other changes that solved the problem.
          >
          > Now, in fact, if you don't set "relay_domains" explicitly, as a matter
          > of regrettable backwards compatibility requirements, the value of
          > $relay_domains defaults to to "$mydestination" and in the context of
          > "$relay_domains", ".example.com" keys do come into play given an
          > appropriate setting of parent_domain_matches_subdomains.
          >
          > The right solution is to set relay_domains explicitly and correctly,
          > rather than rely on side-effects from $mydestination.
          >
          > Secondly, it appears that you have changed the default value of
          > parent_domain_matches_subdomains. You should review this parameter
          > and make sure you understand its impact.
          >
        • mouss
          ... do not do that. mydestination is for domains that should be delivered locally. mynetworks have nothing to do with reception domains. ... you must
          Message 4 of 26 , May 5, 2009
          • 0 Attachment
            Eric Cunningham a écrit :
            > Thanks Victor. Ok, so I:
            >
            > - removed .$mydomain from $mydestination
            > - have set relay_domains = $mydestination, $mynetworks

            do not do that. mydestination is for domains that should be delivered
            locally. mynetworks have nothing to do with reception domains.


            > - have set parent_domain_matches_subdomains to it's default
            > - have added permit_mx_backup to smtpd_recipient_restrictions
            > - set permit_mx_backup_networks = $mynetworks
            >
            > but I'm still unable to have email accepted for MX'ed hosts or those
            > hosts listed in my transport file due to "Relay access denied."

            you must understand that transport_maps is for routing. this doesn't
            make mail acceptable.

            for postfix to accept mail for a domain (from anywhere), the domain
            needs to be found in one (and only one of):
            - mydestination (this is for mail delivered to a unix account)
            - relay_domains (this is for mail passed to another MTA)
            - virtual_mailbox_domains (this is for mail delivered to a "virtual" user)
            - virtual_alias_domains (this is for mail rewritten to another address
            in another domain)



            > Which,
            > of these, or any other parameters, should I focus on to correct the
            > denial? I've attached a fresh postconf -n for a more detailed & updated
            > picture.
            >
            >[snip]
          • Eric Cunningham
            Thanks mouss. I removed $mynetworks from relay_domains and added the domains found in the transport map to relay_domains (while also keeping them in the
            Message 5 of 26 , May 6, 2009
            • 0 Attachment
              Thanks mouss. I removed $mynetworks from relay_domains and added the
              domains found in the transport map to relay_domains (while also keeping
              them in the transport map). Relaying to those specific domains now works.

              However, MX'd machines still suffer "relay access denied." I introduced
              "relay_recipient_maps =" (both empty and with a file spec) to main.cf
              and with the file specified, tried adding each of the following as an
              entry to /etc/postfix/relay_recipients:

              @... x
              @... x
              eric@... x

              None of those entry attempts had an effect on the relay problem. In
              fact, the mere introduction of relay_recipient_maps re-broke the
              just-fixed relaying. What config parameters and possible values should
              I be looking at to try and resolve MX relay failures? It isn't an
              option for me to specifically list all the MX hosts as there are
              hundreds and that list is not always static. I'm certain Postfix must
              be capable of performing MX lookups and directing the emails accordingly.

              -Eric


              mouss wrote:
              > Eric Cunningham a écrit :
              >> Thanks Victor. Ok, so I:
              >>
              >> - removed .$mydomain from $mydestination
              >> - have set relay_domains = $mydestination, $mynetworks
              >
              > do not do that. mydestination is for domains that should be delivered
              > locally. mynetworks have nothing to do with reception domains.
              >
              >
              >> - have set parent_domain_matches_subdomains to it's default
              >> - have added permit_mx_backup to smtpd_recipient_restrictions
              >> - set permit_mx_backup_networks = $mynetworks
              >>
              >> but I'm still unable to have email accepted for MX'ed hosts or those
              >> hosts listed in my transport file due to "Relay access denied."
              >
              > you must understand that transport_maps is for routing. this doesn't
              > make mail acceptable.
              >
              > for postfix to accept mail for a domain (from anywhere), the domain
              > needs to be found in one (and only one of):
              > - mydestination (this is for mail delivered to a unix account)
              > - relay_domains (this is for mail passed to another MTA)
              > - virtual_mailbox_domains (this is for mail delivered to a "virtual" user)
              > - virtual_alias_domains (this is for mail rewritten to another address
              > in another domain)
            • mouss
              ... as you can see, there is no *_recipient_maps here. if you get relay access denied , then the domain is not listed in one of the above mentioned classes.
              Message 6 of 26 , May 6, 2009
              • 0 Attachment
                Eric Cunningham a écrit :
                > Thanks mouss. I removed $mynetworks from relay_domains and added the
                > domains found in the transport map to relay_domains (while also keeping
                > them in the transport map). Relaying to those specific domains now works.
                >
                > However, MX'd machines still suffer "relay access denied." I introduced
                > "relay_recipient_maps =" (both empty and with a file spec) to main.cf
                > and with the file specified, tried adding each of the following as an
                > entry to /etc/postfix/relay_recipients:
                >
                > @... x
                > @... x
                > eric@... x
                >
                > None of those entry attempts had an effect on the relay problem. In
                > fact, the mere introduction of relay_recipient_maps re-broke the
                > just-fixed relaying. What config parameters and possible values should
                > I be looking at to try and resolve MX relay failures? It isn't an
                > option for me to specifically list all the MX hosts as there are
                > hundreds and that list is not always static. I'm certain Postfix must
                > be capable of performing MX lookups and directing the emails accordingly.
                >

                stop random experimentation. I said this:

                >>
                >> for postfix to accept mail for a domain (from anywhere), the domain
                >> needs to be found in one (and only one of):
                >> - mydestination (this is for mail delivered to a unix account)
                >> - relay_domains (this is for mail passed to another MTA)
                >> - virtual_mailbox_domains (this is for mail delivered to a "virtual"
                >> user)
                >> - virtual_alias_domains (this is for mail rewritten to another address
                >> in another domain)

                as you can see, there is no *_recipient_maps here. if you get "relay
                access denied", then the domain is not listed in one of the above
                mentioned classes.

                if this sin't clear, please show rejection logs (unaltered, unedited) as
                well as output of 'postconf -n' (because it probably changed since your
                last post).
              • Eric Cunningham
                I guess I m still missing something so here s my postfix -n output and logfile showing the rejection. -Eric ... alias_database = hash:/etc/aliases alias_maps
                Message 7 of 26 , May 11, 2009
                • 0 Attachment
                  I guess I'm still missing something so here's my 'postfix -n' output and
                  logfile showing the rejection.

                  -Eric

                  >>> for postfix to accept mail for a domain (from anywhere), the domain
                  >>> needs to be found in one (and only one of):
                  >>> - mydestination (this is for mail delivered to a unix account)
                  >>> - relay_domains (this is for mail passed to another MTA)
                  >>> - virtual_mailbox_domains (this is for mail delivered to a "virtual"
                  >>> user)
                  >>> - virtual_alias_domains (this is for mail rewritten to another address
                  >>> in another domain)
                  >
                  > as you can see, there is no *_recipient_maps here. if you get "relay
                  > access denied", then the domain is not listed in one of the above
                  > mentioned classes.
                  >
                  > if this sin't clear, please show rejection logs (unaltered, unedited) as
                  > well as output of 'postconf -n' (because it probably changed since your
                  > last post).
                  >
                  >
                • /dev/rob0
                  ... ($mydomain is at the default, which should be whoi.edu ) ... These are all your address class definitions. We can t see into your virtual_alias_maps to
                  Message 8 of 26 , May 11, 2009
                  • 0 Attachment
                    On Mon May 11 2009 11:33:37 Eric Cunningham wrote:
                    > I guess I'm still missing something so here's my 'postfix -n' output
                    > and logfile showing the rejection.

                    > >>> for postfix to accept mail for a domain (from anywhere), the
                    > >>> domain needs to be found in one (and only one of):
                    > >>> - mydestination (this is for mail delivered to a unix account)
                    > >>> - relay_domains (this is for mail passed to another MTA)
                    > >>> - virtual_mailbox_domains (this is for mail delivered to a
                    > >>> "virtual" user)
                    > >>> - virtual_alias_domains (this is for mail rewritten to another
                    > >>> address in another domain)
                    > >
                    > > as you can see, there is no *_recipient_maps here. if you get
                    > > "relay access denied", then the domain is not listed in one of the
                    > > above mentioned classes.
                    > >
                    > > if this sin't clear, please show rejection logs (unaltered,
                    > > unedited) as well as output of 'postconf -n' (because it probably
                    > > changed since your last post).

                    > mydestination = $myhostname, obtest.$mydomain, outbox.$mydomain,
                    > mail.$mydomain, localhost.$mydomain, localhost.localdomain,
                    > localhost, beachcomberscompanion.net, whoi.net,
                    > oceansites.org, interridge.org
                    > myhostname = obtest.whoi.edu
                    ($mydomain is at the default, which should be "whoi.edu")
                    > relay_domains = $mydomain, oceanus.whoi.edu,
                    > atlantis.whoi.edu knorr.whoi.edu, bosun.whoi.edu,
                    > striker.whoi.edu, striker2.whoi.edu, sssg1.whoi.edu
                    ...
                    > virtual_alias_domains = $virtual_alias_maps
                    > virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap

                    These are all your address class definitions. We can't see into your
                    virtual_alias_maps to know what domains might be listed there. You can
                    show us "postmap -q sanguine.whoi.edu hash:/etc/postfix/virtual" and
                    "postmap -q sanguine.whoi.edu ldap:vldap".

                    BTW, I always use complete paths for lookups. I think "ldap:vldap"
                    defaults to "ldap:$config_directory/vldap", but it never hurts to be
                    specific, so you know what you're getting.

                    > May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
                    > from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
                    > <eric@...>: Relay access denied;
                    > from=<ecunningham5928@...> to=<eric@...>
                    > proto=SMTP helo=<web62403.mail.re1.yahoo.com>

                    So, sanguine.whoi.edu is apparently not in any of your address class
                    definitions. It doesn't matter what's in transport_maps for this. And
                    it's HIGHLY recommended that you do NOT use transport_maps as a
                    dual-use lookup as an address class definition, because that could
                    cause you to accept mail that's not yours.
                    --
                    Offlist mail to this address is discarded unless
                    "/dev/rob0" or "not-spam" is in Subject: header
                  • Magnus Bäck
                    On Monday, May 11, 2009 at 18:59 CEST, /dev/rob0 wrote: [...] ... ldap:vldap is the legacy configuration method where you d define variables
                    Message 9 of 26 , May 11, 2009
                    • 0 Attachment
                      On Monday, May 11, 2009 at 18:59 CEST,
                      /dev/rob0 <rob0@...> wrote:

                      [...]

                      > BTW, I always use complete paths for lookups. I think "ldap:vldap"
                      > defaults to "ldap:$config_directory/vldap", but it never hurts to
                      > be specific, so you know what you're getting.

                      ldap:vldap is the legacy configuration method where you'd define
                      variables like

                      vldap_server_host = ...
                      vldap_search_base = ...

                      in main.cf. Nothing wrong with that, but that use is deprecated.

                      [...]

                      --
                      Magnus Bäck
                      magnus@...
                    • Eric Cunningham
                      ... Both of those postmap commands returned nothing. ... Correct, sanguine.whoi.edu isn t specifically listed in any of my address class definitions. I m
                      Message 10 of 26 , May 11, 2009
                      • 0 Attachment
                        > ...
                        >> virtual_alias_domains = $virtual_alias_maps
                        >> virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap
                        >
                        > These are all your address class definitions. We can't see into your
                        > virtual_alias_maps to know what domains might be listed there. You can
                        > show us "postmap -q sanguine.whoi.edu hash:/etc/postfix/virtual" and
                        > "postmap -q sanguine.whoi.edu ldap:vldap".

                        Both of those postmap commands returned nothing.


                        >
                        > BTW, I always use complete paths for lookups. I think "ldap:vldap"
                        > defaults to "ldap:$config_directory/vldap", but it never hurts to be
                        > specific, so you know what you're getting.
                        >
                        >> May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
                        >> from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
                        >> <eric@...>: Relay access denied;
                        >> from=<ecunningham5928@...> to=<eric@...>
                        >> proto=SMTP helo=<web62403.mail.re1.yahoo.com>
                        >
                        > So, sanguine.whoi.edu is apparently not in any of your address class
                        > definitions. It doesn't matter what's in transport_maps for this. And
                        > it's HIGHLY recommended that you do NOT use transport_maps as a
                        > dual-use lookup as an address class definition, because that could
                        > cause you to accept mail that's not yours.

                        Correct, sanguine.whoi.edu isn't specifically listed in any of my
                        address class definitions. I'm using it for testing the MX relays, of
                        which I have many.
                      • Noel Jones
                        ... Fix the above error. Probably not directly related to your problem, but might cause unexpected behavior. The fix is probably just: # cp /etc/resolv.conf
                        Message 11 of 26 , May 11, 2009
                        • 0 Attachment
                          Eric Cunningham wrote:

                          > May 11 12:24:19 obtest postfix/postfix-script[4849]: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ

                          Fix the above error. Probably not directly related to your
                          problem, but might cause unexpected behavior. The fix is
                          probably just:

                          # cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf

                          > May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1 <eric@...>: Relay access denied; from=<ecunningham5928@...> to=<eric@...> proto=SMTP helo=<web62403.mail.re1.yahoo.com>

                          Apparently, sanguine.whoi.edu not listed in any of the postfix
                          address classes. Which address class do you expect this to
                          be? Then you'll know where the domain must be listed.

                          This is one document you need to understand:
                          http://www.postfix.org/ADDRESS_CLASS_README.html

                          -- Noel Jones
                        • /dev/rob0
                          ... Thanks for the correction / explanation. I guess those settings in main.cf wouldn t show in postconf -n . ... As expected. ... Yet, DNS points to you:
                          Message 12 of 26 , May 11, 2009
                          • 0 Attachment
                            On Mon May 11 2009 12:08:02 Magnus Bäck wrote:
                            > On Monday, May 11, 2009 at 18:59 CEST,
                            > /dev/rob0 <rob0@...> wrote:
                            >
                            > [...]
                            >
                            > > BTW, I always use complete paths for lookups. I think "ldap:vldap"
                            > > defaults to "ldap:$config_directory/vldap", but it never hurts to
                            > > be specific, so you know what you're getting.
                            >
                            > ldap:vldap is the legacy configuration method where you'd define
                            > variables like
                            >
                            > vldap_server_host = ...
                            > vldap_search_base = ...
                            >
                            > in main.cf. Nothing wrong with that, but that use is deprecated.
                            >
                            > [...]

                            Thanks for the correction / explanation. I guess those settings in
                            main.cf wouldn't show in "postconf -n".

                            On Mon May 11 2009 12:22:20 Eric Cunningham wrote:
                            > > ...
                            > >
                            > >> virtual_alias_domains = $virtual_alias_maps
                            > >> virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap
                            > >
                            > > These are all your address class definitions. We can't see into
                            > > your virtual_alias_maps to know what domains might be listed there.
                            > > You can show us "postmap -q sanguine.whoi.edu
                            > > hash:/etc/postfix/virtual" and "postmap -q sanguine.whoi.edu
                            > > ldap:vldap".
                            >
                            > Both of those postmap commands returned nothing.

                            As expected.

                            > >> May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
                            > >> from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
                            > >> <eric@...>: Relay access denied;
                            > >> from=<ecunningham5928@...> to=<eric@...>
                            > >> proto=SMTP helo=<web62403.mail.re1.yahoo.com>
                            > >
                            > > So, sanguine.whoi.edu is apparently not in any of your address
                            > > class definitions. It doesn't matter what's in transport_maps for
                            > > this. And it's HIGHLY recommended that you do NOT use
                            > > transport_maps as a dual-use lookup as an address class definition,
                            > > because that could cause you to accept mail that's not yours.
                            >
                            > Correct, sanguine.whoi.edu isn't specifically listed in any of my
                            > address class definitions. I'm using it for testing the MX relays,
                            > of which I have many.

                            Yet, DNS points to you:
                            sanguine.whoi.edu. 86400 IN MX 10 obtest.whoi.edu.
                            obtest.whoi.edu. 86400 IN A 128.128.64.226

                            You either need to accept that mail (as a relay domain, perhaps) or
                            change the MX to point to a host that will.
                            --
                            Offlist mail to this address is discarded unless
                            "/dev/rob0" or "not-spam" is in Subject: header
                          • Eric Cunningham
                            ... sanguine.whoi.edu is simply a host that is no longer active on my network. At one point, I received email at that host via eric@sanguine.whoi.edu. Now
                            Message 13 of 26 , May 11, 2009
                            • 0 Attachment
                              Noel Jones wrote:
                              > Apparently, sanguine.whoi.edu not listed in any of the postfix address classes. Which address class do you expect this to be? Then you'll know where the domain must be listed.
                              >
                              > This is one document you need to understand:
                              > http://www.postfix.org/ADDRESS_CLASS_README.html


                              /dev/rob0 wrote:
                              >> Correct, sanguine.whoi.edu isn't specifically listed in any of my
                              >> address class definitions. I'm using it for testing the MX relays,
                              >> of which I have many.
                              >
                              > Yet, DNS points to you:
                              > sanguine.whoi.edu. 86400 IN MX 10 obtest.whoi.edu.
                              > obtest.whoi.edu. 86400 IN A 128.128.64.226
                              >
                              > You either need to accept that mail (as a relay domain, perhaps) or
                              > change the MX to point to a host that will.

                              sanguine.whoi.edu is simply a host that is no longer active on my
                              network. At one point, I received email at that host via
                              eric@.... Now that that's no longer an option, I set up
                              an MX record so that mail destined for sanguine.whoi.edu is relayed to
                              my postfix smtp server and assigned eric@... as an alias
                              for my address in ldap. I want eric@... to continue
                              delivery to my imap account. In fact, that happened perfectly in my
                              previous postfix configuration. Since upgrading postfix, in order for
                              that to continue working, I'm now hearing that I must specifically list
                              sanguine.whoi.edu "somewhere" in my postfix configs. That's not
                              unreasonable, but let's now extend this example to another 250 hosts
                              that are in a similar situation. I must now specifically find, list and
                              maintain all of 250 of those in some postfix config file and that
                              there's no other way this will work as before? That, to me, seems
                              rather unreasonable. Doesn't postfix have the capability to look up MX
                              records for that purpose?
                            • Wietse Venema
                              ... I, the guy who built Postfix, already mentioned that Postfix does not accept mail just because some MX record points to it. That would be extremely
                              Message 14 of 26 , May 11, 2009
                              • 0 Attachment
                                Eric Cunningham:
                                > that to continue working, I'm now hearing that I must specifically list
                                > sanguine.whoi.edu "somewhere" in my postfix configs. That's not
                                > unreasonable, but let's now extend this example to another 250 hosts
                                > that are in a similar situation. I must now specifically find, list and
                                > maintain all of 250 of those in some postfix config file and that
                                > there's no other way this will work as before? That, to me, seems
                                > rather unreasonable. Doesn't postfix have the capability to look up MX
                                > records for that purpose?

                                I, the guy who built Postfix, already mentioned that Postfix does
                                not accept mail just because some MX record points to it. That
                                would be extremely vulnerable to mis-use.

                                Ignore my postings at your own peril.

                                Wietse
                              • Noel Jones
                                ... ... it worked previously due to a bug in permit_mx_backup. That bug has been corrected. ... Yes. ... Correct. You can configure wildcard subdomains to be
                                Message 15 of 26 , May 11, 2009
                                • 0 Attachment
                                  Eric Cunningham wrote:
                                  > I want eric@... to continue
                                  > delivery to my imap account. In fact, that happened perfectly in my
                                  > previous postfix configuration.

                                  ... it worked previously due to a bug in permit_mx_backup.
                                  That bug has been corrected.

                                  > Since upgrading postfix, in order for
                                  > that to continue working, I'm now hearing that I must specifically list
                                  > sanguine.whoi.edu "somewhere" in my postfix configs.

                                  Yes.

                                  > That's not
                                  > unreasonable, but let's now extend this example to another 250 hosts
                                  > that are in a similar situation. I must now specifically find, list and
                                  > maintain all of 250 of those in some postfix config file

                                  Correct. You can configure wildcard subdomains to be
                                  delivered all to one location if that's appropriate for your
                                  configuration.

                                  > and that
                                  > there's no other way this will work as before? That, to me, seems
                                  > rather unreasonable. Doesn't postfix have the capability to look up MX
                                  > records for that purpose?

                                  Postfix can behave as an automatic backup/secondary MX using
                                  permit_mx_backup and protected by permit_mx_backup_networks,
                                  but this specifically excludes domains that list you as the
                                  primary MX, unless those domains are already configured in one
                                  of the postfix address classes.

                                  http://www.postfix.org/postconf.5.html#permit_mx_backup
                                  http://www.postfix.org/postconf.5.html#permit_mx_backup_networks


                                  -- Noel Jones
                                • Eric Cunningham
                                  ... Ahh...finally, someone has clued me in as to -why- this behavior changed. Thank -you- Noel! ... This may be of use in my situation. Can you point me to
                                  Message 16 of 26 , May 11, 2009
                                  • 0 Attachment
                                    Noel Jones wrote:
                                    > Eric Cunningham wrote:
                                    >> I want eric@... to continue delivery to my imap
                                    >> account. In fact, that happened perfectly in my previous postfix
                                    >> configuration.
                                    >
                                    > ... it worked previously due to a bug in permit_mx_backup. That bug has
                                    > been corrected.

                                    Ahh...finally, someone has clued me in as to -why- this behavior
                                    changed. Thank -you- Noel!


                                    >> That's not unreasonable, but let's now extend this example to another
                                    >> 250 hosts that are in a similar situation. I must now specifically
                                    >> find, list and maintain all of 250 of those in some postfix config file
                                    >
                                    > Correct. You can configure wildcard subdomains to be delivered all to
                                    > one location if that's appropriate for your configuration.

                                    This may be of use in my situation. Can you point me to the docs that
                                    explain how to configure wildcard subdomains?

                                    Thanks,

                                    -Eric
                                  • /dev/rob0
                                    ... postconf.5.html#parent_domain_matches_subdomains ... one way pcre_table.5.html ... another way regexp_table.5.html ... another (similar) way The first one
                                    Message 17 of 26 , May 11, 2009
                                    • 0 Attachment
                                      On Mon May 11 2009 14:45:14 Eric Cunningham wrote:
                                      > This may be of use in my situation. Can you point me to the docs
                                      > that explain how to configure wildcard subdomains?

                                      postconf.5.html#parent_domain_matches_subdomains ... one way
                                      pcre_table.5.html ... another way
                                      regexp_table.5.html ... another (similar) way

                                      The first one also shows how to accomplish subdomain matching in hash:
                                      maps.
                                      --
                                      Offlist mail to this address is discarded unless
                                      "/dev/rob0" or "not-spam" is in Subject: header
                                    Your message has been successfully submitted and would be delivered to recipients shortly.