Thierry Fournier:
> smtp_dns_request_filter (default: empty)
The name is not entirely consistent with the function. Examples of
existing Postfix filter features:
xxx_delivery_status_filter modifies a delivery status
xxx_dns_reply_filter modifies a DNS response
smtpd_command_filter modifies an inbound SMTP command
smtp_reply_filter modifies an outbound SMTP reply
The name smtp_mx_lookup_override would better describe what the
code does now: it overrides MX lookups.
Based on your examples the main thing it can do that Postfix can't
already do is to specify multiple destinations.
- The "transport_maps" feature can selectively redirect mail to a
different MTA, and it can selectively bounce (or discard) mail
by redirecting it to the 'error' (or 'discard') transport.
- The xxx_dns_reply_filter feature can delete a record that you
don't like (I use this to avoid sending mail to Google over IPv6).
(a secondary thing is that Postfix cannot create DNS responses, but
Postfix could be updated to modify responses if needed).
Support for multiple destinations could be implemented with:
- An "smtp_fallback_relay_maps" feature that produces an additional
destination depending on the domain in the delivery request.
- An "smtp_nexthop_override_maps" feature that replaces the domain
in the delivery request with one or more domain names. You decide
the order of names in the result, and if the original domain
should be part of the result. Specify [name], [name] to get
comparable control as with your synthetic MX records.
- Or, add support for multiple next-hop destinations in "relayhost",
"transport_maps", and "default_transport". This changes the syntax
and semantics of existing Postfix features. Again, specify [name],
[name] to get comparable control as with your synthetic MX records.
Each would require about a similar number of lines of code as they
would require in documentation, or less than that. That's significantly
less than ~200 lines of code for the MX lookup override.
I think that "smtp_nexthop_override_maps" could do the trick, with
documentation updates for "transport_maps", "default_transport",
and "relayhost" that point to "smtp_nexthop_override_maps".
- It gives comparable control over multi-destination selection as
with your proposed feature, unlike "smtp_fallback_relay_maps"
which can only add a destination.
- It does not change the syntax or semantics of "relayhost",
"transport_maps", or "default_transport", unlike a change that
would support for multiple next-hop destinations in those features.
Wietse
