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

recipient rewrite when sender != <>

Expand Messages
  • Fabio Sangiovanni
    Hi list, I m setting up postfix as mx for some domains. According to the docs, my setup should fall in the relay_domain class, since I need to relay messages
    Message 1 of 11 , Aug 27, 2013
    • 0 Attachment
      Hi list,

      I'm setting up postfix as mx for some domains. According to the docs, my
      setup should fall in the 'relay_domain' class, since I need to relay
      messages for those domains to an internal host (is this correct?).

      I need to implement a policy, that is an exception to the standard flow
      postfix -> internal host: I need to rewrite the address of some
      particular recipients, but just for messages with envelope sender
      different from the null sender. In other terms, I need to redirect
      messages for some recipients in a list (towards other, remote,
      addresses), but only if the envelope sender is not <>. If the envelope
      sender is <>, I need messages to follow the standard route towards the
      internal host, even for the recipients on the list.

      My solution so far involves an access table in
      smtp_recipient_restrictions with the REDIRECT directive, but it doesn't
      work properly in case of multiple recipients.

      Have you any suggestions?

      Thanks a lot for your help.

      Fabio Sangiovanni
    • Wietse Venema
      ... That is correct. When your server is not the final destination for domain X, then X is a relay domain. ... I am suspicious about mail configurations that
      Message 2 of 11 , Aug 27, 2013
      • 0 Attachment
        Fabio Sangiovanni:
        > Hi list,
        >
        > I'm setting up postfix as mx for some domains. According to the docs, my
        > setup should fall in the 'relay_domain' class, since I need to relay
        > messages for those domains to an internal host (is this correct?).

        That is correct. When your server is not the final destination for
        domain X, then X is a relay domain.

        > I need to implement a policy, that is an exception to the standard flow
        > postfix -> internal host: I need to rewrite the address of some
        > particular recipients, but just for messages with envelope sender
        > different from the null sender. In other terms, I need to redirect
        > messages for some recipients in a list (towards other, remote,
        > addresses), but only if the envelope sender is not <>. If the envelope
        > sender is <>, I need messages to follow the standard route towards the
        > internal host, even for the recipients on the list.

        I am suspicious about mail configurations that special-case bounce
        messages.

        That said, this is doable with Postfix built-in mechanisms if your
        setup looks like Postfix->after-queue content filter->Postfix->internal,
        with separate Postfix instances before and after the filter.

        In this case, the Postfix instance before the content filter
        uses two smtp transports (with different names) that both deliver
        all mail to the content filter. The Postfix instance before
        the content filter uses sender_dependent_default_transport_maps
        to send mail with a null sender to the first smtp transport,
        and everything else to the second smtp transport. The second
        smtp transport uses smtp_generic_maps to rewrite addresses.
        Note that smtp_generic_maps rewrites all addresses (both envelope
        and message header). Postfix after the content filter simply
        delivers mail to its destination, whether internal or external.

        If the above seems reasonable, then I or someone else can draft an
        example configuration.

        If you must implement sender-dependent recipient rewriting within
        one Postfix configuration, this requires a plugin.

        You'd need a Milter plugin (for example in Python or Perl) that
        deletes an old recipient and that adds a new recipient as its
        replacement. This Milter would not need to inspect the message
        body, so the overhead would be small. If you use a before-queue
        content filter, this Milter plugin would have to be hooked into
        the SMTP daemon after the filter.


        Wietse
      • Fabio Sangiovanni
        Wietse Venema porcupine.org writes: First of all, thanks for the answer. ... One question: since sender_dependent_default_transport_maps
        Message 3 of 11 , Aug 28, 2013
        • 0 Attachment
          Wietse Venema <wietse <at> porcupine.org> writes:

          First of all, thanks for the answer.

          > The Postfix instance before
          > the content filter uses sender_dependent_default_transport_maps
          > to send mail with a null sender to the first smtp transport,
          > and everything else to the second smtp transport.
          >

          One question: since sender_dependent_default_transport_maps overrides
          default_transport, how can I have this within a relay domain configuration?
          The transport in use would be relay_transport, IIRC.

          Besides, I don't see any difficulties in doing this with one single postfix
          instance, i.e. without an after-queue filter. Is this correct?

          > If the above seems reasonable, then I or someone else can draft an
          > example configuration.

          That would be great, I think we could discuss better with real confs at hand.

          Thanks,
          Fabio
        • Wietse Venema
          ... Both first and second smtp transport sending mail to the content filter. ... The Postfix instance before the content filter sends *all mail* to the content
          Message 4 of 11 , Aug 28, 2013
          • 0 Attachment
            Fabio Sangiovanni:
            > Wietse Venema <wietse <at> porcupine.org> writes:
            >
            > First of all, thanks for the answer.
            >
            > > The Postfix instance before
            > > the content filter uses sender_dependent_default_transport_maps
            > > to send mail with a null sender to the first smtp transport,
            > > and everything else to the second smtp transport.

            Both first and second smtp transport sending mail to the content filter.

            > One question: since sender_dependent_default_transport_maps overrides
            > default_transport, how can I have this within a relay domain configuration?

            The Postfix instance before the content filter sends *all mail* to
            the content filter. This simplifies routing considerably.

            > Besides, I don't see any difficulties in doing this with one single postfix
            > instance, i.e. without an after-queue filter. Is this correct?

            Perhaps, if you know how to deliver mail from <> to external
            recipients, to internal recipients, and to local recipients.

            > > If the above seems reasonable, then I or someone else can draft an
            > > example configuration.
            >
            > That would be great, I think we could discuss better with real confs at hand.

            OK, I'll look into that.

            Wietse
          • Fabio Sangiovanni
            ... Ok, I get it now. ... I really appreciate this, thanks. Fabio
            Message 5 of 11 , Aug 28, 2013
            • 0 Attachment
              Wietse Venema <wietse <at> porcupine.org> writes:

              > > One question: since sender_dependent_default_transport_maps overrides
              > > default_transport, how can I have this within a relay domain configuration?
              >
              > The Postfix instance before the content filter sends *all mail* to
              > the content filter. This simplifies routing considerably.

              Ok, I get it now.

              > OK, I'll look into that.

              I really appreciate this, thanks.

              Fabio
            • Wietse Venema
              Would it be possible to describe the problem that you are trying to solve, instead of your solution (routing senders differently). It is an uncommon
              Message 6 of 11 , Aug 28, 2013
              • 0 Attachment
                Would it be possible to describe the problem that you are trying
                to solve, instead of your solution (routing <> senders differently).
                It is an uncommon requirement. Arbitrary routing requires a procedural
                language, which is currently not included with Postfix.

                Wietse
              • Fabio Sangiovanni
                ... Yes, the problem is the following: the machine postfix is running on will act as a smtp relay for some domains. Its public ip address is listed as MX
                Message 7 of 11 , Aug 28, 2013
                • 0 Attachment
                  Wietse Venema <wietse <at> porcupine.org> writes:

                  >
                  > Would it be possible to describe the problem that you are trying
                  > to solve, instead of your solution (routing <> senders differently).
                  > It is an uncommon requirement. Arbitrary routing requires a procedural
                  > language, which is currently not included with Postfix.
                  >
                  > Wietse
                  >
                  >


                  Yes, the problem is the following:
                  the machine postfix is running on will act as a smtp relay for some domains.
                  Its public ip address is listed as MX record for these domains, but inboxes
                  are on another (internal) server.
                  The requirements I'm trying to satisfy are:
                  - incoming messages for some of the local addresses need to be redirected
                  to other addresses, whose final destination is remote (so they don't need
                  to hit the inbox)
                  - incoming messages for these same addresses that have null sender
                  need not to be redirected, but must be stored in the inbox (this is an
                  exception to the previous requirement, based on the sender)

                  Thanks a lot for your help :)

                  Fabio
                • Wietse Venema
                  ... Your original solution was about rewriting instead of routing, but apart from that, same limitation applies. Wietse
                  Message 8 of 11 , Aug 28, 2013
                  • 0 Attachment
                    Wietse Venema:
                    > Would it be possible to describe the problem that you are trying
                    > to solve, instead of your solution (routing <> senders differently).
                    > It is an uncommon requirement. Arbitrary routing requires a procedural
                    > language, which is currently not included with Postfix.

                    Your original solution was about rewriting instead of routing, but
                    apart from that, same limitation applies.

                    Wietse
                  • Wietse Venema
                    ... This requires a different routing model than what Postfix currently implements. Postfix s trivial-rewrite program basically runs one address (sender or
                    Message 9 of 11 , Aug 28, 2013
                    • 0 Attachment
                      Wietse:
                      > Would it be possible to describe the problem that you are trying
                      > to solve, instead of your solution (routing <> senders differently).
                      > It is an uncommon requirement. Arbitrary routing requires a procedural
                      > language, which is currently not included with Postfix.

                      Fabio Sangiovanni:
                      > Yes, the problem is the following:
                      > [the same solution]

                      This requires a different routing model than what Postfix currently
                      implements. Postfix's trivial-rewrite program basically runs one
                      address (sender or recipient) through a sequence of table lookups,
                      without much regard to other message properties. The trivial-rewrite
                      program is designed to be replaced by a less trivial program, but
                      sofar that replacement has not materialized.

                      That means your solution can currently be implemented only with
                      less than elegant solutions.

                      To make the point clear, below is a single Postfix configuration
                      that rewrites selected addresses when the sender is not <>. It
                      uses a sender-dependent FILTER action to enable/disable address
                      rewriting with smtp_generic_maps, and loops mail back into Postfix
                      via a mechanism that was designed for external content filters.

                      /etc/postfix/main.cf:
                      smtpd_sender_restrictions = pcre:/etc/postfix/sender_access
                      # Default: enable smtp_generic_maps address rewriting.
                      content_filter = smtp-with-generic:127.0.0.1:10025

                      /etc/postfix/sender_access:
                      # Override: disable smtp_generic_maps address rewriting.
                      /<>/ FILTER smtp-no-generic:127.0.0.1:10025

                      /etc/postfix/master.cf:
                      # smtp-no-generic is included for clarity. You could use "smtp" instead.
                      smtp-no-generic unix - - n - - smtp
                      -o smtp_generic_maps=
                      smtp-with-generic unix - - n - - smtp
                      -o smtp_generic_maps=hash:/etc/postfix/generic
                      127.0.0.1:10025 inet n - n - - smtpd
                      -o receive_override_options=no_address_mappings

                      /etc/postfix/generic:
                      user1@... another1@...

                      Now, this looks like a pretty compact configuration. The problem
                      is that a) it is unlikely that real people would come up with stuff
                      like this and b) solutions that rely on multiple parts (here, FILTER
                      and smtp_generic_maps) tend to fall apart when requirements change.

                      In the end, it appears that the more verbose configuration language
                      wins.

                      Wietse
                    • Fabio Sangiovanni
                      ... With my original solution , do you mean the access table with REDIRECT directive? It s the first thing I came up with, but I changed my mind quite rapidly
                      Message 10 of 11 , Aug 28, 2013
                      • 0 Attachment
                        Wietse Venema <wietse <at> porcupine.org> writes:

                        >
                        > Wietse Venema:
                        > > Would it be possible to describe the problem that you are trying
                        > > to solve, instead of your solution (routing <> senders differently).
                        > > It is an uncommon requirement. Arbitrary routing requires a procedural
                        > > language, which is currently not included with Postfix.
                        >
                        > Your original solution was about rewriting instead of routing, but
                        > apart from that, same limitation applies.
                        >
                        > Wietse
                        >
                        >

                        With my "original solution", do you mean the access table with
                        REDIRECT directive? It's the first thing I came up with, but I changed
                        my mind quite rapidly because of its poorness in dealing with multiple
                        recipients.
                      • Fabio Sangiovanni
                        ... Thanks, this should also get rid of the double instance + content filter. It should work properly, and let s hope requirements don t change :) Fabio
                        Message 11 of 11 , Aug 28, 2013
                        • 0 Attachment
                          Wietse Venema <wietse <at> porcupine.org> writes:

                          >
                          > In the end, it appears that the more verbose configuration language
                          > wins.

                          Thanks, this should also get rid of the double instance + content filter.
                          It should work properly, and let's hope requirements don't change :)

                          Fabio
                        Your message has been successfully submitted and would be delivered to recipients shortly.