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

Re: Multiple recipient_delimiter address extensions?

Expand Messages
  • Wietse Venema
    ... I was able to simplify this further. The result is below. Comments are welcome. The problem with forward_path could be solved without requiring changes to
    Message 1 of 16 , Apr 5, 2013
      Wietse Venema:
      > I've done a proof-of-concept implementation that works as documented
      > below the signature.

      I was able to simplify this further. The result is below.
      Comments are welcome.

      The problem with forward_path could be solved without requiring
      changes to the forward_path default setting:

      forward_path = $home/.forward${recipient_delimiter}${extension},
      $home/.forward

      When Postfix expands this while delivering mail, it now replaces
      ${recipient_delimiter} with the actual recipient delimiter in the
      recipient email address, instead of using the main.cf value.

      recipient_delimiter (default: empty)
      The set of characters that can separate user names and
      address extensions (user+foo). See canonical(5),
      local(8), relocated(5) and virtual(5) for the effects
      this has on aliases, canonical, virtual, and relocated
      lookups. Basically, the software tries user+foo before
      trying user.

      When the recipient_delimiter set contains more than one
      character (Postfix 2.11 and later), user names and
      address extensions are separated at the first character
      that matches the recipient_delimiter set. The
      implementation recognizes only one delimiter character
      per email address.

      When used in forward_path, ${recipient_delimiter} is
      replaced with the actual recipient delimiter in the
      recipient email address.

      Examples:

      # Support Postfix and qmail extensions (Postfix >= 2.11).
      recipient_delimiter = +-

      # Use .forward for mail without address extension, or
      # with an unrecognized address extension.
      forward_path = $home/.forward,
      $home/.forward${recipient_delimiter}${extension}

      This seems like a more reasonable implementation.

      Support for delimiter priorities could be added later but I doubt
      that it will really solve problems.

      Wietse
    • Viktor Dukhovni
      ... One issue this does not discuss is the handling of: propagate_unmatched_extensions = canonical, virtual a relay that accepts multiple extensions and
      Message 2 of 16 , Apr 5, 2013
        On Fri, Apr 05, 2013 at 09:23:42AM -0400, Wietse Venema wrote:

        > Wietse Venema:
        > > I've done a proof-of-concept implementation that works as documented
        > > below the signature.
        >
        > I was able to simplify this further. The result is below.
        > Comments are welcome.

        One issue this does not discuss is the handling of:

        propagate_unmatched_extensions = canonical, virtual

        a relay that accepts multiple extensions and validates addresses
        via relay_recipient_maps, may forward mail via SMTP to downstream
        destinations which handle a subset (possibly none) of the supported
        extensions. This can create bouncebacks.

        Even with a single recipient delimiter (say "+"), I've had to set:

        propagate_unmatched_extensions = canonical

        so that envelope recipients forwarded to Microsoft Exchange were
        not extended, since Exchange does not support extensions.

        The general picture is more complex, since while MUAs only need
        extensions in headers to help users sort incoming mail, the delivery
        MTA (e.g. qmail or Postfix via forward_path, ...) uses the envelope
        recipient.

        So a complete implementation possibly needs to be able to determine
        the correct downstream recipient delimiter based on the destination
        nexthop or transport:nexthop. In recursive virtual (or canonical)
        expansion this logic need only apply to the final address.

        I'm also concerned that matching the first delimiter is problematic
        in mixed environments. When a relay sits in front of two domains
        example.com (whose extension is "+") and example.net (whose extension
        is "-") we don't get correct behaviour:

        postfix-users+extension@...
        user-extension+more-extension@...

        the relay would bounce the "postfix-users+extension" mail, as it
        would misinterpret this as being addressed to "postfix", unless in
        fact multiple lookups are made, and the recipient delimiter is
        inferred from the shortest match (try "postfix" - "...", then
        "postfix-users" + "...").

        If we do add support for destination specific address extensions
        on output, what should be done with the wrong extension on input?
        Hypothetical:

        postfix-users-mumble@...

        is just an invalid address when example.com is a "+" delimiter domain.

        So I'm not entirely convinced we're not opening up a bit of a can
        of worms.

        --
        Viktor.
      • /dev/rob0
        ... Thanks. A very minor complaint is that you have always been very consistent IIRC regarding plural and singular in parameter names, but now
        Message 3 of 16 , Apr 5, 2013
          On Fri, Apr 05, 2013 at 09:23:42AM -0400, Wietse Venema wrote:
          > Wietse Venema:
          > > I've done a proof-of-concept implementation that works as
          > > documented below the signature.
          >
          > I was able to simplify this further. The result is below.
          > Comments are welcome.

          Thanks. A very minor complaint is that you have always been very
          consistent IIRC regarding plural and singular in parameter names, but
          now "recipient_delimiter" can be multiple characters. :) (I do
          understand why it works better in this case; just saying, maybe for
          naming consideration in a Postfix 3.0.)

          I will not be able to get to this until early next week, but at that
          time I'll upgrade and experiment with this.

          I really hated switching from + to - as delimiter. It felt like the
          wrong thing to do, accomodating some fool who happened to write a
          popular PHP library function. It will be nice to be positive again.
          :)
          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Wietse Venema
          ... First, lest I sound ungrateful later, thanks for the comments. ... This problem is old: it exists whether or not recipient_delimiter specifies a single
          Message 4 of 16 , Apr 5, 2013
            Viktor Dukhovni:
            > On Fri, Apr 05, 2013 at 09:23:42AM -0400, Wietse Venema wrote:
            >
            > > Wietse Venema:
            > > > I've done a proof-of-concept implementation that works as documented
            > > > below the signature.
            > >
            > > I was able to simplify this further. The result is below.
            > > Comments are welcome.

            First, lest I sound ungrateful later, thanks for the comments.

            > One issue this does not discuss is the handling of:
            >
            > propagate_unmatched_extensions = canonical, virtual
            >
            > a relay that accepts multiple extensions and validates addresses
            > via relay_recipient_maps, may forward mail via SMTP to downstream
            > destinations which handle a subset (possibly none) of the supported
            > extensions. This can create bouncebacks.

            This problem is old: it exists whether or not recipient_delimiter
            specifies a single character or a set of characters.

            > postfix-users+extension@...
            > user-extension+more-extension@...

            This problem is old, too: it exists whether or not recipient_delimiter
            specifies a single character or a set of characters.

            Note that an address extension exists only because the owner of the
            email address decided to use that extension in the first place.

            If the owner of an email address decides to use address extensions,
            then she should choose a username that doesn't contain any of the
            common user/extension delimiters.

            Wietse
          • Wietse Venema
            ... Yes and no. Postfix still supports only one user/extension separator per address. A feature name that contains the word delimiters would send the message
            Message 5 of 16 , Apr 5, 2013
              /dev/rob0:
              > On Fri, Apr 05, 2013 at 09:23:42AM -0400, Wietse Venema wrote:
              > > Wietse Venema:
              > > > I've done a proof-of-concept implementation that works as
              > > > documented below the signature.
              > >
              > > I was able to simplify this further. The result is below.
              > > Comments are welcome.
              >
              > Thanks. A very minor complaint is that you have always been very
              > consistent IIRC regarding plural and singular in parameter names, but
              > now "recipient_delimiter" can be multiple characters. :) (I do

              Yes and no. Postfix still supports only one user/extension separator
              per address.

              A feature name that contains the word "delimiters" would send the
              message that Postfix supports "multiple delimiters" within an address.

              > I really hated switching from + to - as delimiter. It felt like the
              > wrong thing to do, accomodating some fool who happened to write a
              > popular PHP library function. It will be nice to be positive again.
              > :)

              I see some late revenge.

              Wietse
            • grarpamp
              hi. i ve briefly reviewed some of this posted work and it seems reasonable. and refreshing to see work come from my simple query. so give the new option a go
              Message 6 of 16 , Apr 10, 2013
                hi. i've briefly reviewed some of this posted work and it seems reasonable.
                and refreshing to see work come from my simple query. so give the new
                option a go as best seen fit! thanks.
              • Jeroen Geilman
                ... $recipient_delimiter_alternatives ? -- J.
                Message 7 of 16 , Apr 11, 2013
                  On 04/05/2013 08:17 PM, Wietse Venema wrote:
                  > /dev/rob0:
                  >>
                  >> Thanks. A very minor complaint is that you have always been very
                  >> consistent IIRC regarding plural and singular in parameter names, but
                  >> now "recipient_delimiter" can be multiple characters. :) (I do
                  > Yes and no. Postfix still supports only one user/extension separator
                  > per address.
                  >
                  > A feature name that contains the word "delimiters" would send the
                  > message that Postfix supports "multiple delimiters" within an address.

                  $recipient_delimiter_alternatives ?

                  --
                  J.
                • Wietse Venema
                  ... That is better. After working through feature update, I noticed that the delimiter is also applied to sender addresses, so I am declined to replace the
                  Message 8 of 16 , Apr 11, 2013
                    Jeroen Geilman:
                    > On 04/05/2013 08:17 PM, Wietse Venema wrote:
                    > > /dev/rob0:
                    > >>
                    > >> Thanks. A very minor complaint is that you have always been very
                    > >> consistent IIRC regarding plural and singular in parameter names, but
                    > >> now "recipient_delimiter" can be multiple characters. :) (I do
                    > > Yes and no. Postfix still supports only one user/extension separator
                    > > per address.
                    > >
                    > > A feature name that contains the word "delimiters" would send the
                    > > message that Postfix supports "multiple delimiters" within an address.
                    >
                    > $recipient_delimiter_alternatives ?

                    That is better. After working through feature update, I noticed
                    that the delimiter is also applied to sender addresses, so I am
                    declined to replace the recipient_ portion.

                    Perhaps this is a path into the future:

                    recipient_delimiter
                    This is no longer a main.cf parameter. It is used only in the
                    $forward_path, where it expands into the user/extension separator
                    that was found in the recipient email address.

                    address_delimiter_alternatives (default: $recipient_delimiter)
                    This is a new main.cf parameter, containing the set of characters
                    that may separate a user name from an address extension (user+foo)
                    in a sender or recipient address. The default setting maintains
                    backwards compatibility fo rexisting configurations.

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