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

Re: Multiple recipient_delimiter address extensions?

Expand Messages
  • grarpamp
    ... The current form is known, these are just ideas put out there. ... I ve done - (qmail) to + (postfix) hurriedly in the past to avoid a meta issue. Other
    Message 1 of 16 , Apr 3, 2013
      > also note that the word used here, delimiter, is singular. There's a

      The current form is known, these are just ideas put out there.

      > Having migrated from + to - (reversed my polarity, I guess) I felt

      I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
      meta issue. Other users migration or dual uses aside, with that
      one I wanted to but did not have benefit to research whether
      + or - had better merits. Such as which is in more common use now,
      which is trending to be more prevalent in the long term. And why?
      Honestly, best I could come up with was the large - legacy from
      decade old qmail-like installations, and not requiring the shift key
      seemed to win, heh :) I'm sure there are more sound thoughts
      on the matter in a paper somewhere.

      > As for implementations:
      >
      > 1) One general implementation would support a list of delimiter
      > characters. It would first search with the complete localpart, and
      > ... ... ... The order
      > of the list of delimiter characters would have to decide the priority
      > of one delimiter over another.
      >
      > 2) I would expect that terminating the localpart only once, at the
      > first match with any delimiter, would work well in practice (basically,
      > replacing strchr() with strcspn()). This would make only one table
      > lookup with the shortened localpart. This is guaranteed to match
      > at most once, but it may not match what you want, when one user's
      > delimiter appears inside another user's name.

      W... yes, I think you're both on with the tie-breaking, other possible
      semantics I didn't think of, and cost. Another thing that comes
      into play is the admin will have made some analysis of their
      to-be-merged, or to-be-dual-used username and extension lists.
      Perhaps providing a few interpretations to choose from would indeed
      win the simple cases.

      Just wanted to put the idea out there and some ways of handling,
      maybe it would seem worthy for admins who face migrations with
      userbases that are their livelihood.
      I usually see more new rollouts, or can enforce rules, so am not
      the best position to suggest.
    • Kris Deugau
      ... - has the fairly significant advantage of being allowed on more sites that try to validate well-formed email addresses - often in Javascript. Many such
      Message 2 of 16 , Apr 4, 2013
        grarpamp wrote:
        > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
        > meta issue. Other users migration or dual uses aside, with that
        > one I wanted to but did not have benefit to research whether
        > + or - had better merits. Such as which is in more common use now,
        > which is trending to be more prevalent in the long term. And why?
        > Honestly, best I could come up with was the large - legacy from
        > decade old qmail-like installations, and not requiring the shift key
        > seemed to win, heh :) I'm sure there are more sound thoughts
        > on the matter in a paper somewhere.

        - has the fairly significant advantage of being allowed on more sites
        that try to validate "well-formed" email addresses - often in
        Javascript. Many such validators reject + in an email address. :(

        -kgd
      • Wietse Venema
        ... It would be relatively easy to implement truncate the localpart at the first instance of any character in the delimiter set, then do one table lookup
        Message 3 of 16 , Apr 4, 2013
          Kris Deugau:
          > grarpamp wrote:
          > > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
          > > meta issue. Other users migration or dual uses aside, with that
          > > one I wanted to but did not have benefit to research whether
          > > + or - had better merits. Such as which is in more common use now,
          > > which is trending to be more prevalent in the long term. And why?
          > > Honestly, best I could come up with was the large - legacy from
          > > decade old qmail-like installations, and not requiring the shift key
          > > seemed to win, heh :) I'm sure there are more sound thoughts
          > > on the matter in a paper somewhere.
          >
          > - has the fairly significant advantage of being allowed on more sites
          > that try to validate "well-formed" email addresses - often in
          > Javascript. Many such validators reject + in an email address. :(

          It would be relatively easy to implement "truncate the localpart
          at the first instance of any character in the delimiter set, then
          do one table lookup" (basically, replacing strchr() with strcspn()).

          This would allow one to use '-' for some websites and '+' for others.

          This could later be made more configurable, for example "for each
          delimiter in the specified order: truncate the localpart, do
          table lookup, and stop after the first successful lookup".

          As long as users stick to names with [a-zA-Z0-9.], the first,
          simpler, implementation should be sufficient.

          Wietse
        • Wietse Venema
          ... Unfortunately this would break existing code that expands $recipient_delimiter, for example the forward_path default value. This means using a new
          Message 4 of 16 , Apr 4, 2013
            Wietse Venema:
            > Kris Deugau:
            > > grarpamp wrote:
            > > > I've done - (qmail) to + (postfix) hurriedly in the past to avoid a
            > > > meta issue. Other users migration or dual uses aside, with that
            > > > one I wanted to but did not have benefit to research whether
            > > > + or - had better merits. Such as which is in more common use now,
            > > > which is trending to be more prevalent in the long term. And why?
            > > > Honestly, best I could come up with was the large - legacy from
            > > > decade old qmail-like installations, and not requiring the shift key
            > > > seemed to win, heh :) I'm sure there are more sound thoughts
            > > > on the matter in a paper somewhere.
            > >
            > > - has the fairly significant advantage of being allowed on more sites
            > > that try to validate "well-formed" email addresses - often in
            > > Javascript. Many such validators reject + in an email address. :(
            >
            > It would be relatively easy to implement "truncate the localpart
            > at the first instance of any character in the delimiter set, then
            > do one table lookup" (basically, replacing strchr() with strcspn()).
            >
            > This would allow one to use '-' for some websites and '+' for others.

            Unfortunately this would break existing code that expands
            $recipient_delimiter, for example the forward_path default value.

            This means using a new parameter name for the recipient delimiter
            set, and making the recipient_delimiter default value dependent on
            the value of that new parameter (for example take the first character).

            Wietse

            > This could later be made more configurable, for example "for each
            > delimiter in the specified order: truncate the localpart, do
            > table lookup, and stop after the first successful lookup".
            >
            > As long as users stick to names with [a-zA-Z0-9.], the first,
            > simpler, implementation should be sufficient.
            >
            > Wietse
            >
          • Wietse Venema
            I ve done a proof-of-concept implementation that works as documented below the signature. This retains the old recipient_delimiter parameter because that
            Message 5 of 16 , Apr 4, 2013
              I've done a proof-of-concept implementation that works as documented
              below the signature.

              This retains the old recipient_delimiter parameter because that
              parameter has been in use since 19981029 in the forward_path default
              parameter value, and I can't have a multi-character value there.

              To support users that have .forward+foo and .forward-foo, you'd
              have to spell the file names explicitly:

              /etc/postfix/main.cf:
              recipient_delimiters = +-
              forward_path =
              $home/.forward+${extension},
              $home/.forward-${extension},
              $home/.forward

              This works regardless of what the delimiter in the email address
              was; Postfix does not use that when it searches forward_path.

              Wietse

              recipient_delimiters (default: $recipient_delimiter)
              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_delimiters set contains multiple
              characters, user names and address extensions are
              separated at the first character that matches the
              recipient_delimiters set. The implementation recognizes
              only one delimiter character per email address.

              By default, the recipient_delimiter (note: singular)
              value equals the first character of the recipient_delimiters
              parameter value. The recipient_delimiter parameter is
              used in the default forward_path value, where the
              software tries .forward+foo before trying .forward.

              When the recipient_delimiters parameter is not specified,
              its value defaults to the recipient_delimiter value.

              Example:

              # Handle both Postfix and qmail extensions.
              recipient_delimiters = +-
            • 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.