Noel Jones:
> > Is "DUNNO" the right choice here? This is not an access(5) table, and
> > "DUNNO" may muddy the user's understanding or expectations? If we really
> > want to allow one to make exceptions for specific users or sub-domains
> > without explicitly specifying the default transport, I think that:
> >
> > except.example.com DEFAULT
> > example.com transport:nexthop
>
> No, adding a new magic result is not the solution.
>
> >
> > or perhaps
> >
> > except.example.com :
> > example.com transport:nexthop
> >
> > is even intuitive, with the latter choice matching similar behaviour
> > in transport(5).
> >
>
> I like this. +1 for ":"
The sender-dependent default_transport user interface is a clone
of sender_dependent_relayhost_maps. I think that similar mechanisms
should have similar user interfaces where possible (this is a human
interface issue, flattening the learning curve by reusing mental
concepts).
When you compare sender-dependent default_transport versus relayhost
then you will notice that there are some differences:
- sender-dependent relayhost overrides relayhost, which affects
both the "default" address class and the "relay" address class.
This is desirable because sender-dependent relayhost is intended
for people who must send non-local mail through a specific ISP.
- sender-dependent default_transport overrides only default_transport,
meaning this affects the "default" address class but not the
"relay" address class.
While desirable, such differences may not be immediately obvious.
Finally, this is not the only way source IP address selection can
be implemented. My current list of options is:
1) Sender-dependent default_transport override as discussed above.
2) Two-level routing. First, the recipient address class is chosen
(result: local, virtual, relay, default). Then we extend the
address class concept, such that each address class may override
its own per-class transport with a sender-dependent lookup table.
This way, local recipients will be given to the local (or virtual)
address class, and will not be affected by the default class's
sender-dependent transport lookups. And once we have "default
class" transport overrides, we get "relay class" transport
overrides for free.
Like 1), feature 2) builds on the existing address class
infrastructure. On the down side, one has to understand the
subtle precedence order of selection mechanisms. While an override
is easy enough to add to Postfix, the approach does not scale well
if we want to introduce other lookup mechanisms (transport
selection by client name/address, client helo, sasl login, or
some other property such as the message size).
If we really want fully-generalized routing then we should
provide a transport policy protocol plus a proof-of-concept
implementation, similar to the SMTPD policy protocol. It is not
obvious that this would be used in the real world. Lookup tables
sacrifice functionality for better simplicity and robustness.
3) New access/header_checks/body_checks actions that set an SMTPSOURCE
attribute and that is used only by the SMTP client. This decouples
source IP address selection from the sender envelope address,
and requires no transport selection.
Feature 3) while it appears straightforward, it also completely
ignores the existing infrastructure of transport and nexthop
selection. It has the appeal of a short-sighted^h^h^h^h^h^h^hterm
solution and needs more analysis to understand its implications.
Wietse
