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

LMTP delivery failover

Expand Messages
  • Quanah Gibson-Mount
    As part of making Zimbra more robust, we re abstracting our data layer. Currently, LMTP delivery is configured to point at a specific mailstore, which accepts
    Message 1 of 20 , Jan 27, 2014
      As part of making Zimbra more robust, we're abstracting our data layer.
      Currently, LMTP delivery is configured to point at a specific mailstore,
      which accepts delivery and stores the email in a SQL database. As part of
      the abstraction, we're moving to a SQL cluster, which means that LMTP
      delivery can be to any mailstore for any user. The general idea is that
      there should be no dependency on any given mailstore for the system to
      function.

      However, postfix LMTP seems to only take a single destination address
      (please correct me if I'm wrong. ;) ). A possible solution we've
      considered is requiring a load balancer be deployed between postfix and the
      mailstores. Another potential solution would be if postfix could take a
      list of LMTP destinations and failover between them, similarly to what is
      done with LDAP URLs. Other thoughts welcome.

      Thanks!

      --Quanah

      --

      Quanah Gibson-Mount
      Architect - Server
      Zimbra, Inc.
      --------------------
      Zimbra :: the leader in open source messaging and collaboration
    • Wietse Venema
      ... The Postfix scheduler does not do lists of destinations, and I am not inclined to change that for LMTP. Before inventing new lookup mechanisms, have you
      Message 2 of 20 , Jan 27, 2014
        Quanah Gibson-Mount:
        > As part of making Zimbra more robust, we're abstracting our data layer.
        > Currently, LMTP delivery is configured to point at a specific mailstore,
        > which accepts delivery and stores the email in a SQL database. As part of
        > the abstraction, we're moving to a SQL cluster, which means that LMTP
        > delivery can be to any mailstore for any user. The general idea is that
        > there should be no dependency on any given mailstore for the system to
        > function.
        >
        > However, postfix LMTP seems to only take a single destination address
        > (please correct me if I'm wrong. ;) ). A possible solution we've
        > considered is requiring a load balancer be deployed between postfix and the
        > mailstores. Another potential solution would be if postfix could take a
        > list of LMTP destinations and failover between them, similarly to what is
        > done with LDAP URLs. Other thoughts welcome.

        The Postfix scheduler does not do lists of destinations, and I am
        not inclined to change that for LMTP.

        Before inventing new lookup mechanisms, have you considered the
        possibility of making the existing mechanisms available for LMTP?

        - Using multiple A records per name? If all hosts are equivalent
        that would be the way to go.

        - Using MX lookups, and multiple MX records per name? This would
        make sense if some hosts are more preferred than others.

        - Using smtp_fallback_relay? I don't know if that would be applicable
        for LMTP-based storage access.

        All three scenarios could take advantage of Postfix connection
        caching to avoid wasting time on dead hosts.

        Wietse
      • Viktor Dukhovni
        ... You can use a load balancer, or a round-robin A record. The LMTP code is just SMTP without MX lookups and with unix-domain socket support. So an LMTP
        Message 3 of 20 , Jan 27, 2014
          On Mon, Jan 27, 2014 at 12:18:44PM -0800, Quanah Gibson-Mount wrote:

          > However, postfix LMTP seems to only take a single destination
          > address (please correct me if I'm wrong. ;) ). A possible solution
          > we've considered is requiring a load balancer be deployed between
          > postfix and the mailstores. Another potential solution would be if
          > postfix could take a list of LMTP destinations and failover between
          > them, similarly to what is done with LDAP URLs. Other thoughts
          > welcome.

          You can use a load balancer, or a round-robin A record. The LMTP
          code is just SMTP without MX lookups and with unix-domain socket
          support. So an LMTP "inet:host:port" destination is equivalent to
          an SMTP "[host]:port" destination. Note, on most modern systems
          multiple entries in /etc/hosts work pretty much the same as a
          round-robin DNS entry.

          --
          Viktor.
        • Wietse Venema
          ... This can also be used to implement unequal preferences, by listing an IP address multiple times. Postfix will by default randomly shuffle the address list.
          Message 4 of 20 , Jan 27, 2014
            Wietse Venema:
            > Quanah Gibson-Mount:
            > > As part of making Zimbra more robust, we're abstracting our data layer.
            > > Currently, LMTP delivery is configured to point at a specific mailstore,
            > > which accepts delivery and stores the email in a SQL database. As part of
            > > the abstraction, we're moving to a SQL cluster, which means that LMTP
            > > delivery can be to any mailstore for any user. The general idea is that
            > > there should be no dependency on any given mailstore for the system to
            > > function.
            > >
            > > However, postfix LMTP seems to only take a single destination address
            > > (please correct me if I'm wrong. ;) ). A possible solution we've
            > > considered is requiring a load balancer be deployed between postfix and the
            > > mailstores. Another potential solution would be if postfix could take a
            > > list of LMTP destinations and failover between them, similarly to what is
            > > done with LDAP URLs. Other thoughts welcome.
            >
            > The Postfix scheduler does not do lists of destinations, and I am
            > not inclined to change that for LMTP.
            >
            > Before inventing new lookup mechanisms, have you considered the
            > possibility of making the existing mechanisms available for LMTP?
            >
            > - Using multiple A records per name? If all hosts are equivalent
            > that would be the way to go.

            This can also be used to implement unequal preferences, by listing
            an IP address multiple times. Postfix will by default randomly
            shuffle the address list.

            > - Using MX lookups, and multiple MX records per name? This would
            > make sense if some hosts are more preferred than others.

            This requires some SMTP client code duplication. because MX lookups
            are not part of the LMTP protocol spec.

            > - Using smtp_fallback_relay? I don't know if that would be applicable
            > for LMTP-based storage access.

            This also requires some some SMTP client code duplication.

            > All three scenarios could take advantage of Postfix connection
            > caching to avoid wasting time on dead hosts.
            >
            > Wietse
            >
          • Viktor Dukhovni
            ... Indeed, MX records are out scope for LMTP. To load-balance LMTP in a manner similar to MX records would require SRV record support. Which would
            Message 5 of 20 , Jan 27, 2014
              On Mon, Jan 27, 2014 at 03:53:19PM -0500, Wietse Venema wrote:

              > > Before inventing new lookup mechanisms, have you considered the
              > > possibility of making the existing mechanisms available for LMTP?
              > >
              > > - Using multiple A records per name? If all hosts are equivalent
              > > that would be the way to go.
              >
              > This can also be used to implement unequal preferences, by listing
              > an IP address multiple times. Postfix will by default randomly
              > shuffle the address list.

              Perhaps, but see below:

              > > - Using MX lookups, and multiple MX records per name? This would
              > > make sense if some hosts are more preferred than others.
              >
              > This requires some SMTP client code duplication. because MX lookups
              > are not part of the LMTP protocol spec.

              Indeed, MX records are out scope for LMTP. To load-balance LMTP
              in a manner similar to MX records would require SRV record support.
              Which would (hypothetically) also take care of any desire for
              weighting. I am not eager to add SRV support, but it is doable
              in principle.

              --
              Viktor.
            • Wietse Venema
              ... I agree that we hold off on new mechanisms until a need exists. Equal-preference A records should solve 90% of the problem. By not solving the remaining
              Message 6 of 20 , Jan 27, 2014
                Viktor Dukhovni:
                > On Mon, Jan 27, 2014 at 03:53:19PM -0500, Wietse Venema wrote:
                >
                > > > Before inventing new lookup mechanisms, have you considered the
                > > > possibility of making the existing mechanisms available for LMTP?
                > > >
                > > > - Using multiple A records per name? If all hosts are equivalent
                > > > that would be the way to go.
                > >
                > > This can also be used to implement unequal preferences, by listing
                > > an IP address multiple times. Postfix will by default randomly
                > > shuffle the address list.
                >
                > Perhaps, but see below:
                >
                > > > - Using MX lookups, and multiple MX records per name? This would
                > > > make sense if some hosts are more preferred than others.
                > >
                > > This requires some SMTP client code duplication. because MX lookups
                > > are not part of the LMTP protocol spec.
                >
                > Indeed, MX records are out scope for LMTP. To load-balance LMTP
                > in a manner similar to MX records would require SRV record support.
                > Which would (hypothetically) also take care of any desire for
                > weighting. I am not eager to add SRV support, but it is doable
                > in principle.

                I agree that we hold off on new mechanisms until a need exists.
                Equal-preference A records should solve 90% of the problem. By not
                solving the remaining 10% at great effort, we can spend the limited
                development cycles more wisely.

                Wietse
              • Quanah Gibson-Mount
                --On Monday, January 27, 2014 4:54 PM -0500 Wietse Venema ... Thanks! I ll propose Round Robin DNS or load balancers as the solution then. Overall, it would
                Message 7 of 20 , Jan 27, 2014
                  --On Monday, January 27, 2014 4:54 PM -0500 Wietse Venema
                  <wietse@...> wrote:

                  > I agree that we hold off on new mechanisms until a need exists.
                  > Equal-preference A records should solve 90% of the problem. By not
                  > solving the remaining 10% at great effort, we can spend the limited
                  > development cycles more wisely.

                  Thanks! I'll propose Round Robin DNS or load balancers as the solution
                  then. Overall, it would be most effective (for Zimbra) to have it prefer
                  the user's "home" mailstore and then fall back if that wasn't available,
                  but that would be tricky to implement anywhere in the stack (but more
                  closely aligns with LDAP URLs).

                  --Quanah

                  --

                  Quanah Gibson-Mount
                  Architect - Server
                  Zimbra, Inc.
                  --------------------
                  Zimbra :: the leader in open source messaging and collaboration
                • Viktor Dukhovni
                  ... Actually, that is not too difficult. Just specify a round-robin name as the lmtp_fallback_relay (new feature). While adding SRV support is tricky,
                  Message 8 of 20 , Jan 27, 2014
                    On Mon, Jan 27, 2014 at 02:30:24PM -0800, Quanah Gibson-Mount wrote:

                    > >I agree that we hold off on new mechanisms until a need exists.
                    > >Equal-preference A records should solve 90% of the problem. By not
                    > >solving the remaining 10% at great effort, we can spend the limited
                    > >development cycles more wisely.
                    >
                    > Thanks! I'll propose Round Robin DNS or load balancers as the
                    > solution then. Overall, it would be most effective (for Zimbra) to
                    > have it prefer the user's "home" mailstore and then fall back if
                    > that wasn't available, but that would be tricky to implement
                    > anywhere in the stack (but more closely aligns with LDAP URLs).

                    Actually, that is not too difficult. Just specify a round-robin
                    name as the "lmtp_fallback_relay" (new feature). While adding SRV
                    support is tricky, adding "lmtp_fallback_relay" is I think quite
                    simple.

                    --
                    Viktor.
                  • Quanah Gibson-Mount
                    --On Monday, January 27, 2014 10:32 PM +0000 Viktor Dukhovni ... That would be cool. We store all the servers in LDAP, and use LMTP to look up the target
                    Message 9 of 20 , Jan 27, 2014
                      --On Monday, January 27, 2014 10:32 PM +0000 Viktor Dukhovni
                      <postfix-users@...> wrote:


                      > Actually, that is not too difficult. Just specify a round-robin
                      > name as the "lmtp_fallback_relay" (new feature). While adding SRV
                      > support is tricky, adding "lmtp_fallback_relay" is I think quite
                      > simple.

                      That would be cool. We store all the servers in LDAP, and use LMTP to look
                      up the target mailstore for a user now, so we could have the default LMTP
                      use the LDAP lookup for their primary store, and then use the fallback
                      relay do a LDAP lookup that returns a list of the other servers if that one
                      is down.

                      --Quanah


                      --

                      Quanah Gibson-Mount
                      Architect - Server
                      Zimbra, Inc.
                      --------------------
                      Zimbra :: the leader in open source messaging and collaboration
                    • Quanah Gibson-Mount
                      --On Monday, January 27, 2014 2:36 PM -0800 Quanah Gibson-Mount ... Correction. ;) LDAP lookup that returns the RRDNS name for the fallback relay. --Quanah --
                      Message 10 of 20 , Jan 27, 2014
                        --On Monday, January 27, 2014 2:36 PM -0800 Quanah Gibson-Mount
                        <quanah@...> wrote:

                        > --On Monday, January 27, 2014 10:32 PM +0000 Viktor Dukhovni
                        > <postfix-users@...> wrote:
                        >
                        >
                        >> Actually, that is not too difficult. Just specify a round-robin
                        >> name as the "lmtp_fallback_relay" (new feature). While adding SRV
                        >> support is tricky, adding "lmtp_fallback_relay" is I think quite
                        >> simple.
                        >
                        > That would be cool. We store all the servers in LDAP, and use LMTP to
                        > look up the target mailstore for a user now, so we could have the default
                        > LMTP use the LDAP lookup for their primary store, and then use the
                        > fallback relay do a LDAP lookup that returns a list of the other servers
                        > if that one is down.

                        Correction. ;) LDAP lookup that returns the RRDNS name for the fallback
                        relay.

                        --Quanah

                        --

                        Quanah Gibson-Mount
                        Architect - Server
                        Zimbra, Inc.
                        --------------------
                        Zimbra :: the leader in open source messaging and collaboration
                      • Viktor Dukhovni
                        ... The fallback relay setting is a fixed per-transport setting. So the fallback relay would not be per-user. Only the first LMTP server to try (per-user
                        Message 11 of 20 , Jan 27, 2014
                          On Mon, Jan 27, 2014 at 02:38:01PM -0800, Quanah Gibson-Mount wrote:

                          > >>Actually, that is not too difficult. Just specify a round-robin
                          > >>name as the "lmtp_fallback_relay" (new feature). While adding SRV
                          > >>support is tricky, adding "lmtp_fallback_relay" is I think quite
                          > >>simple.
                          > >
                          > >That would be cool. We store all the servers in LDAP, and use LDAP to
                          > >look up the target mailstore for a user now, so we could have the default
                          > >LMTP use the LDAP lookup for their primary store, and then use the
                          > >fallback relay do a LDAP lookup that returns a list of the other servers
                          > >if that one is down.

                          The fallback relay setting is a fixed per-transport setting. So
                          the fallback relay would not be per-user. Only the first LMTP
                          server to try (per-user transport table). Each transport carries
                          a fixed fallback relay in master.cf.

                          So you'd have one transport per "cluster" of mailstores, and an
                          associated fallback that uses the clust round-robin address. The
                          user's transport entry would direct the first delivery attempt to
                          "somelmtp:primary-store:port" if it is best to not simply round-robin
                          the deliveries and sending each user's mail to the primary destination
                          for that user is substantially better.

                          --
                          Viktor.
                        • Quanah Gibson-Mount
                          --On Monday, January 27, 2014 10:45 PM +0000 Viktor Dukhovni ... Ok, makes sense. That would work well. Thanks! --Quanah -- Quanah Gibson-Mount Architect -
                          Message 12 of 20 , Jan 27, 2014
                            --On Monday, January 27, 2014 10:45 PM +0000 Viktor Dukhovni
                            <postfix-users@...> wrote:

                            > On Mon, Jan 27, 2014 at 02:38:01PM -0800, Quanah Gibson-Mount wrote:
                            >
                            >> >> Actually, that is not too difficult. Just specify a round-robin
                            >> >> name as the "lmtp_fallback_relay" (new feature). While adding SRV
                            >> >> support is tricky, adding "lmtp_fallback_relay" is I think quite
                            >> >> simple.
                            >> >
                            >> > That would be cool. We store all the servers in LDAP, and use LDAP to
                            >> > look up the target mailstore for a user now, so we could have the
                            >> > default LMTP use the LDAP lookup for their primary store, and then use
                            >> > the fallback relay do a LDAP lookup that returns a list of the other
                            >> > servers if that one is down.
                            >
                            > The fallback relay setting is a fixed per-transport setting. So
                            > the fallback relay would not be per-user. Only the first LMTP
                            > server to try (per-user transport table). Each transport carries
                            > a fixed fallback relay in master.cf.
                            >
                            > So you'd have one transport per "cluster" of mailstores, and an
                            > associated fallback that uses the clust round-robin address. The
                            > user's transport entry would direct the first delivery attempt to
                            > "somelmtp:primary-store:port" if it is best to not simply round-robin
                            > the deliveries and sending each user's mail to the primary destination
                            > for that user is substantially better.

                            Ok, makes sense. That would work well. Thanks!

                            --Quanah


                            --

                            Quanah Gibson-Mount
                            Architect - Server
                            Zimbra, Inc.
                            --------------------
                            Zimbra :: the leader in open source messaging and collaboration
                          • Andrzej A. Filip
                            ... Do you plan to support SRV DNS records in a few years perspective? https://en.wikipedia.org/wiki/SRV_record
                            Message 13 of 20 , Jan 27, 2014
                              On 01/27/2014 09:37 PM, Wietse Venema wrote:
                              > Quanah Gibson-Mount:
                              >> As part of making Zimbra more robust, we're abstracting our data layer.
                              >> Currently, LMTP delivery is configured to point at a specific mailstore,
                              >> which accepts delivery and stores the email in a SQL database. As part of
                              >> the abstraction, we're moving to a SQL cluster, which means that LMTP
                              >> delivery can be to any mailstore for any user. The general idea is that
                              >> there should be no dependency on any given mailstore for the system to
                              >> function.
                              >>
                              >> However, postfix LMTP seems to only take a single destination address
                              >> (please correct me if I'm wrong. ;) ). A possible solution we've
                              >> considered is requiring a load balancer be deployed between postfix and the
                              >> mailstores. Another potential solution would be if postfix could take a
                              >> list of LMTP destinations and failover between them, similarly to what is
                              >> done with LDAP URLs. Other thoughts welcome.
                              >
                              > The Postfix scheduler does not do lists of destinations, and I am
                              > not inclined to change that for LMTP.
                              >
                              > Before inventing new lookup mechanisms, have you considered the
                              > possibility of making the existing mechanisms available for LMTP?
                              >
                              > - Using multiple A records per name? If all hosts are equivalent
                              > that would be the way to go.
                              >
                              > - Using MX lookups, and multiple MX records per name? This would
                              > make sense if some hosts are more preferred than others.
                              >
                              > - Using smtp_fallback_relay? I don't know if that would be applicable
                              > for LMTP-based storage access.
                              >
                              > All three scenarios could take advantage of Postfix connection
                              > caching to avoid wasting time on dead hosts.
                              >
                              > Wietse


                              Do you plan to support SRV DNS records in a few years perspective?

                              https://en.wikipedia.org/wiki/SRV_record
                            • Wietse Venema
                              ... What real problem does this solve? Developer cycles are finite and must be spent wisely. Wietse
                              Message 14 of 20 , Jan 27, 2014
                                Andrzej A. Filip:
                                > Do you plan to support SRV DNS records in a few years perspective?

                                What real problem does this solve? Developer cycles are finite
                                and must be spent wisely.

                                Wietse
                              • Viktor Dukhovni
                                ... The patch below may not even compile, but probably works, give it a try. As you can see, it is mostly a matter of adding a bit of documentation and
                                Message 15 of 20 , Jan 27, 2014
                                  On Mon, Jan 27, 2014 at 02:51:20PM -0800, Quanah Gibson-Mount wrote:

                                  > >The fallback relay setting is a fixed per-transport setting. So
                                  > >the fallback relay would not be per-user. Only the first LMTP
                                  > >server to try (per-user transport table). Each transport carries
                                  > >a fixed fallback relay in master.cf.
                                  > >
                                  > >So you'd have one transport per "cluster" of mailstores, and an
                                  > >associated fallback that uses the cluster round-robin address. The
                                  > >user's transport entry would direct the first delivery attempt to
                                  > >"somelmtp:primary-store:port" if it is best to not simply round-robin
                                  > >the deliveries and sending each user's mail to the primary destination
                                  > >for that user is substantially better.
                                  >
                                  > Ok, makes sense. That would work well. Thanks!

                                  The patch below may not even compile, but probably works, give it a try.
                                  As you can see, it is mostly a matter of adding a bit of documentation
                                  and disabling conditionals that make existing code apply only to SMTP.

                                  If it works well for you, and Wietse is not opposed to an
                                  "lmtp_fallback_relay" feature, something like this could be part
                                  of Postfix 2.12.

                                  diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto
                                  index bba32ac..18e6288 100644
                                  --- a/postfix/proto/postconf.proto
                                  +++ b/postfix/proto/postconf.proto
                                  @@ -1492,6 +1492,25 @@ as the right-hand side for backup or primary MX domain entries.
                                  for destinations that it is MX host for.
                                  </p>

                                  +%PARAM lmtp_fallback_relay
                                  +
                                  +<p> Optional list of relay hosts for LMTP destinations that can't be
                                  +found or that are unreachable. In main.cf elements are separated by
                                  +whitespace or commas. </p>
                                  +
                                  +<p> By default, mail is returned to the sender when a destination is not
                                  +found, and delivery is deferred when a destination is unreachable. </p>
                                  +
                                  +<p> The fallback relays must be TCP LMTP destinations, specified without
                                  +a leading "inet:" prefix. Specify a host or host:port. Since MX
                                  +lookups do not apply with LMTP, there is no need to use the "[host]" or
                                  +"[host]:port" forms. If you specify multiple LMTP destinations, Postfix
                                  +will try them in the specified order. </p>
                                  +
                                  +<p>
                                  +This feature is available in Postfix 2.12 and later.
                                  +</p>
                                  +
                                  %PARAM fast_flush_domains $relay_domains

                                  <p>
                                  diff --git a/postfix/src/global/mail_params.h b/postfix/src/global/mail_params.h
                                  index 12fd0e1..963d438 100644
                                  --- a/postfix/src/global/mail_params.h
                                  +++ b/postfix/src/global/mail_params.h
                                  @@ -198,7 +198,8 @@ extern char *var_null_relay_maps_key;

                                  #define VAR_SMTP_FALLBACK "smtp_fallback_relay"
                                  #define DEF_SMTP_FALLBACK "$fallback_relay"
                                  -#define VAR_LMTP_FALLBACK "smtp_fallback_relay"
                                  +#define VAR_LMTP_FALLBACK "lmtp_fallback_relay"
                                  +#define DEF_LMTP_FALLBACK ""
                                  #define DEF_FALLBACK_RELAY ""
                                  extern char *var_fallback_relay;

                                  diff --git a/postfix/src/smtp/lmtp_params.c b/postfix/src/smtp/lmtp_params.c
                                  index 68a2739..5af852f 100644
                                  --- a/postfix/src/smtp/lmtp_params.c
                                  +++ b/postfix/src/smtp/lmtp_params.c
                                  @@ -1,5 +1,6 @@
                                  static const CONFIG_STR_TABLE lmtp_str_table[] = {
                                  VAR_NOTIFY_CLASSES, DEF_NOTIFY_CLASSES, &var_notify_classes, 0, 0,
                                  + VAR_LMTP_FALLBACK, DEF_LMTP_FALLBACK, &var_fallback_relay, 0, 0,
                                  VAR_BESTMX_TRANSP, DEF_BESTMX_TRANSP, &var_bestmx_transp, 0, 0,
                                  VAR_ERROR_RCPT, DEF_ERROR_RCPT, &var_error_rcpt, 1, 0,
                                  VAR_LMTP_SASL_PASSWD, DEF_LMTP_SASL_PASSWD, &var_smtp_sasl_passwd, 0, 0,
                                  diff --git a/postfix/src/smtp/smtp_connect.c b/postfix/src/smtp/smtp_connect.c
                                  index ff278c1..0b84adc 100644
                                  --- a/postfix/src/smtp/smtp_connect.c
                                  +++ b/postfix/src/smtp/smtp_connect.c
                                  @@ -778,9 +778,7 @@ static void smtp_connect_inet(SMTP_STATE *state, const char *nexthop,
                                  if (sites->argc == 0)
                                  msg_panic("null destination: \"%s\"", nexthop);
                                  non_fallback_sites = sites->argc;
                                  - /* When we are lmtp(8) var_fallback_relay is null */
                                  - if (smtp_mode)
                                  - argv_split_append(sites, var_fallback_relay, ", \t\r\n");
                                  + argv_split_append(sites, var_fallback_relay, ", \t\r\n");

                                  /*
                                  * Don't give up after a hard host lookup error until we have tried the
                                  @@ -1055,7 +1053,7 @@ static void smtp_connect_inet(SMTP_STATE *state, const char *nexthop,
                                  * Pay attention to what could be configuration problems, and pretend
                                  * that these are recoverable rather than bouncing the mail.
                                  */
                                  - else if (!SMTP_HAS_SOFT_DSN(why) && smtp_mode) {
                                  + else if (!SMTP_HAS_SOFT_DSN(why)) {

                                  /*
                                  * The fall-back destination did not resolve as expected, or it
                                  @@ -1071,7 +1069,7 @@ static void smtp_connect_inet(SMTP_STATE *state, const char *nexthop,
                                  * The next-hop relayhost did not resolve as expected, or it is
                                  * refusing to talk to us, or mail for it loops back to us.
                                  */
                                  - else if (strcmp(sites->argv[0], var_relayhost) == 0) {
                                  + else if (smtp_mode && strcmp(sites->argv[0], var_relayhost) == 0) {
                                  msg_warn("%s configuration problem", VAR_RELAYHOST);
                                  vstring_strcpy(why->status, "4.3.5");
                                  /* XXX Keep the diagnostic code and MTA. */
                                  @@ -1081,7 +1079,7 @@ static void smtp_connect_inet(SMTP_STATE *state, const char *nexthop,
                                  * Mail for the next-hop destination loops back to myself. Pass
                                  * the mail to the best_mx_transport or bounce it.
                                  */
                                  - else if (SMTP_HAS_LOOP_DSN(why) && *var_bestmx_transp) {
                                  + else if (smtp_mode && SMTP_HAS_LOOP_DSN(why) && *var_bestmx_transp) {
                                  dsb_reset(why); /* XXX */
                                  state->status = deliver_pass_all(MAIL_CLASS_PRIVATE,
                                  var_bestmx_transp,

                                  --
                                  Viktor.
                                • Viktor Dukhovni
                                  ... One limitation is that with the patch lmtp_fallback_relay works only when the original LMTP destination is an inet: destination, there is no support for
                                  Message 16 of 20 , Jan 27, 2014
                                    On Tue, Jan 28, 2014 at 01:02:45AM +0000, Viktor Dukhovni wrote:

                                    > The patch below may not even compile, but probably works, give it a try.
                                    > As you can see, it is mostly a matter of adding a bit of documentation
                                    > and disabling conditionals that make existing code apply only to SMTP.
                                    >
                                    > If it works well for you, and Wietse is not opposed to an
                                    > "lmtp_fallback_relay" feature, something like this could be part
                                    > of Postfix 2.12.

                                    One limitation is that with the patch lmtp_fallback_relay works
                                    only when the original LMTP destination is an "inet:" destination,
                                    there is no support for fallback after failed unix-domain socket
                                    deliveries. This is an implementation artifact, but fixing it is
                                    substantially more difficult. I don't know how useful fallback
                                    relays are when the primary destination is a local LMTP service.

                                    --
                                    Viktor.
                                  • Quanah Gibson-Mount
                                    --On Tuesday, January 28, 2014 2:40 AM +0000 Viktor Dukhovni ... Hi Viktor, Thanks. For my specific installations, this isn t a concern as all of our LMTP
                                    Message 17 of 20 , Jan 27, 2014
                                      --On Tuesday, January 28, 2014 2:40 AM +0000 Viktor Dukhovni
                                      <postfix-users@...> wrote:

                                      > On Tue, Jan 28, 2014 at 01:02:45AM +0000, Viktor Dukhovni wrote:
                                      >
                                      >> The patch below may not even compile, but probably works, give it a try.
                                      >> As you can see, it is mostly a matter of adding a bit of documentation
                                      >> and disabling conditionals that make existing code apply only to SMTP.
                                      >>
                                      >> If it works well for you, and Wietse is not opposed to an
                                      >> "lmtp_fallback_relay" feature, something like this could be part
                                      >> of Postfix 2.12.
                                      >
                                      > One limitation is that with the patch lmtp_fallback_relay works
                                      > only when the original LMTP destination is an "inet:" destination,
                                      > there is no support for fallback after failed unix-domain socket
                                      > deliveries. This is an implementation artifact, but fixing it is
                                      > substantially more difficult. I don't know how useful fallback
                                      > relays are when the primary destination is a local LMTP service.

                                      Hi Viktor,

                                      Thanks. For my specific installations, this isn't a concern as all of our
                                      LMTP deliveries are via inet. ;)

                                      --Quanah

                                      --

                                      Quanah Gibson-Mount
                                      Architect - Server
                                      Zimbra, Inc.
                                      --------------------
                                      Zimbra :: the leader in open source messaging and collaboration
                                    • Andrzej A. Filip
                                      ... IMHO it would allow better configuration of (internet to internal) relays because it provides destination ports and weights. I do not (really) need it
                                      Message 18 of 20 , Jan 27, 2014
                                        On 01/28/2014 12:38 AM, Wietse Venema wrote:
                                        > Andrzej A. Filip:
                                        >> Do you plan to support SRV DNS records in a few years perspective?
                                        >
                                        > What real problem does this solve? Developer cycles are finite
                                        > and must be spent wisely.

                                        IMHO it would allow better configuration of (internet to internal)
                                        relays because it provides destination ports and weights. I do not
                                        (really) need it myself so I have asked about a few years perspective.

                                        Based on your reply the answer seems to be "double maybe" [polite no] ;-)
                                      • Viktor Dukhovni
                                        ... You speak of inbound relays , are you talking about SMTP? MX records are required for SMTP and SRV records are out of scope. ... For SMTP, absolutely
                                        Message 19 of 20 , Jan 28, 2014
                                          On Tue, Jan 28, 2014 at 08:21:01AM +0100, Andrzej A. Filip wrote:

                                          > >> Do you plan to support SRV DNS records in a few years perspective?
                                          > >
                                          > > What real problem does this solve? Developer cycles are finite
                                          > > and must be spent wisely.
                                          >
                                          > IMHO it would allow better configuration of (internet to internal)
                                          > relays because it provides destination ports and weights. I do not
                                          > (really) need it myself so I have asked about a few years perspective.

                                          You speak of "inbound relays", are you talking about SMTP? MX
                                          records are required for SMTP and SRV records are out of scope.

                                          > Based on your reply the answer seems to be "double maybe" [polite no] ;-)

                                          For SMTP, "absolutely not" is a more likely answer. For LMTP, SRV
                                          records are a possibility, that is neither currently implemented
                                          nor planned.

                                          --
                                          Viktor.
                                        • Andrzej A. Filip
                                          ... I was thinking about (E)SMTP and LMTP. SRV records may be useful for MX servers relaying to SMTP servers listening on non standard ports e.g. multiple
                                          Message 20 of 20 , Jan 28, 2014
                                            On 01/28/2014 03:10 PM, Viktor Dukhovni wrote:
                                            > On Tue, Jan 28, 2014 at 08:21:01AM +0100, Andrzej A. Filip wrote:
                                            >
                                            >>>> Do you plan to support SRV DNS records in a few years perspective?
                                            >>>
                                            >>> What real problem does this solve? Developer cycles are finite
                                            >>> and must be spent wisely.
                                            >>
                                            >> IMHO it would allow better configuration of (internet to internal)
                                            >> relays because it provides destination ports and weights. I do not
                                            >> (really) need it myself so I have asked about a few years perspective.
                                            >
                                            > You speak of "inbound relays", are you talking about SMTP? MX
                                            > records are required for SMTP and SRV records are out of scope.
                                            >
                                            >> Based on your reply the answer seems to be "double maybe" [polite no] ;-)
                                            >
                                            > For SMTP, "absolutely not" is a more likely answer. For LMTP, SRV
                                            > records are a possibility, that is neither currently implemented
                                            > nor planned.

                                            I was thinking about (E)SMTP and LMTP.

                                            SRV records may be useful for MX servers relaying to SMTP servers
                                            listening on non standard ports e.g. multiple virtual WWW servers on
                                            single IP with separated SMTP/LMTP servers also on the same IP address.
                                          Your message has been successfully submitted and would be delivered to recipients shortly.