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

Re: Verification of recipients when using @domain @domain mappings

Expand Messages
  • Wietse Venema
    ... I prefer to make distinction by purpose, and not by whether some mechanism happens to produce 1-1 for an input of FOO, or whether that same mechanism
    Message 1 of 23 , Jan 31, 2006
    View Source
    • 0 Attachment
      Victor Duchovni:
      > On Mon, Jan 30, 2006 at 07:13:12PM -0500, Wietse Venema wrote:
      >
      > > Consistency requires that this be done in the same manner for all
      > > forms of aliasing and forwarding, not just some and then driving
      > > everyone nuts here with questions just like per-recipient header_checks.
      > >
      >
      > Yes. So we could do two rounds of envelope recipient rewriting, with the
      > first round 1-to-1 and the second round 1-to-many, and call the first
      > recipient rewriting and the second recipient expansion. Then
      > with the rewriting phase 1-to-1 we can optionally propagate DSN and
      > perform validation after rewriting, while doing 1-to-many expansion
      > after DSN and validation.

      I prefer to make distinction by purpose, and not by whether some
      mechanism happens to produce 1-1 for an input of FOO, or whether
      that same mechanism happens to produce 1-N for input of BAR.

      The purposes I see are 1) canonicalization of headers and envelopes,
      2) routing, i.e. specifying where the mail should be sent.

      Step 1 applies the same rules for a sender address regardless of
      whether it is in a header or envelope. Likewise for a recipient
      address. If someone wants different treatment of headers vs
      envelopes, or recipients vs senders, then it is they who shall jump
      hoops, not those who follow the natural flow.

      Step 2, routing, could be 1-1 or 1-N. But whether the result is 1
      or N is of accidental nature, and not something that should
      fundamentally determine how the mail system works. From the user's
      point of view it's not about 1-1 versus 1-N. There is no good reason
      why 1, 2, or 3 should behave differently, and therefore they must
      be implemented the same.

      I also observe that all this crap was not an issue until DSN was
      introduced. It is not fundamental, but accidental, just like some
      programming problems are an accidental artefact of the language
      and not of programming per se. I disagree with making a fundamental
      change just because of pain in some accidental artefact.

      > The astute user will find clever ways of mixing and matching the two
      > rounds, but there is no special-casing in the interface, just two stages
      > with restricted semantics for the first round.
      >
      > Anyway, this is just one idea...

      We need a translator who can map the different views into
      a common space.

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