Alias piping + mysql in virtual domains
Hi, I'm moving an existing domain to virtual mailboxes. All the info is stored in a mysql database. Currently all devlivery and alias mapping is working correctly; I'm using virtual_mailbox_maps, virtual_alias_maps and virtual_mailbox_domains stored in the sql backend. Problem is that aliases that pipe to a command and aren't delivered anywhere - this is most common for mailing list software like mailman and smartlist. Dropping the piped command into the destination side of an alias map results in a bounce mail, and the logs show an unknown user error. The current workaround that I'm using is to alias to another alias in /etc/aliases (obviously a flat file, not an sql backend) which is aliased to the pipe. This seems wrong and doubles the admin work, as you have to add the alias into the virtual_alias_maps sql db, and then make another alias that points to the actual pipe. Am I doing this incorrectly? Should virtual_alias_maps be able to handle a pipe and I've got something misconfigured? Using postmap -q to query the db gives the correct pipe command. It doesn't work with double quotes or without on the pipe command. Thanks - Joselito
Re: Alias piping + mysql in virtual domains
Joselito a écrit : > Hi, > > I'm moving an existing domain to virtual mailboxes. All the info is > stored in a mysql database. Currently all devlivery and alias mapping > is working correctly; I'm using virtual_mailbox_maps, > virtual_alias_maps and virtual_mailbox_domains stored in the sql > backend. > > Problem is that aliases that pipe to a command and aren't delivered > anywhere > - this is most common for mailing list software like mailman and > smartlist. Dropping the piped command into the destination side of an > alias map results in a bounce mail, and the logs show an unknown user > error. The current workaround that I'm using is to alias to another > alias in /etc/aliases (obviously a flat file, not an sql backend) which > is aliased to the pipe. > > This seems wrong and doubles the admin work, as you have to add the > alias into the virtual_alias_maps sql db, and then make another alias > that points to the actual pipe. Am I doing this incorrectly? Should > virtual_alias_maps be able to handle a pipe and I've got something > misconfigured? Using postmap -q to query the db gives the correct pipe > command. It doesn't work with double quotes or without on the pipe > command. > virtual does not execute commands. an alternative to using /etc/aliases is to create a transport in master.cf. if all your lists have addresses of the form *...@lists.example.com, then you can create a transport for lists.example.com to pass mail to your list manager. Otherwise, you can use an external MDA (such as maildrop for example).
Re: Alias piping + mysql in virtual domains
Joselito wrote: > I'm moving an existing domain to virtual mailboxes. All the info is > stored in a mysql database. Currently all devlivery and alias mapping > is working correctly; I'm using virtual_mailbox_maps, > virtual_alias_maps and virtual_mailbox_domains stored in the sql > backend. > > Problem is that aliases that pipe to a command and aren't delivered > anywhere > - this is most common for mailing list software like mailman and > smartlist. Dropping the piped command into the destination side of an > alias map results in a bounce mail, and the logs show an unknown user > error. The current workaround that I'm using is to alias to another > alias in /etc/aliases (obviously a flat file, not an sql backend) which > is aliased to the pipe. You cannot pipe to programs from virtual alias maps; use local aliases as you currently do, or route to an address that resolves (via transport_maps) to a pipe transport. -- Sahil Tandon
Re: Alias piping + mysql in virtual domains
Sahil Tandon: > Joselito wrote: > > > I'm moving an existing domain to virtual mailboxes. All the info is > > stored in a mysql database. Currently all devlivery and alias mapping > > is working correctly; I'm using virtual_mailbox_maps, > > virtual_alias_maps and virtual_mailbox_domains stored in the sql > > backend. > > > > Problem is that aliases that pipe to a command and aren't delivered > > anywhere > > - this is most common for mailing list software like mailman and > > smartlist. Dropping the piped command into the destination side of an > > alias map results in a bounce mail, and the logs show an unknown user > > error. The current workaround that I'm using is to alias to another > > alias in /etc/aliases (obviously a flat file, not an sql backend) which > > is aliased to the pipe. > > You cannot pipe to programs from virtual alias maps; use local aliases > as you currently do, or route to an address that resolves (via > transport_maps) to a pipe transport. See also examples in http://www.postfix.org/VIRTUAL_README.html for delivery to command. Wietse
Re: Alias piping + mysql in virtual domains
On Dec 30, 2008, at 10:45 PM, Wietse Venema wrote: Sahil Tandon: Joselito wrote: I'm moving an existing domain to virtual mailboxes. All the info is stored in a mysql database. Currently all devlivery and alias mapping is working correctly; I'm using virtual_mailbox_maps, virtual_alias_maps and virtual_mailbox_domains stored in the sql backend. Problem is that aliases that pipe to a command and aren't delivered anywhere - this is most common for mailing list software like mailman and smartlist. Dropping the piped command into the destination side of an alias map results in a bounce mail, and the logs show an unknown user error. The current workaround that I'm using is to alias to another alias in /etc/aliases (obviously a flat file, not an sql backend) which is aliased to the pipe. You cannot pipe to programs from virtual alias maps; use local aliases as you currently do, or route to an address that resolves (via transport_maps) to a pipe transport. See also examples in http://www.postfix.org/VIRTUAL_README.html for delivery to command. Wietse Ugh, that's what I get for reading everything very closely up to the point I need, instead of the whole page, where I miss the gigantic section at the bottom that talks about this issue. Whoops.
