From: David F. on
For a given virtual domain, I would like to send mail with a certain prefix to another process (via pipe) while all other mail gets delivered normally.

Here are the (hopefully) relevant pieces of my various config files:

/etc/postfix/master.cf
list-expander unix - n n - - pipe
flags=DRhu user=nobody:nobody argv=/usr/bin/list-expander ${recipient}

/etc/postfix/transport
/^list-.*@mydomain.com$/ list-expander:unix

/etc/postfix/main.cf
transport_maps = regexp:/etc/postfix/transport
virtual_mailbox_domains = mydomain.com

If I ask for a delivery report (sendmail -bv 'list-test(a)mydomain.com') I get what I was expecting:

<list-test(a)mydomain.com>: delivery via list-expander: delivers to
command: /usr/bin/list-expander

But the Postfix Virtual Domain Hosting Howto seems to say that what I've done above won't work:

"Why does this example use a clumsy virtual alias instead of a more elegant transport mapping? The reason is that mail for the virtual mailing list would be rejected with "User unknown". "

And, sure enough, when I try to send mail to my list, it bounces with "Recipient address rejected: User unknown in virtual mailbox table;". (Virtual aliases for the domain are delivered without problem.)

So, my question is, why doesn't the transport map work? Or do I have something misconfigured?

Thanks,
David

From: Victor Duchovni on
On Fri, May 14, 2010 at 02:06:55PM -0600, David F. wrote:

> For a given virtual domain, I would like to send mail with a certain prefix to another process (via pipe) while all other mail gets delivered normally.
>
> Here are the (hopefully) relevant pieces of my various config files:
>
> /etc/postfix/master.cf
> list-expander unix - n n - - pipe
> flags=DRhu user=nobody:nobody argv=/usr/bin/list-expander ${recipient}
>
> /etc/postfix/transport
> /^list-.*@mydomain.com$/ list-expander:unix

This is wrong. The syntax is "transport:nexthop" not
"transport:IPC-mechanism".

The nexthop of "unix" is mostly harmless, but is clearly not what you
had in mind.

The "." in "example.com" should be escaped
in regular expressions:

/@example\.com$/

> If I ask for a delivery report (sendmail -bv 'list-test(a)mydomain.com') I get what I was expecting:

This is not subjected to recipient validation by the SMTP server. You
need to list the valid lists in a suitable table.

> <list-test(a)mydomain.com>: delivery via list-expander: delivers to
> command: /usr/bin/list-expander
>
> But the Postfix Virtual Domain Hosting Howto seems to say that what I've done above won't work:
>
> "Why does this example use a clumsy virtual alias instead of a more elegant transport mapping? The reason is that mail for the virtual mailing list would be rejected with "User unknown". "
>
> And, sure enough, when I try to send mail to my list, it bounces with "Recipient address rejected: User unknown in virtual mailbox table;". (Virtual aliases for the domain are delivered without problem.)
>
> So, my question is, why doesn't the transport map work? Or do I have something misconfigured?

A wildcard transport mapping does not make random virtual mailbox
recipients valid. You should avoid wildcard mappings and list the valid
addresses in a suitable table, identity mappings in virtual_alias_maps
will suffice in this case, but rewriting to a "list.example.com" sub-domain
would be even better, then you can ditch the fragile wild-card transport
mappings.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

From: "David F." on

On May 14, 2010, at 2:40 PM, Victor Duchovni wrote:

> A wildcard transport mapping does not make random virtual mailbox
> recipients valid. You should avoid wildcard mappings and list the valid
> addresses in a suitable table, identity mappings in virtual_alias_maps
> will suffice in this case, but rewriting to a "list.example.com" sub-domain
> would be even better, then you can ditch the fragile wild-card transport
> mappings.

Thanks. Adding an identity mapping in virtual_alias_maps worked.

David