Re: Verification of recipients when using @domain @domain mappings
- View SourceVictor Duchovni:
> On Mon, Jan 30, 2006 at 07:13:12PM -0500, Wietse Venema wrote:I prefer to make distinction by purpose, and not by whether some
> > 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.
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 twoWe need a translator who can map the different views into
> 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...
a common space.