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

292366Re: Multiple recipient_delimiter address extensions?

Expand Messages
  • Viktor Dukhovni
    Apr 5 6:46 AM
    • 0 Attachment
      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.
    • Show all 16 messages in this topic