Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Wietse Venema (wietseporcupine.org)
Date: Thu Nov 19 2009 - 13:07:56 CST
> On Wed, Nov 18, 2009 at 4:53 PM, Wietse Venema <wietseporcupine.org> wrote:
> > In smtpd_recipient_restrictions you can have an access(5) map
> > that uses PREPEND.
> > ? ?/([^]+)$/ PREPEND X-Vmta: $1
> > which can be picked up by header_checks, because thuse happen later.
> > And that is as far as I am willing to reach out at this time.
> I will think on this more, but that just supplies the domain without
> the transport number needed to select the IP, and we definitely don't
> want to randomize it or anything like that. Thank you for your help.
Doing this right in Postfix requires either multiple instances
(perhaps using sender_dependent_relayhost_maps to do the "fan out")
or a new built-in mechanism that actually works. I don't think
that re-chartering the FILTER command is the right way.
As the name suggests, FILTER is designed for content inspection,
and for this reason it makes little sense to introduce a FILTER
destination that defaults to the recipient's domain (especially
considering that I pushed hard for SMTP-based content filters).
Changing the default FILTER destination from static to recipient
domain would affect performance for sites that use the "simple
filter" (Postfix pipe -> command -> Postfix sendmail) approach.
This currently does not require an explicit destination in the
FILTER command, although some examples show a dummy destination.
Specifically, this changes "simple filter" queue scheduling from
FIFO message selection (all messages have the same filter destination)
into round-robin destination domain selection, and that would
introduce anomalous delays for destinations that receive lots of
mail. The kind of badness that we eliminated eight years ago.
Past attempts at sender-dependent routing have not been successful
and their code was removed because it had unexpected failures in
corner cases. Postfix code is supposed to do something reasonable
no matter what you throw at it (even if this means declining to
handle radio-active waste).