LuKreme a écrit :
> On 16-Jan-2010, at 12:24, Wietse Venema wrote:
>>> To address that issue, I would like to be able to use another character
>>> ("_" or ".") that is commonly accepted as part of email addresses, instead.
>> Address transformation mappings are always queried at recipient
>> validation time, so you can't use a wild-card pattern to replace
>> "_" by "+" without becoming a backscatter source.
>
>
> This has been covered on the list in the past (I know, I was the supplicant
> last time).
>
> I have a fairly static user list, so I managed it this way:
>
> For local users, I have a virtual.pcre file that contains lines like:
>
> /^kremels_(.*)@kreme.com$/ kremels+${1}
>
> for the non-local (SQL users) I have another file, virtual_sql.pcre with very
> similar lines like:
>
> /^info_(.*)@domain\.tld$/ info+$...@domain\.tld
>
> and in main.cf I have:
>
> virtual_alias_maps =
> hash:$config_directory/virtual
> pcre:$config_directory/virtual.pcre,
> pcre:$config_directory/virtual_sql.pcre,
> proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf
>
> If your user list changes frequently, then this is not a really workable
> solution unless you can automate the creation of the pcre files.
>
with SQL, there is no need to use pcre. just do that in the SQL query to
avoid having to keep an external file up to date...
mysql> set @s:="foo_bar_...@example.com";
Query OK, 0 rows affected (0.00 sec)
mysql> select concat(substring(@s, 1, locate("_", @s)-1), "+",
substring(@s, locate("_", @s)+1)) ;
+------------------------------------------------------------------------------------+
| concat(substring(@s, 1, locate("_", @s)-1), "+", substring(@s,
locate("_", @s)+1)) |
+------------------------------------------------------------------------------------+
| foo+bar_...@example.com
|
+------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
