Re: delivering mail to separate users
On Thu, Dec 20, 2012 at 12:24:30AM -0500, Simon Brereton wrote:
newu...@example.org direc...@example.org, newu...@example.org
But it occurs to me that this will create a loop - no?
No, there is no loop, virtual alias expansion eliminates exactly
this kind of loop and delivers email to the leaf address and
to its peers.
When I do this mail is only delivered to newu...@example.org and not
direc...@example.org as well.
I did postmap the virtual_alias_maps. Is there something else I should I do?
No, but you've likely misconfigured other elements of the system.
To test the table contents:
1. postconf -h virtual_alias_maps
If this contains no unexpanded ${variable} references, just set
maps=$(postconf -h virtual_alias_maps)
Otherwise, figure out what the variables expand to and set
maps=type1:table1 type2:table2 ...
for all the maps in resulting from the expansion.
2. Run:
$ postmap -fq newu...@example.com $maps
To check that the result of the expansion of the user via
$virtual_alias_maps.
3. Make sure you have not disabled virtual_alias_maps expansion via:
receive_override_options=no_address_mappings
4. Check your logs (http://www.postfix.org/DEBUG_README.html#mail)
you'll see how many recipients each message expands to, from
what original addresses, and how each recipient was or failed to be
delivered.
--
Viktor.
Re: delivering mail to separate users
On 20 December 2012 08:07, Viktor Dukhovni postfix-us...@dukhovni.org wrote:
On Thu, Dec 20, 2012 at 12:24:30AM -0500, Simon Brereton wrote:
newu...@example.org direc...@example.org, newu...@example.org
But it occurs to me that this will create a loop - no?
No, there is no loop, virtual alias expansion eliminates exactly
this kind of loop and delivers email to the leaf address and
to its peers.
When I do this mail is only delivered to newu...@example.org and not
direc...@example.org as well.
I did postmap the virtual_alias_maps. Is there something else I should I do?
No, but you've likely misconfigured other elements of the system.
To test the table contents:
1. postconf -h virtual_alias_maps
If this contains no unexpanded ${variable} references, just set
maps=$(postconf -h virtual_alias_maps)
Otherwise, figure out what the variables expand to and set
maps=type1:table1 type2:table2 ...
for all the maps in resulting from the expansion.
I think this is ok. Output is:
mail:/etc/postfix# postconf -h virtual_alias_maps
proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases
2. Run:
$ postmap -fq newu...@example.com $maps
To check that the result of the expansion of the user via
$virtual_alias_maps.
Here I ran into problems.
mail:/etc/postfix# postmap -fq newu...@example.org $maps
postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
[-q key] [map_type:]file...
postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
config_dir] [-d key] [-q key] [map_type:]file...
mail:/etc/postfix#
mail:/etc/postfix# postmap -fq newu...@example.org virtual_alias_maps
postmap: fatal: open database virtual_alias_maps.db: No such file or directory
postfix/postmap[31146]: fatal: open database virtual_alias_maps.db:
No such file or directory
But it pays to read the error messages, so...
mail:/etc/postfix# postmap -fq newu...@example.org virtual_user_aliases
direc...@example.org,newu...@example.org
Which looks good to me.
3. Make sure you have not disabled virtual_alias_maps expansion via:
receive_override_options=no_address_mappings
I'm pretty sure this isn't disabled because a different virtual_alias
in the file works (maps to one local domain and one external one).
4. Check your logs (http://www.postfix.org/DEBUG_README.html#mail)
you'll see how many recipients each message expands to, from
what original addresses, and how each recipient was or failed to be
delivered.
I did check the logs, which is how I know it wasn't delivered to both users :)
Here's the (sanitized) log out put from a test from the postmaster
account to the newuser.
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: connect from
localhost[127.0.0.1]
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: setting up TLS
connection from localhost[127.0.0.1]
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: Anonymous TLS
connection established from localhost[127.0.0.1]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Dec 20 17:16:31 mail postfix/submission/smtpd[31207]: 0F96ADC6001:
client=localhost[127.0.0.1], sasl_method=LOGIN,
sasl_username=postmas...@example.org
Dec 20 17:16:32 mail postfix/cleanup[31208]: 0F96ADC6001:
message-id=20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org
Dec 20 17:16:32 mail postfix/qmgr[17306]: 0F96ADC6001:
from=postmas...@example.org, size=934, nrcpt=1 (queue active)
Dec 20 17:16:32 mail dkimproxy.out[11740]: connect from 127.0.0.1
Dec 20 17:16:32 mail dovecot: imap-login: Login:
user=postmas...@example.org, method=PLAIN, rip=127.0.0.1, secured
Dec 20 17:16:32 mail postfix/smtpd[31210]: connect from localhost[127.0.0.1]
Dec 20 17:16:32 mail postfix/smtp[31209]: discarding EHLO keywords:
8BITMIME STARTTLS
Dec 20 17:16:32 mail postfix/smtpd[31210]: 22D2FDC6003:
client=localhost[127.0.0.1]
Dec 20 17:16:32 mail postfix/submission/smtpd[31207]: disconnect from
localhost[127.0.0.1]
Dec 20 17:16:32 mail dovecot: IMAP(postmas...@example.org):
Disconnected: Logged out bytes=693/384
Dec 20 17:16:33 mail dkimproxy.out[11740]: DKIM signing - signed;
message-id=20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org,
signer=@example.org, from=postmas...@example.org
Dec 20 17:16:33 mail postfix/cleanup[31208]: 22D2FDC6003:
message-id=20121220121630.horde.zri5flyznp9q00fu59ec...@webmail.example.org
Dec 20 17:16:33 mail postfix/qmgr[17306]: 22D2FDC6003:
from=postmas...@example.org, size=1679, nrcpt=1 (queue active)
Dec 20 17:16:33 mail postfix/smtp[31209]: 0F96ADC6001:
to=newu...@example.org, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1,
delays=1/0/0.08/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
22D2FDC6003)
Dec 20 17:16:33 mail postfix/qmgr[17306]: 0F96ADC6001: removed
Dec 20 17:16:33 mail postfix/smtpd[31210]: disconnect from localhost[127.0.0.1]
Dec 20 17:16:33 mail
Re: delivering mail to separate users
On Thu, Dec 20, 2012 at 12:25:03PM -0500, Simon Brereton wrote: I did postmap the virtual_alias_maps. Is there something else I should I do? No, but you've likely misconfigured other elements of the system. I think this is ok. Output is: mail:/etc/postfix# postconf -h virtual_alias_maps proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases So you have two tables mysql and a hash table. $ postmap -fq newu...@example.com $maps After setting maps to the exact list tables you configured. $ postmap -fq newu...@example.com \ mysql:/etc/postfix/Mail-Alias.cf \ hash:/etc/postfix/virtual_user_aliases You almost certainly have an entry for newu...@example.com in the mysql table that hides any data in the hash table. Perhaps you should list the hash table first, if you want it to take precedence over mysql. To check that the result of the expansion of the user via $virtual_alias_maps. Here I ran into problems. mail:/etc/postfix# postmap -fq newu...@example.org $maps postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file... postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file... I'm disappointed you could not then figure it out by reading the manpage, or parsing the usage: message. postmap -q key map [optionally more maps] -- Viktor.
Re: delivering mail to separate users
On 20 December 2012 12:44, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Thu, Dec 20, 2012 at 12:25:03PM -0500, Simon Brereton wrote: I did postmap the virtual_alias_maps. Is there something else I should I do? No, but you've likely misconfigured other elements of the system. I think this is ok. Output is: mail:/etc/postfix# postconf -h virtual_alias_maps proxy:mysql:/etc/postfix/Mail-Alias.cf, hash:/etc/postfix/virtual_user_aliases So you have two tables mysql and a hash table. $ postmap -fq newu...@example.com $maps After setting maps to the exact list tables you configured. $ postmap -fq newu...@example.com \ mysql:/etc/postfix/Mail-Alias.cf \ hash:/etc/postfix/virtual_user_aliases You almost certainly have an entry for newu...@example.com in the mysql table that hides any data in the hash table. Perhaps you should list the hash table first, if you want it to take precedence over mysql. With postfix it's always the simple solution. I should have seen that. Reversing the order works now - and is in fact the more correct approach. Thanks! Dec 20 18:17:49 mail dovecot: deliver(direc...@example.org): msgid=20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31973]: 777B5DC6001: to=direc...@example.org, relay=dovecot, delay=1, delays=1/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail dovecot: deliver(newu...@example.org): msgid=20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31974]: 777B5DC6001: to=newu...@example.org, relay=dovecot, delay=1, delays=1/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail dovecot: deliver(direc...@example.org): msgid=20121220131743.horde.1yqsdfyznp9q01zhfab0...@webmail.example.org: postmas...@example.org: saved mail to INBOX Dec 20 18:17:49 mail postfix/pipe[31976]: 777B5DC6001: to=direc...@example.org, orig_to=newu...@example.org, relay=dovecot, delay=1, delays=1/0.01/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 20 18:17:49 mail postfix/qmgr[31903]: 777B5DC6001: removed To check that the result of the expansion of the user via $virtual_alias_maps. Here I ran into problems. mail:/etc/postfix# postmap -fq newu...@example.org $maps postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file... postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file... I'm disappointed you could not then figure it out by reading the manpage, or parsing the usage: message. postmap -q key map [optionally more maps] That disappointment is hard to bear, but not unexpected sadly. I've had another look and I still don't get it. Except that $maps can't be expanded by the shell. I feel sure there should be a way to check not just a single file (as I did), but the actual entry from main.cf - but I'm not able to find it. Sorry. Simon
Re: delivering mail to separate users
On Thu, Dec 20, 2012 at 01:39:07PM -0500, Simon Brereton wrote:
To check that the result of the expansion of the user via
$virtual_alias_maps.
Here I ran into problems.
mail:/etc/postfix# postmap -fq newu...@example.org $maps
postmap: fatal: usage: postmap [-Nfinoprsvw] [-c config_dir] [-d key]
[-q key] [map_type:]file...
postfix/postmap[31144]: fatal: usage: postmap [-Nfinoprsvw] [-c
config_dir] [-d key] [-q key] [map_type:]file...
I'm disappointed you could not then figure it out by reading the manpage,
or parsing the usage: message.
postmap -q key map [optionally more maps]
That disappointment is hard to bear, but not unexpected sadly. I've
had another look and I still don't get it. Except that $maps can't be
expanded by the shell.
Of course it can be expanded by the shell, it is a shell variable
after all.
$ maps=
$ postmap -fq key $maps
If it were not for the possibility of unexpanded ${parameter} values
in postconf -h output you could write:
$ maps=$(postconf -h virtual_alias_maps)
$ postmap -fq key $maps
I've not looked too closely at what it would take for postconf
to be able to perform fully recursive parameter expansion. It is
apparently a bit tricky (from past conversations with Wietse). It
would be useful however.
--
Viktor.
Re: delivering mail to separate users
On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote: One of the clients I support is getting a consultant to do some sensitive work for them and so one of the directors wants to get a copy of all the mails sent to this new mail box. At first, I though I would simply set up the new mailbox (all domains are virtual) and then add an alias to virtual_alias_maps like: newu...@example.org direc...@example.org,newu...@example.org But it occurs to me that this will create a loop - no? No, there is no loop, virtual alias expansion eliminates exactly this kind of loop and delivers email to the leaf address and to its peers. -- Viktor.
Re: delivering mail to separate users
On Dec 19, 2012 10:06 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote: One of the clients I support is getting a consultant to do some sensitive work for them and so one of the directors wants to get a copy of all the mails sent to this new mail box. At first, I though I would simply set up the new mailbox (all domains are virtual) and then add an alias to virtual_alias_maps like: newu...@example.org direc...@example.org,newu...@example.org But it occurs to me that this will create a loop - no? No, there is no loop, virtual alias expansion eliminates exactly this kind of loop and delivers email to the leaf address and to its peers. Sweet, thanks! Simon
Re: delivering mail to separate users
On 19 December 2012 22:05, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Dec 19, 2012 at 05:27:17PM -0500, Simon Brereton wrote: One of the clients I support is getting a consultant to do some sensitive work for them and so one of the directors wants to get a copy of all the mails sent to this new mail box. At first, I though I would simply set up the new mailbox (all domains are virtual) and then add an alias to virtual_alias_maps like: newu...@example.org direc...@example.org,newu...@example.org But it occurs to me that this will create a loop - no? No, there is no loop, virtual alias expansion eliminates exactly this kind of loop and delivers email to the leaf address and to its peers. -- Viktor. Viktor When I do this mail is only delivered to newu...@example.org and not direc...@example.org as well. I did postmap the virtual_alias_maps. Is there something else I should I do? Thanks. Simon
