RE: Catch-all virtual alias
Hi, I would like to thank all of you for your helpful remarks. It would be great if postfix would support such aliases in the future and I understood that the current behavior is correctly documented in the virtual readme file. However, some hint in the postconf manual probably would be helpful. Kind regards, Christoph From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Charles Marcus Sent: Monday, November 11, 2013 9:59 PM To: postfix-users@postfix.org Subject: Re: Catch-all virtual alias On 2013-11-11 2:30 PM, Viktor Dukhovni postfix-us...@dukhovni.org mailto:postfix-us...@dukhovni.org wrote: It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @example.org with @example.net. Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way... -- Best regards, Charles
Re: Catch-all virtual alias
On Mon, Nov 11, 2013 at 03:59:11PM -0500, Charles Marcus wrote: On 2013-11-11 2:30 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @example.org with @example.net. Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way... No programming is necessary; all you need is SQL. Most simply, a query which receives input of u...@example.org and then does a lookup of u...@example.net. A well-thought-out SQL schema can automate this. Similarly, LDAP offers means of doing this. For those using neither SQL nor LDAP, trivial scripting can generate and maintain complete user maps. As Viktor said, while a domain aliasing feature might be worth considering for an eventual Postfix 3.0, it's probably not worth implementing here in Postfix 2.x. Maybe a few examples added to VIRTUAL_README? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Catch-all virtual alias
/dev/rob0: On Mon, Nov 11, 2013 at 03:59:11PM -0500, Charles Marcus wrote: On 2013-11-11 2:30 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @example.org with @example.net. Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way... No programming is necessary; all you need is SQL. Most simply, a query which receives input of u...@example.org and then does a lookup of u...@example.net. A well-thought-out SQL schema can automate this. Similarly, LDAP offers means of doing this. For those using neither SQL nor LDAP, trivial scripting can generate and maintain complete user maps. As Viktor said, while a domain aliasing feature might be worth considering for an eventual Postfix 3.0, it's probably not worth implementing here in Postfix 2.x. Maybe a few examples added to VIRTUAL_README? I welcome *SQL and LDAP examples. As for 'fixing' Postfix recipient address validation, doing a half-assed job that handles only @domain-@domain and other 1-1 canonical/virtual alias mappings may not be hard, but doing a complete job would require a redesign. Wietse
Re: Catch-all virtual alias
On Tue, Nov 12, 2013 at 11:45:51AM -0500, Wietse Venema wrote: /dev/rob0: As Viktor said, while a domain aliasing feature might be worth considering for an eventual Postfix 3.0, it's probably not worth implementing here in Postfix 2.x. Maybe a few examples added to VIRTUAL_README? I welcome *SQL and LDAP examples. I'll do one for sqlite (which would also work for pgsql), if no one beats me to it. :) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Catch-all virtual alias
On 11/12/2013 10:45 AM, Wietse Venema wrote: As for 'fixing' Postfix recipient address validation, doing a half-assed job that handles only @domain-@domain and other 1-1 canonical/virtual alias mappings may not be hard, but doing a complete job would require a redesign. Wietse Recipient address verification currently has some blind spots. Reducing those blind spots -- even if they can't be totally eliminated -- is still an improvement. -- Noel Jones
Re: Catch-all virtual alias
Noel Jones: On 11/12/2013 10:45 AM, Wietse Venema wrote: As for 'fixing' Postfix recipient address validation, doing a half-assed job that handles only @domain-@domain and other 1-1 canonical/virtual alias mappings may not be hard, but doing a complete job would require a redesign. Recipient address verification currently has some blind spots. Reducing those blind spots -- even if they can't be totally eliminated -- is still an improvement. Yes, I was just lowering expectations. A redesign is not in the budget, but the half-assed job may actually happen. Wietse
Re: Catch-all virtual alias
On 11/12/2013 2:20 PM, Wietse Venema wrote: Noel Jones: On 11/12/2013 10:45 AM, Wietse Venema wrote: As for 'fixing' Postfix recipient address validation, doing a half-assed job that handles only @domain-@domain and other 1-1 canonical/virtual alias mappings may not be hard, but doing a complete job would require a redesign. Recipient address verification currently has some blind spots. Reducing those blind spots -- even if they can't be totally eliminated -- is still an improvement. Yes, I was just lowering expectations. A redesign is not in the budget, but the half-assed job may actually happen. Wietse Not too slow, not too fast. Just kind of half-fast.
RE: Catch-all virtual alias
Dear Ansgar and everybody else, in short: I think postfix' behavior reflects a bug, not a feature. Please, read again my first email. I hope to make it clear with the following remarks: $virtual_mailbox_domains lists *domains*, so its content should look like this: example.net I am sorry, you're absolutely right. Actually my mysql tables list only pure domain names in virtual_mailbox_domains. By accident, I added the '@' in my first email. Thus, there is no problem in this direction. User mappings, including catch-alls, should go into the respective map. In case of virtual mailboxes you must map the catch-all to an existing mailbox in $virtual_mailbox_maps, e.g.: f...@example.net example.net/foo b...@example.net example.net/bar @example.net example.net/bar As described, I don't have any catch-all in virtual_mailbox_maps. What I have and what works perfectly is foo@anotherdomain in virtual_mailbox_maps. It is the only mailbox. Since virtual_transport is dovecot, there is no need to specify the mailbox name here. However, if virtual_transport would be virtual and if I would specify mailboxes here, the problem would be exactly the same. The only catch all is in virtual_alias_maps. This catch-all forwards all emails from @domain to @anotherdomain, not to a specific user@ anotherdomain. A better approach (unless you really need a catch-all, which I somehow doubt) would be to auto-generate a virtual alias map by reading the virtual mailbox map and creating a mapping for each address found in it: f...@example.com f...@example.net b...@example.com b...@example.net ... Yes, this would be a nice workaround. But it would be much better, if postfix would correctly handle virtual alias forwards with the pattern @domain - @anotherdomain, with anotherdomain being a virtual mailbox domain. See my original email for a complete example. In fact, postfix *ignores* virtual_mailbox_maps when there is a valid virtual_alias_maps entry pointing to a virtual mailbox domain, thereby creating mailboxes that should not exist and accepting mail that should actually be rejected. I consider this a bug, not a feature. Neither the manual for virtual_mailbox_maps nor the one for virtual_alias_maps says that the restriction from virtual_mailbox_maps is being ignored if there is a valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I am wrong, but I am pretty sure. What do you think? Kind regards, Christoph
Re: Catch-all virtual alias
On 2013-11-11 Christoph Kling wrote: User mappings, including catch-alls, should go into the respective map. In case of virtual mailboxes you must map the catch-all to an existing mailbox in $virtual_mailbox_maps, e.g.: f...@example.net example.net/foo b...@example.net example.net/bar @example.net example.net/bar As described, I don't have any catch-all in virtual_mailbox_maps. What I have and what works perfectly is foo@anotherdomain in virtual_mailbox_maps. It is the only mailbox. Since virtual_transport is dovecot, there is no need to specify the mailbox name here. However, if virtual_transport would be virtual and if I would specify mailboxes here, the problem would be exactly the same. The only catch all is in virtual_alias_maps. This catch-all forwards all emails from @domain to @anotherdomain, not to a specific user@ anotherdomain. Don't do this. Ever. Postfix does not recursively resolve wildcard alias mappings, so it correctly translates addresses from one domain to the other, and bounces if the outcome is not a valid mailbox or forward. Besides, the VIRTUAL_README that I already referred you to clearly states: NEVER put a virtual MAILBOX wild-card in the virtual ALIAS file!! A better approach (unless you really need a catch-all, which I somehow doubt) would be to auto-generate a virtual alias map by reading the virtual mailbox map and creating a mapping for each address found in it: f...@example.com f...@example.net b...@example.com b...@example.net ... Yes, this would be a nice workaround. But it would be much better, if postfix would correctly handle virtual alias forwards with the pattern @domain - @anotherdomain, with anotherdomain being a virtual mailbox domain. See my original email for a complete example. In fact, postfix *ignores* virtual_mailbox_maps when there is a valid virtual_alias_maps entry pointing to a virtual mailbox domain, thereby creating mailboxes that should not exist and accepting mail that should actually be rejected. No. Postfix behaves as documented, but you chose to ignore the documentation. Don't blame Postfix for your own negligence. I consider this a bug, not a feature. Neither the manual for virtual_mailbox_maps nor the one for virtual_alias_maps says that the restriction from virtual_mailbox_maps is being ignored if there is a valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I am wrong, but I am pretty sure. What do you think? You're free to file a bug report, but I can practically guarantee you that it will be discarded, since the virtual mailbox configuration example in the VIRTUAL_README clearly tells you not to do what you're doing. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Catch-all virtual alias
On Mon, Nov 11, 2013 at 07:18:01PM +0100, Ansgar Wiechers wrote:
I consider this a bug, not a feature. Neither the manual for
virtual_mailbox_maps nor the one for virtual_alias_maps says that the
restriction from virtual_mailbox_maps is being ignored if there is a
valid virtual_alias_maps entry for a virtual_mailbox_domain. Maybe I
am wrong, but I am pretty sure. What do you think?
You're free to file a bug report, but I can practically guarantee you
that it will be discarded, since the virtual mailbox configuration
example in the VIRTUAL_README clearly tells you not to do what you're
doing.
It is not entirely unreasonable to expect address validation to
handle 1-to-1 aliasing of @example.org with @example.net. So I
would not say that the request will be discarded, but a correct
implementation of such rewriting would be a major change in Postfix
internals and user interface and would be more than a bug fix.
Perhaps in Postfix 3.0 (yes I do recall the thread where nobody
voted for 3.0). Arguably, since canonical mapping is restricted
to be 1-to-1, Postfix smtpd(8) could expand canonical mappings
before validating addresses, but it is not clear that this would
be sufficient.
Validation with 1-to-many mappings (virtual rewriting) is a pain.
You pay the full cost of expanding a large group just to verify
that it exists, such expansion can be rather time consuming. SMTP
clients are generally more patient after . than after RCPT TO.
I've built configurations where smptd(8) sees a different definition
of virtual_alias_maps than cleanup(8). The smtpd(8) version just
checks for a group's existence (maps mail-mail), while the cleanup(8)
version expands the group to its list of members (maps mail-{member-maildrop}).
Suffice it to say that for the moment people have learned to live
with the limitation.
Perhaps the right solution is to define a new 1-to-1 rewriting
mechanism that is applied to RCPT TO directly by smtpd(8) before
validation. This would be a more suitable mechanism for the task
than smtpd_command_filter that would be more accurate than fiddling
with regexps and can use additional lookup tables.
Anyway this requires new inspiration to build just right the first
time.
--
Viktor.
Re: Catch-all virtual alias
On 2013-11-11 2:30 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: It is not entirely unreasonable to expect address validation to handle 1-to-1 aliasing of @example.org with @example.net. Postfixadmin, an excellent tool for managing userdbs in mysql/postgresql, has had 1-to-1 domain aliasing for a long time, and it works just fine... so, unltil postfix supports this natively, it can still be done now, and if you don't want to use postfixadmin, I'm sure a competent programmer could 'use the source' and implement it their own way... -- Best regards, */Charles/*
Re: Catch-all virtual alias
On 2013-11-10 Christoph Kling wrote: virtual_alias_domains = virtual_alias_maps = hash file with contents: @domain @anotherdomain virtual_mailbox_domains = hash file with contents: @anotherdomain virtual_mailbox_maps = hash file with contents: foo@anotherdomain $virtual_mailbox_domains lists *domains*, so its content should look like this: example.net User mappings, including catch-alls, should go into the respective map. In case of virtual mailboxes you must map the catch-all to an existing mailbox in $virtual_mailbox_maps, e.g.: f...@example.net example.net/foo b...@example.net example.net/bar @example.net example.net/bar The catch-all mapping must be the last mapping in the list, and you need to make sure that you re-hash the file after it's changed. See the VIRTUAL_README [1] for further details. Make sure that you don't remove the catch-all as long as you have the wildcard domain mapping in $virtual_alias_maps, because you'd produce bounces otherwise. A better approach (unless you really need a catch-all, which I somehow doubt) would be to auto-generate a virtual alias map by reading the virtual mailbox map and creating a mapping for each address found in it: f...@example.com f...@example.net b...@example.com b...@example.net ... This can be done with a Makefile or some other script. [1] http://www.postfix.org/VIRTUAL_README.html Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
