Fabio Sangiovanni:
> Hi list,
> 
> I'm setting up postfix as mx for some domains. According to the docs, my 
> setup should fall in the 'relay_domain' class, since I need to relay 
> messages for those domains to an internal host (is this correct?).

That is correct. When your server is not the final destination for
domain X, then X is a relay domain.

> I need to implement a policy, that is an exception to the standard flow 
> postfix -> internal host: I need to rewrite the address of some 
> particular recipients, but just for messages with envelope sender 
> different from the null sender. In other terms, I need to redirect 
> messages for some recipients in a list (towards other, remote, 
> addresses), but only if the envelope sender is not <>. If the envelope 
> sender is <>, I need messages to follow the standard route towards the 
> internal host, even for the recipients on the list.

I am suspicious about mail configurations that special-case bounce
messages.

That said, this is doable with Postfix built-in mechanisms if your
setup looks like Postfix->after-queue content filter->Postfix->internal,
with separate Postfix instances before and after the filter.

    In this case, the Postfix instance before the content filter
    uses two smtp transports (with different names) that both deliver
    all mail to the content filter.  The Postfix instance before
    the content filter uses sender_dependent_default_transport_maps
    to send mail with a null sender to the first smtp transport,
    and everything else to the second smtp transport. The second
    smtp transport uses smtp_generic_maps to rewrite addresses.
    Note that smtp_generic_maps rewrites all addresses (both envelope
    and message header).  Postfix after the content filter simply
    delivers mail to its destination, whether internal or external.

If the above seems reasonable, then I or someone else can draft an
example configuration.

If you must implement sender-dependent recipient rewriting within
one Postfix configuration, this requires a plugin.  

    You'd need a Milter plugin (for example in Python or Perl) that
    deletes an old recipient and that adds a new recipient as its
    replacement.  This Milter would not need to inspect the message
    body, so the overhead would be small. If you use a before-queue
    content filter, this Milter plugin would have to be hooked into
    the SMTP daemon after the filter.


        Wietse

Reply via email to