Re: RE: virtual_alias_maps / mysql problem
Ah, thank you, that led me into the exact right direction! =) i changed the way dovecot checks, if the user exists, and now it works fine. ^_^; just for curiosity, what exactly would i need to feed to the virtual_maibox_maps or rather, what does it expect to get from whatever backend put there? the virtual-readme gives the example i...@example.comexample.com/info is example.com/info the actual directory where the mails are supposed to end up relative to some other directory? or did i read that wrong? best regards and thanks again =) sil Original-Nachricht Datum: Sun, 11 Dec 2011 21:58:55 + Von: James Day james@ontraq.com An: lupin...@gmx.net lupin...@gmx.net, postfix-users@postfix.org postfix-users@postfix.org Betreff: RE: virtual_alias_maps / mysql problem I think you need to be using virtual_mailbox_maps to create a list of valid recipients. Also I can see that dovecot has also accepted the message so you must have configured something like allow_all_users=yes. From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] On Behalf Of lupin...@gmx.net [lupin...@gmx.net] Sent: Sunday, December 11, 2011 4:31 PM To: postfix-users@postfix.org Subject: Re: virtual_alias_maps / mysql problem thank you for the hint! i activated the query-log and the query is executed ok. i also checked it via postmap -q hutzenp...@domain.de mysql:/etc/postfix/mysql-virtual.cf (which correctly did not return anything) and postmap -q correctu...@domain.de mysql:/etc/postfix/mysql-virtual.cf which did return the correct entry, e.g. user169 so it seems mysql is not at fault. also, when i tested it with a hash-file, it sent successfully to an address that was not listed in said file. unfortunately, now i guess i´ll have to check any and all other config parameters that have anything to do with virtual delivery ^_^; here goes the postconf -n: broken_sasl_auth_clients = yes config_directory = /etc/postfix inet_interfaces = 192.168.12.7 127.0.0.1 mailbox_size_limit = 0 message_size_limit = 2048 mydestination = localhost mydomain = domain.de myhostname = mail.domain.de mynetworks = 192.168.12.0/24 127.0.0.0/8 myorigin = $mydomain relayhost = smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = mail.domain.de smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/certs/cert.pem smtpd_tls_cert_file = /etc/certs/cert.pem smtpd_tls_key_file = /etc/certs/key.pem smtpd_tls_received_header = no smtpd_use_tls = yes transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf virtual_mailbox_domains = domain.de virtual_transport = dovecot transport_maps reads thus: domain.de : .domain.de : * smtp:192.168.12.8 (this is the external firewall-postfix-server) the mail.log reads thus: Dec 11 17:05:05 mehl postfix/smtpd[16897]: connect from unknown[192.168.12.1] Dec 11 17:05:05 mehl postfix/smtpd[16897]: DD60514A03F3: client=unknown[192.168.12.1], sasl_method=PLAIN, sasl_username=user169 Dec 11 17:05:05 mehl postfix/cleanup[16901]: DD60514A03F3: message-id=4ee4d4b2.2020...@domain.de Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: from=s@domain.de, size=858, nrcpt=1 (queue active) Dec 11 17:05:06 mehl postfix/smtpd[16897]: disconnect from unknown[192.168.12.1] Dec 11 17:05:06 mehl postfix/pipe[16902]: DD60514A03F3: to=grmbl...@domain.de, relay=dovecot, delay=0.32, delays=0.18/0/0/0.14, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: removed the address grmblash does not really exist ;-), when i send to an existing address, the only difference is that postfix/pipe has the correct target as to, e.g. user...@dmain.de thank you all for you hints, i hope this help shed some light on the problem. =) best regards sil Original-Nachricht Datum: Sun, 11 Dec 2011 15:26:40 +0100 Von: Reindl Harald h.rei...@thelounge.net An: postfix-users@postfix.org Betreff: Re: virtual_alias_maps / mysql problem Am 11.12.2011 15:18, schrieb lupin...@gmx.net: thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work
virtual_alias_maps / mysql problem
Hello! i´m not quite sure if the problem is directly the virtual_alias_maps or something it interacts with, so to say. in main.cf i set virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf unverified_recipient_reject_code = 550 unknown_local_recipient_reject_code = 550 and in mysql-virtual.cf # the user name and password to log into the mysql server hosts = 127.0.0.1 user = mailcheck password = secretpassword dbname = mails table = virtual select_field = dest where_field = alias now, if i try to send to an address on the server that does not exist, it should refuse, right? unfortunately it, postfix just hands it over to dovecot, as if everything was fine =( I´m currently not completely sure, if the problem lies with the postfix-configuration or with the mysql-query (e.g. if it always returns ok, even if the entry wasn´t found). But I´m currently not sure, how to test this. When i directly make the query in sql, it works fine (aka, it returns an empty result, if the mailaddress is not equal to one of the aliases). i also tried to change the mysql-virtual.cf so that it uses a query (query = SELECT dest FROM virtual WHERE alias = %s;), but the behavior did not change. mind you, when there´s an error in this file, i can´t send any mails, so it seems to be used in some way or other. -_-; any hints would be appreciated =) best regards sil -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
RE: virtual_alias_maps / mysql problem
First make sure that the domain you are sending to is set as a virtual mailbox domain. It sounds like you've already set the virtual transport to dovecot which is right. If you think mysql is the issue try making a virtual alias maps hash file. ***Sent via RoadSync® for Android™ -Original Message- From: lupin...@gmx.net Sent: Dec 11, 2011 1:21 PM To: postfix-users@postfix.org Subject: virtual_alias_maps / mysql problem Hello! i´m not quite sure if the problem is directly the virtual_alias_maps or something it interacts with, so to say. in main.cf i set virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf unverified_recipient_reject_code = 550 unknown_local_recipient_reject_code = 550 and in mysql-virtual.cf # the user name and password to log into the mysql server hosts = 127.0.0.1 user = mailcheck password = secretpassword dbname = mails table = virtual select_field = dest where_field = alias now, if i try to send to an address on the server that does not exist, it should refuse, right? unfortunately it, postfix just hands it over to dovecot, as if everything was fine =( I´m currently not completely sure, if the problem lies with the postfix-configuration or with the mysql-query (e.g. if it always returns ok, even if the entry wasn´t found). But I´m currently not sure, how to test this. When i directly make the query in sql, it works fine (aka, it returns an empty result, if the mailaddress is not equal to one of the aliases). i also tried to change the mysql-virtual.cf so that it uses a query (query = SELECT dest FROM virtual WHERE alias = %s;), but the behavior did not change. mind you, when there´s an error in this file, i can´t send any mails, so it seems to be used in some way or other. -_-; any hints would be appreciated =) best regards sil -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: RE: virtual_alias_maps / mysql problem
thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work =) is there some handy way of testing, what postfix receives from this mysql-check? best regards sil Original-Nachricht Datum: Sun, 11 Dec 2011 14:04:15 + Von: James Day james@ontraq.com An: lupin...@gmx.net lupin...@gmx.net, postfix-users@postfix.org postfix-users@postfix.org Betreff: RE: virtual_alias_maps / mysql problem First make sure that the domain you are sending to is set as a virtual mailbox domain. It sounds like you've already set the virtual transport to dovecot which is right. If you think mysql is the issue try making a virtual alias maps hash file. ***Sent via RoadSync® for Android™ -Original Message- From: lupin...@gmx.net Sent: Dec 11, 2011 1:21 PM To: postfix-users@postfix.org Subject: virtual_alias_maps / mysql problem Hello! i´m not quite sure if the problem is directly the virtual_alias_maps or something it interacts with, so to say. in main.cf i set virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf unverified_recipient_reject_code = 550 unknown_local_recipient_reject_code = 550 and in mysql-virtual.cf # the user name and password to log into the mysql server hosts = 127.0.0.1 user = mailcheck password = secretpassword dbname = mails table = virtual select_field = dest where_field = alias now, if i try to send to an address on the server that does not exist, it should refuse, right? unfortunately it, postfix just hands it over to dovecot, as if everything was fine =( I´m currently not completely sure, if the problem lies with the postfix-configuration or with the mysql-query (e.g. if it always returns ok, even if the entry wasn´t found). But I´m currently not sure, how to test this. When i directly make the query in sql, it works fine (aka, it returns an empty result, if the mailaddress is not equal to one of the aliases). i also tried to change the mysql-virtual.cf so that it uses a query (query = SELECT dest FROM virtual WHERE alias = %s;), but the behavior did not change. mind you, when there´s an error in this file, i can´t send any mails, so it seems to be used in some way or other. -_-; any hints would be appreciated =) best regards sil -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: virtual_alias_maps / mysql problem
Well a hash file would be the simplest thing to ensure that postfix is configured properly. I would have thought that all the information you need to see what is going on would be in the mail log and the mysql log. ***Sent via RoadSync® for Android™ -Original Message- From: lupin...@gmx.net Sent: Dec 11, 2011 2:19 PM To: postfix-users@postfix.org Subject: Re: RE: virtual_alias_maps / mysql problem thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work =) is there some handy way of testing, what postfix receives from this mysql-check? best regards sil Original-Nachricht Datum: Sun, 11 Dec 2011 14:04:15 + Von: James Day james@ontraq.com An: lupin...@gmx.net lupin...@gmx.net, postfix-users@postfix.org postfix-users@postfix.org Betreff: RE: virtual_alias_maps / mysql problem First make sure that the domain you are sending to is set as a virtual mailbox domain. It sounds like you've already set the virtual transport to dovecot which is right. If you think mysql is the issue try making a virtual alias maps hash file. ***Sent via RoadSync® for Android™ -Original Message- From: lupin...@gmx.net Sent: Dec 11, 2011 1:21 PM To: postfix-users@postfix.org Subject: virtual_alias_maps / mysql problem Hello! i´m not quite sure if the problem is directly the virtual_alias_maps or something it interacts with, so to say. in main.cf i set virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf unverified_recipient_reject_code = 550 unknown_local_recipient_reject_code = 550 and in mysql-virtual.cf # the user name and password to log into the mysql server hosts = 127.0.0.1 user = mailcheck password = secretpassword dbname = mails table = virtual select_field = dest where_field = alias now, if i try to send to an address on the server that does not exist, it should refuse, right? unfortunately it, postfix just hands it over to dovecot, as if everything was fine =( I´m currently not completely sure, if the problem lies with the postfix-configuration or with the mysql-query (e.g. if it always returns ok, even if the entry wasn´t found). But I´m currently not sure, how to test this. When i directly make the query in sql, it works fine (aka, it returns an empty result, if the mailaddress is not equal to one of the aliases). i also tried to change the mysql-virtual.cf so that it uses a query (query = SELECT dest FROM virtual WHERE alias = %s;), but the behavior did not change. mind you, when there´s an error in this file, i can´t send any mails, so it seems to be used in some way or other. -_-; any hints would be appreciated =) best regards sil -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: virtual_alias_maps / mysql problem
Am 11.12.2011 15:18, schrieb lupin...@gmx.net: thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work =) is there some handy way of testing, what postfix receives from this mysql-check? what about activate querylog in mysqld to look what really happens and cp interesting queries into a mysql-shell to look at the results? signature.asc Description: OpenPGP digital signature
Re: virtual_alias_maps / mysql problem
thank you for the hint! i activated the query-log and the query is executed ok. i also checked it via postmap -q hutzenp...@domain.de mysql:/etc/postfix/mysql-virtual.cf (which correctly did not return anything) and postmap -q correctu...@domain.de mysql:/etc/postfix/mysql-virtual.cf which did return the correct entry, e.g. user169 so it seems mysql is not at fault. also, when i tested it with a hash-file, it sent successfully to an address that was not listed in said file. unfortunately, now i guess i´ll have to check any and all other config parameters that have anything to do with virtual delivery ^_^; here goes the postconf -n: broken_sasl_auth_clients = yes config_directory = /etc/postfix inet_interfaces = 192.168.12.7 127.0.0.1 mailbox_size_limit = 0 message_size_limit = 2048 mydestination = localhost mydomain = domain.de myhostname = mail.domain.de mynetworks = 192.168.12.0/24 127.0.0.0/8 myorigin = $mydomain relayhost = smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = mail.domain.de smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/certs/cert.pem smtpd_tls_cert_file = /etc/certs/cert.pem smtpd_tls_key_file = /etc/certs/key.pem smtpd_tls_received_header = no smtpd_use_tls = yes transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf virtual_mailbox_domains = domain.de virtual_transport = dovecot transport_maps reads thus: domain.de : .domain.de : * smtp:192.168.12.8 (this is the external firewall-postfix-server) the mail.log reads thus: Dec 11 17:05:05 mehl postfix/smtpd[16897]: connect from unknown[192.168.12.1] Dec 11 17:05:05 mehl postfix/smtpd[16897]: DD60514A03F3: client=unknown[192.168.12.1], sasl_method=PLAIN, sasl_username=user169 Dec 11 17:05:05 mehl postfix/cleanup[16901]: DD60514A03F3: message-id=4ee4d4b2.2020...@domain.de Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: from=s@domain.de, size=858, nrcpt=1 (queue active) Dec 11 17:05:06 mehl postfix/smtpd[16897]: disconnect from unknown[192.168.12.1] Dec 11 17:05:06 mehl postfix/pipe[16902]: DD60514A03F3: to=grmbl...@domain.de, relay=dovecot, delay=0.32, delays=0.18/0/0/0.14, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: removed the address grmblash does not really exist ;-), when i send to an existing address, the only difference is that postfix/pipe has the correct target as to, e.g. user...@dmain.de thank you all for you hints, i hope this help shed some light on the problem. =) best regards sil Original-Nachricht Datum: Sun, 11 Dec 2011 15:26:40 +0100 Von: Reindl Harald h.rei...@thelounge.net An: postfix-users@postfix.org Betreff: Re: virtual_alias_maps / mysql problem Am 11.12.2011 15:18, schrieb lupin...@gmx.net: thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work =) is there some handy way of testing, what postfix receives from this mysql-check? what about activate querylog in mysqld to look what really happens and cp interesting queries into a mysql-shell to look at the results? -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
RE: virtual_alias_maps / mysql problem
I think you need to be using virtual_mailbox_maps to create a list of valid recipients. Also I can see that dovecot has also accepted the message so you must have configured something like allow_all_users=yes. From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] On Behalf Of lupin...@gmx.net [lupin...@gmx.net] Sent: Sunday, December 11, 2011 4:31 PM To: postfix-users@postfix.org Subject: Re: virtual_alias_maps / mysql problem thank you for the hint! i activated the query-log and the query is executed ok. i also checked it via postmap -q hutzenp...@domain.de mysql:/etc/postfix/mysql-virtual.cf (which correctly did not return anything) and postmap -q correctu...@domain.de mysql:/etc/postfix/mysql-virtual.cf which did return the correct entry, e.g. user169 so it seems mysql is not at fault. also, when i tested it with a hash-file, it sent successfully to an address that was not listed in said file. unfortunately, now i guess i´ll have to check any and all other config parameters that have anything to do with virtual delivery ^_^; here goes the postconf -n: broken_sasl_auth_clients = yes config_directory = /etc/postfix inet_interfaces = 192.168.12.7 127.0.0.1 mailbox_size_limit = 0 message_size_limit = 2048 mydestination = localhost mydomain = domain.de myhostname = mail.domain.de mynetworks = 192.168.12.0/24 127.0.0.0/8 myorigin = $mydomain relayhost = smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = mail.domain.de smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /etc/certs/cert.pem smtpd_tls_cert_file = /etc/certs/cert.pem smtpd_tls_key_file = /etc/certs/key.pem smtpd_tls_received_header = no smtpd_use_tls = yes transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf virtual_mailbox_domains = domain.de virtual_transport = dovecot transport_maps reads thus: domain.de : .domain.de : * smtp:192.168.12.8 (this is the external firewall-postfix-server) the mail.log reads thus: Dec 11 17:05:05 mehl postfix/smtpd[16897]: connect from unknown[192.168.12.1] Dec 11 17:05:05 mehl postfix/smtpd[16897]: DD60514A03F3: client=unknown[192.168.12.1], sasl_method=PLAIN, sasl_username=user169 Dec 11 17:05:05 mehl postfix/cleanup[16901]: DD60514A03F3: message-id=4ee4d4b2.2020...@domain.de Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: from=s@domain.de, size=858, nrcpt=1 (queue active) Dec 11 17:05:06 mehl postfix/smtpd[16897]: disconnect from unknown[192.168.12.1] Dec 11 17:05:06 mehl postfix/pipe[16902]: DD60514A03F3: to=grmbl...@domain.de, relay=dovecot, delay=0.32, delays=0.18/0/0/0.14, dsn=2.0.0, status=sent (delivered via dovecot service) Dec 11 17:05:06 mehl postfix/qmgr[16586]: DD60514A03F3: removed the address grmblash does not really exist ;-), when i send to an existing address, the only difference is that postfix/pipe has the correct target as to, e.g. user...@dmain.de thank you all for you hints, i hope this help shed some light on the problem. =) best regards sil Original-Nachricht Datum: Sun, 11 Dec 2011 15:26:40 +0100 Von: Reindl Harald h.rei...@thelounge.net An: postfix-users@postfix.org Betreff: Re: virtual_alias_maps / mysql problem Am 11.12.2011 15:18, schrieb lupin...@gmx.net: thank you for you reply. virtual_mailbox_domains is set, as is virtual_transport. do you mean using a hash-file to test it or for permanent use? there are some 500 mail-users on the server, who change relatively often and who have each a number of aliases..i´d rather avoid using a hash file, especially because the mysql-query is supposed to work =) is there some handy way of testing, what postfix receives from this mysql-check? what about activate querylog in mysqld to look what really happens and cp interesting queries into a mysql-shell to look at the results? -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- -- Do you know what happens to a toad struck by lightning..? The same thing that happens to anything else... -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
