Ian Duggan:
> On Wed, Nov 18, 2009 at 2:03 PM, Wietse Venema <wie...@porcupine.org> wrote:
> > The transports(5) manpage mentions that the destination defaults
> > to the recipient domain. However, the scheduler uses a different
> > default, which appears to be inconsistent. I wonder what would
> > break if this were to be changed.
>
> Yes, this seems to be the issue. I'm depending on, from transport(5):
>
> "A non-null transport field with a null nexthop field resets
> the nexthop information to the recipient domain."
>
> which doesn't seem to be happening. If you can direct me to the
> relevant scheduler code or have a patch I could try, I'd be happy to
> test it and see what happens.
The Postfix scheduler uses $myhostname as the default for all
imssing destinations. Transport maps are implemented by a different
program, hence the difference in default policies.
Making changes to the scheduler is non-trivial (i.e. it actually
requires more testing than simply "it works") and it is not a good
idea to do this at the end of along day.
Apart from that is the question what existing usage patterns would
break if this default behavior were to be changed almost 10 years
after it was introduced. It is not a win if I piss of lots of
others.
> > For now, perhaps your header_checks rules can copy the recipient
> > domain to the FILTER command.
>
> Success! Well, more or less. This is working, but I'm not 100%
> satisfied with it since the sender has to specify the domain to send
> to twice in the email, making sure the X-Vmta header matches the
> recipient domain.
>
> /^X-Vmta.*\s*([0-9]+)(\s*(\S*))?/ FILTER vmta${1}:${3}
>
> So:
>
> "X-Vmta: 3 gmail.com" maps to "vmta3:gmail.com"
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.
> Can anyone think of a way to easily grab the recipient domain from the
> To: header line and have it available somehow when writing the FILTER
> line? I can't envision a way to pass information between lines like
> that.
As documented there is no way to pass information from one header/body
action to another header/body action.
> My preference is to figure out how to get postfix to do what
> transport(5) seems to indicate it should, however.
I think this use case is so peripheral to legitimacy that it's not
a priority for me to find out what things will break when this were
to be changed.
I am suspicious when people try to use Postfix to implement
IP-based reputation tricks.
Wietse
