Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
On 18.01.21 12:45, Daniel Caillibaud wrote: >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems to be ignored >(mail to aliases address are bounced with "user unknown"), and I don't find why… Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écrit : you turned on: >receive_override_options = no_address_mappings and while amavisd worked as post-queue filter, thus received mail and sent back through port 10024 where virtual aliases were xpanded, rspamd workd as milter, thus does not send back to postfix. On 18.01.21 14:52, Daniel Caillibaud wrote: Thanks a lot for pointing this out ! (it was necessary with amavis to avoid double mail on aliases, no mapping before amavis and receive_override_options=no_unknown_recipient_checks,no_header_body_checks precised in master cf for the 2nd treatment by postfix on the way back) I use it on port 10024. That way, amavis knows real recipients. Also, I use amavisd-milter on mail received on port 25. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
Le 18/01/21 à 13:13, Matus UHLAR - fantomas a écrit : > On 18.01.21 12:45, Daniel Caillibaud wrote: > >After switching to rspamd (was amavis+spamassassin), virtual_alias_maps > >seems to be ignored > >(mail to aliases address are bounced with "user unknown"), and I don't find > >why… > > you turned on: > >receive_override_options = no_address_mappings > > and while amavisd worked as post-queue filter, thus received mail and sent > back through port 10024 where virtual aliases were xpanded, rspamd workd as > milter, > thus does not send back to postfix. Thanks a lot for pointing this out ! (it was necessary with amavis to avoid double mail on aliases, no mapping before amavis and receive_override_options=no_unknown_recipient_checks,no_header_body_checks precised in master cf for the 2nd treatment by postfix on the way back) -- Daniel Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais
Re: virtual_alias_maps ignored after switching from spamassassin (amavis) to rspamd (milter)
On 18.01.21 12:45, Daniel Caillibaud wrote:
After switching to rspamd (was amavis+spamassassin), virtual_alias_maps seems
to be ignored
(mail to aliases address are bounced with "user unknown"), and I don't find why…
you turned on:
receive_override_options = no_address_mappings
and while amavisd worked as post-queue filter, thus received mail and sent
back through port 10024 where virtual aliases were xpanded, rspamd workd as
milter,
thus does not send back to postfix.
1) Before (all is fine with virtual_alias_maps)
content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 3
smtpd_milters =
unix:run/opendkim/opendkim.sock,unix:run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters
milter_connect_macros = j
2) after (virtual_alias_maps ignored)
# content_filter=amavis:[127.0.0.1]:10024
milter_protocol = 6
milter_default_action = tempfail
smtpd_milters = inet:localhost:11332
non_smtpd_milters = $smtpd_milters
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
Here is a log of a mail ok with 1)
postfix/pickup[25504]: 18D8F222ED4: uid=0 from=
postfix/cleanup[27187]: 18D8F222ED4:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
opendkim[5572]: 18D8F222ED4: DKIM-Signature field added (s=mail, d=sesamath.net)
postfix/qmgr[25505]: 18D8F222ED4: from=, size=654, nrcpt=1
(queue active)
postfix/smtpd[27196]: 4822622194E: client=localhost[127.0.0.1]
postfix/cleanup[27187]: 4822622194E:
message-id=<20210118105545.18d8f222...@mail.sesamath.net>
postfix/qmgr[25505]: 4822622194E: from=, size=1483,
nrcpt=1 (queue active)
amavis[20707]: (20707-14) Passed CLEAN {RelayedInbound}, [127.0.0.1]
-> , Message-ID:
<20210118105545.18d8f222...@mail.sesamath.net>, mail_id: kvP9WKxhumWJ, Hits: -1.791, size:
988, queued_as: 4822622194E, 211 ms
postfix/smtp[27192]: 18D8F222ED4: to=, orig_to=,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.28, delays=0.07/0/0/0.21, dsn=2.0.0, status=sent
(250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4822622194E)
postfix/qmgr[25505]: 18D8F222ED4: removed
postfix/pipe[27197]: 4822622194E: to=,
orig_to=, relay=dovecot, delay=0.15, delays=0.03/0/0/0.12,
dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[25505]: 4822622194E: removed
and the same test ko with 2)
postfix/pickup[24882]: 6DD04222ED4: uid=0 from=
postfix/cleanup[24914]: 6DD04222ED4:
message-id=<20210118103925.6dd04222...@mail.sesamath.net>
postfix/qmgr[24883]: 6DD04222ED4: from=, size=383, nrcpt=1
(queue active)
postfix/pipe[24920]: 6DD04222ED4: to=, orig_to=,
relay=dovecot, delay=0.14, delays=0.09/0.01/0/0.05, dsn=5.1.1, status=bounced (user unknown)
postfix/bounce[24922]: 6DD04222ED4: sender non-delivery notification:
87950222EDA
postfix/qmgr[24883]: 6DD04222ED4: removed
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good.
Re: virtual_alias_maps with both: regexp and mysql
> Am 09.01.2021 um 13:25 schrieb Leonardo Rodrigues : > > Em 09/01/2021 06:25, Frank Röhm escreveu: >> I would put then: >> >> /^.*@mydomain.tld$/ fr...@mydomain.tld >> >> Would that be correct? >> I don’t want to just test it, it is a productive mailserver. >> >> > > Never actually tried it, bur first thing that cames to my mind is "why > not let MySQL solve the regexp itself, instead of postfix"? > > https://dev.mysql.com/doc/refman/8.0/en/regexp.html > What is the advantage? And how would be my setting then? Another table?
Re: virtual_alias_maps with both: regexp and mysql
Em 09/01/2021 06:25, Frank Röhm escreveu: I would put then: /^.*@mydomain.tld$/ fr...@mydomain.tld Would that be correct? I don’t want to just test it, it is a productive mailserver. Never actually tried it, bur first thing that cames to my mind is "why not let MySQL solve the regexp itself, instead of postfix"? https://dev.mysql.com/doc/refman/8.0/en/regexp.html -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
Re: virtual_alias_maps doesn't require domains to be in virtual_alias_domains
Fred Morris: > With postfix 3.3.1 it appears that mappings in virtual_alias_maps are > honored without the domains being listed in virtual_alias_domains. Just > want to confirm that this is correct and intended behavior going forward. The first sendence in the manpage says: The optional virtual(5) alias table rewrites recipient addresses for all local, all virtual, and all remote mail destinations. Secrets from Postfix documentation unleashed. Wietse
Re: virtual_alias_maps combined with sender domain
thx noel! you are absolutely right - the proper way is to create a 2 restriction classes. thx again! On 12/09/2016 05:22 PM, Noel Jones wrote: > On 12/9/2016 9:11 AM, Harald Glanzer wrote: >> hi all! >> >> i am using virtual_alias_maps for a simple 'mainlinglist' configuration, i.e. >> lookup a list adress and get the expanded (local) recipients. >> >> the lookup is based on mysql: >> SELECT recipients FROM forwardings WHERE listadress='%s' >> >> is there any way to restrict this expansion s.t. it only occurs for a >> speficic >> sender domain. for example, i would love to do something like that >> SELECT recipients FROM forwardings WHERE listadress='%s' AND sender = >> '%INTERNAL_VARIABLE' >> >> where INTERNAL_VARIABLE contains the domain of the sender. i want to >> restrict this s.t. >> a virtual_alias_maps expansion occurs _only_ if the sender belongs to a >> certain domain (and has >> used SMTP auth)... >> > > > It is possible to restrict internal lists to a specific sender using > restriction classes. Here's an example: > http://www.postfix.org/RESTRICTION_CLASS_README.html#internal > > > > > -- Noel Jones > -- DI Harald Glanzer Research Industrial Systems Engineering (RISE) Forschungs-, Entwicklungs- und Großprojektberatung GmbH Concorde Business Park F 2320 Schwechat Austria Email: harald.glan...@rise-world.com Web: www.rise-world.com Firmenbuch: FN 280353i Handelsgericht Korneuburg UID: ATU62886416
Re: virtual_alias_maps combined with sender domain
On 12/9/2016 9:11 AM, Harald Glanzer wrote: > hi all! > > i am using virtual_alias_maps for a simple 'mainlinglist' configuration, i.e. > lookup a list adress and get the expanded (local) recipients. > > the lookup is based on mysql: > SELECT recipients FROM forwardings WHERE listadress='%s' > > is there any way to restrict this expansion s.t. it only occurs for a speficic > sender domain. for example, i would love to do something like that > SELECT recipients FROM forwardings WHERE listadress='%s' AND sender = > '%INTERNAL_VARIABLE' > > where INTERNAL_VARIABLE contains the domain of the sender. i want to restrict > this s.t. > a virtual_alias_maps expansion occurs _only_ if the sender belongs to a > certain domain (and has > used SMTP auth)... > It is possible to restrict internal lists to a specific sender using restriction classes. Here's an example: http://www.postfix.org/RESTRICTION_CLASS_README.html#internal -- Noel Jones
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
Hi Wietse, So it means that there is a postfix wrong behavior? Alfredo - Mensagem original - De: "Wietse Venema" <wie...@porcupine.org> Para: "postfix-users" <postfix-users@postfix.org> Enviadas: Quinta-feira, 17 de março de 2016 21:09:15 Assunto: Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions Alfredo Saldanha: > Hello all, > > Why my virtual_alias_maps accounts are bypassing > smtpd_recipient_restrictions? > > Example: > > accou...@mydomain.tld accou...@mydomain.tld, accou...@mydomain.tld, > accou...@mydomain.tld > > The account1 is ok, it pass in smtpd_recipient_restrinctions, but the others > don't. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix. Wietse
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
Lucas Castro: > I still don't know what it is or was the problem. If you still have trouble using Postfix: - Include postfix (non-debug) logging showing the unexpected behavior. - Include your 'postconf -n' output. Then, someone may be able to help you. Wietse
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
please, post your postconf -n. On 18-03-2016 10:51, Alfredo Saldanha wrote: > Hi Wietse, > > So it means that there is a postfix wrong behavior? > > Alfredo > > - Mensagem original - > De: "Wietse Venema" <wie...@porcupine.org> > Para: "postfix-users" <postfix-users@postfix.org> > Enviadas: Quinta-feira, 17 de março de 2016 21:09:15 > Assunto: Re: virtual_alias_maps accounts are bypassing > smtpd_recipient_restrictions > > Alfredo Saldanha: >> Hello all, >> >> Why my virtual_alias_maps accounts are bypassing >> smtpd_recipient_restrictions? >> >> Example: >> >> accou...@mydomain.tld accou...@mydomain.tld, accou...@mydomain.tld, >> accou...@mydomain.tld >> >> The account1 is ok, it pass in smtpd_recipient_restrinctions, but the others >> don't. > TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail > > TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html > > Thank you for using Postfix. > > Wietse >
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
I still don't know what it is or was the problem. On 18-03-2016 12:20, Alfredo Saldanha wrote: > Sorry guys, now I realize what was wrong. > The problem is my configuration mistake. > My bad. > > Best regards, > > Alfredo > > - Mensagem original - > De: "Noel Jones" <njo...@megan.vbhcs.org> > Para: "postfix-users" <postfix-users@postfix.org> > Enviadas: Sexta-feira, 18 de março de 2016 11:13:08 > Assunto: Re: virtual_alias_maps accounts are bypassing > smtpd_recipient_restrictions > > On 3/18/2016 8:51 AM, Alfredo Saldanha wrote: >> Hi Wietse, >> >> So it means that there is a postfix wrong behavior? >> >> Alfredo > No one here understands your question. > > You can help us by describing exactly what is happening, compared to > what you expected to happen. > > Include postfix logging showing the unexpected behavior. > > Include your 'postconf -n' output. > > > > > -- Noel Jones >
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
Alfredo Saldanha: > Hello all, > > Why my virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions? > > Example: > > accou...@mydomain.tld accou...@mydomain.tld, accou...@mydomain.tld, > accou...@mydomain.tld > > The account1 is ok, it pass in smtpd_recipient_restrinctions, but the others > don't. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix. Wietse
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
On 3/18/2016 8:51 AM, Alfredo Saldanha wrote: > Hi Wietse, > > So it means that there is a postfix wrong behavior? > > Alfredo No one here understands your question. You can help us by describing exactly what is happening, compared to what you expected to happen. Include postfix logging showing the unexpected behavior. Include your 'postconf -n' output. -- Noel Jones
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
On Fri, Mar 18, 2016 at 10:57:03AM -0300, Lucas Castro wrote: > please, post your postconf -n. Without the relevant logging to demonstrate the issue observed by the OP, this wouldn't help. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions
Sorry guys, now I realize what was wrong. The problem is my configuration mistake. My bad. Best regards, Alfredo - Mensagem original - De: "Noel Jones" <njo...@megan.vbhcs.org> Para: "postfix-users" <postfix-users@postfix.org> Enviadas: Sexta-feira, 18 de março de 2016 11:13:08 Assunto: Re: virtual_alias_maps accounts are bypassing smtpd_recipient_restrictions On 3/18/2016 8:51 AM, Alfredo Saldanha wrote: > Hi Wietse, > > So it means that there is a postfix wrong behavior? > > Alfredo No one here understands your question. You can help us by describing exactly what is happening, compared to what you expected to happen. Include postfix logging showing the unexpected behavior. Include your 'postconf -n' output. -- Noel Jones
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
smtpd pass - - n - 500 smtpd This one. May 22 09:10:44 mx1 postfix/smtpd[1757]: NOQUEUE: reject: RCPT from xx..xxx[ddd.ddd.ddd.]: 550 5.1.1 recipi...@domain.tld: Recipient address rejected: User unknown in virtual mailbox table; from=sen...@domain.tld to=recipi...@domain.tld proto=ESMTP helo=xx..xxx 2015-05-22 18:38 GMT+03:00 Wietse Venema wie...@porcupine.org: Edgaras Luko?evi?ius: Alright. Let's try again. Thanks. There are many smtpd(8) instances; which of these is responsible for rejecting the address that should be found in virtual_alias_maps? localhost:10026 inet n - n - 200 smtpd smtpd pass - - n - 500 smtpd 2525 inet n - n - - smtpd submission inet n - n - - smtpd smtps inet n - n - - smtpd Wietse
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
main.cf: virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf master.cf: smtpd pass - - n - 500 smtpd [no -o parameter=value] With these two lines, the Postfix SMTP server will not reject recipients with user unknown when their address is listed in virtual_alias_maps. As long as the virtual_alias_maps lookup produces a result, the SMTP server will accept the mail. It does not matter what the lookup result looks like. This is in fact a known limitation of Postfix; it does not try to find out if the result address should be rejected as user unknown. If your Postfix server behaves in a different manner, then it has been modified. Wietse
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
Edgaras Luko?evi?ius: Trying to improve my report :) postmap -q recipi...@domain.tld proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf addre...@domain1.tld,addre...@domain2.tld,addre...@domain3.tld postmap -q recipi...@domain.tld proxy:mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf [empty] [fragments from main.cf and master.cf] I suggest that you look at postconf -nf output and postmap -Mf, i.e. the information that Postfix actually uses, instead of cutting and pasting fragments that you believe Postfix is using. Wietse
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
Alright. Let's try again. main.cf 2525_end_of_data_restrictions = permit_mynetworks 2525_recipient_restrictions = reject_unauth_pipelining reject_unknown_recipient_domain permit_mynetworks reject_rbl_client bl.spamcop.net reject_authenticated_sender_login_mismatch check_sender_access proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_outbound.cf permit_sasl_authenticated reject_non_fqdn_recipient permit_auth_destination reject_unauth_destination reject_unauthenticated_sender_login_mismatch reject 2525_smtpd_client_restrictions = permit_sasl_authenticated reject alias_maps = hash:/etc/aliases anvil_rate_time_unit = 5m anvil_status_update_time = 5m broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix fuglu_default_destination_recipient_limit = 1 inet_interfaces = all inet_protocols = ipv4 mail_name = [ Mail System] mail_owner = postfix message_size_limit = 3072 mydestination = mx.XX mx1.XX localhost.$mydomain localhost mydomain = XX myhostname = mx.XX mynetworks = 1.2.3.4/32 4.3.2.1/32 [::1]/128 [fe80::]/10 127.0.0.0/8 myorigin = $myhostname non_smtpd_milters = inet:127.0.0.1:8891 policyd-spf_time_limit = 3600s postscreen_access_list = permit_mynetworks postscreen_client_connection_count_limit = 200 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*1 cbl.abuseat.org*1 bl.spamcop.net*1 postscreen_dnsbl_threshold = 1 postscreen_greet_action = enforce postscreen_pre_queue_limit = 100 proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps $alias_maps, proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_inbound.cf, proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_outbound.cf, proxy:mysql:/etc/postfix/mysql/outbound_transport.cf, proxy:mysql:/etc/postfix/mysql/virtual_relayhost_maps.cf, proxy:mysql:/etc/postfix/mysql/smtpd_sender_login_maps.cf queue_directory = /var/spool/postfix recipient_bcc_maps = proxy:mysql:/etc/postfix/mysql/virtual_vacation.cf relay_domains = $mydestination sender_dependent_default_transport_maps = proxy:mysql:/etc/postfix/mysql/outbound_transport.cf sender_dependent_relayhost_maps = proxy:mysql:/etc/postfix/mysql/virtual_relayhost_maps.cf smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_count_limit = 50 smtpd_client_connection_rate_limit = 100 smtpd_client_message_rate_limit = 100 smtpd_client_new_tls_session_rate_limit = 20 smtpd_client_recipient_rate_limit = 20 smtpd_client_restrictions = permit_mynetworks reject_invalid_hostname reject_unauth_pipelining permit smtpd_end_of_data_restrictions = permit_mynetworks smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname reject_non_fqdn_helo_hostname permit smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_limit = 15 smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination check_policy_service unix:private/policyd-spf check_policy_service inet:127.0.0.1:12340 check_recipient_access proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_inbound.cf permit_sasl_authenticated check_policy_service unix:postgrey/socket permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql/smtpd_sender_login_maps.cf smtpd_sender_restrictions = permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit smtpd_tls_CApath = /etc/pki/CA/certs smtpd_tls_cert_file = /etc/pki/tls/certs/crt smtpd_tls_key_file = /etc/pki/tls/private/key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s smtps_end_of_data_restrictions = permit_mynetworks smtps_recipient_restrictions = reject_unauth_pipelining permit_mynetworks reject_rbl_client bl.spamcop.net reject_authenticated_sender_login_mismatch check_sender_access proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_outbound.cf reject_unauthenticated_sender_login_mismatch permit_sasl_authenticated reject smtps_smtpd_client_restrictions = permit_sasl_authenticated reject soft_bounce = no submission_end_of_data_restrictions = permit_mynetworks submission_recipient_restrictions = reject_unauth_pipelining permit_mynetworks
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
Edgaras Luko?evi?ius: Alright. Let's try again. Thanks. There are many smtpd(8) instances; which of these is responsible for rejecting the address that should be found in virtual_alias_maps? localhost:10026 inet n - n - 200 smtpd smtpd pass - - n - 500 smtpd 2525 inet n - n - - smtpd submission inet n - n - - smtpd smtps inet n - n - - smtpd Wietse main.cf 2525_end_of_data_restrictions = permit_mynetworks 2525_recipient_restrictions = reject_unauth_pipelining reject_unknown_recipient_domain permit_mynetworks reject_rbl_client bl.spamcop.net reject_authenticated_sender_login_mismatch check_sender_access proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_outbound.cf permit_sasl_authenticated reject_non_fqdn_recipient permit_auth_destination reject_unauth_destination reject_unauthenticated_sender_login_mismatch reject 2525_smtpd_client_restrictions = permit_sasl_authenticated reject alias_maps = hash:/etc/aliases anvil_rate_time_unit = 5m anvil_status_update_time = 5m broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix fuglu_default_destination_recipient_limit = 1 inet_interfaces = all inet_protocols = ipv4 mail_name = [ Mail System] mail_owner = postfix message_size_limit = 3072 mydestination = mx.XX mx1.XX localhost.$mydomain localhost mydomain = XX myhostname = mx.XX mynetworks = 1.2.3.4/32 4.3.2.1/32 [::1]/128 [fe80::]/10 127.0.0.0/8 myorigin = $myhostname non_smtpd_milters = inet:127.0.0.1:8891 policyd-spf_time_limit = 3600s postscreen_access_list = permit_mynetworks postscreen_client_connection_count_limit = 200 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*1 cbl.abuseat.org*1 bl.spamcop.net*1 postscreen_dnsbl_threshold = 1 postscreen_greet_action = enforce postscreen_pre_queue_limit = 100 proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps $alias_maps, proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_inbound.cf, proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_outbound.cf, proxy:mysql:/etc/postfix/mysql/outbound_transport.cf, proxy:mysql:/etc/postfix/mysql/virtual_relayhost_maps.cf, proxy:mysql:/etc/postfix/mysql/smtpd_sender_login_maps.cf queue_directory = /var/spool/postfix recipient_bcc_maps = proxy:mysql:/etc/postfix/mysql/virtual_vacation.cf relay_domains = $mydestination sender_dependent_default_transport_maps = proxy:mysql:/etc/postfix/mysql/outbound_transport.cf sender_dependent_relayhost_maps = proxy:mysql:/etc/postfix/mysql/virtual_relayhost_maps.cf smtpd_banner = $myhostname ESMTP $mail_name smtpd_client_connection_count_limit = 50 smtpd_client_connection_rate_limit = 100 smtpd_client_message_rate_limit = 100 smtpd_client_new_tls_session_rate_limit = 20 smtpd_client_recipient_rate_limit = 20 smtpd_client_restrictions = permit_mynetworks reject_invalid_hostname reject_unauth_pipelining permit smtpd_end_of_data_restrictions = permit_mynetworks smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname reject_non_fqdn_helo_hostname permit smtpd_milters = inet:127.0.0.1:8891 smtpd_recipient_limit = 15 smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination check_policy_service unix:private/policyd-spf check_policy_service inet:127.0.0.1:12340 check_recipient_access proxy:mysql:/etc/postfix/mysql/filter_recipient_domains_inbound.cf permit_sasl_authenticated check_policy_service unix:postgrey/socket permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql/smtpd_sender_login_maps.cf smtpd_sender_restrictions = permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit smtpd_tls_CApath = /etc/pki/CA/certs smtpd_tls_cert_file = /etc/pki/tls/certs/crt smtpd_tls_key_file = /etc/pki/tls/private/key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s
Re: virtual_alias_maps for non-existent virtual_mailbox_maps
Edgaras Luko?evi?ius: I have aliases for recipients in virtual_alias_maps that do not exist in virtual_mailbox_maps. This is for users who want to *only* have forwarding without owning any mailboxes. That should work, provided that you did do something like receive_override_options = no_address_mappings. By the documentation virtual_mailbox_maps are checked before virtual_alias_maps and so I get Recipient address rejected: User unknown in virtual mailbox table?. You made a mistake, but you failed to follow mailing list instructions in the mailing list welcome message: TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix. Show us what you did, and someone will point out the mistake. Wietse
Re: virtual_alias_maps order
LuKreme: 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 I want to be sure that the ORDER of declarations in virtual_alias_maps is significant. For example, if something matches in virtual it will always match and not be overridden by a match in virtual.pcre. Quote from virtual(5): Specify zero or more type:name lookup tables, separated by whitespace of comma. Tables will be searched in the specified order until a match is found. Note: these lookups are recursive. Thus, with virtual_alias_maps = A, B, C, a match in B terminates the search, meaning that B has precedence over C. However, lookup is recursive. The above result from B will be used for a subsequent query. That may still query A and B and C, finding a result in C. Wietse
Re: virtual_alias_maps order
On 07 Oct 2014, at 11:24 , Wietse Venema wie...@porcupine.org wrote: However, lookup is recursive. The above result from B will be used for a subsequent query. That may still query A and B and C, finding a result in C. Excellent! Than you. -- Vader means father in German. Oh, you know German. Now I know why you don't like fun things.
Re: virtual_alias_maps, continue after succesful match
On Wed, Jul 09, 2014 at 08:48:33AM +0200, Roel van Meer wrote: Basic question: if I have two virtual_mailbox_maps, is there a way to ensure lookups happen in both of them, even if the first already had a match? No. I tried using recipient_bcc_maps, and this works, but that map accepts only a single address to send bcc's to. The bcc address is itself subject to virtual alias expansion, however using this for normal non-bcc processing is likely unwise. It seems the only way to make this work is to make sure that the LDAP lookup returns external addresses and actual mailboxes in one go (like it used to do with mailacceptinggeneralid/maildrop entries). You can specify multiple result attributes, any of which can be multi-valued. -- Viktor.
Re: virtual_alias_maps, continue after succesful match
Am 09.07.2014 08:48, schrieb Roel van Meer: Hi list! I'm in the process of converting our Postfix/OpenLDAP system to Postfix/Samba 4/Zarafa. The OpenLDAP structure contained mailacceptinggeneralid entries, with maildrop attributes for both local and remote addresses. The problem is that this does not fit the Zarafa way. Basic question: if I have two virtual_mailbox_maps, is there a way to ensure lookups happen in both of them, even if the first already had a match? What I would like to do is this: virtual_mailbox_maps = hash:/etc/postfix/external, ldap:/etc/postfix/zarafa-aliases.cf which, (for the sake of this explanation) can be simplified to this: virtual_mailbox_maps = hash:/etc/postfix/external, hash:/etc/postfix/zarafa-aliases /etc/postfix/external: i...@example.tldi...@example.tld, somewh...@gmail.com /etc/postfix/zarafa-aliases i...@example.tldus...@example.tld, us...@example.tld So, the lookup in the first table would result in an expansion to include external addresses, and the lookup in the second table would expand the address to actual mailboxes. However, with this setup, if there's a match in the first table, the second expansion never happens. I tried using recipient_bcc_maps, and this works, but that map accepts only a single address to send bcc's to. It seems the only way to make this work is to make sure that the LDAP lookup returns external addresses and actual mailboxes in one go (like it used to do with mailacceptinggeneralid/maildrop entries). If anyone can tell me if I've overlooked something, I'd be grateful! Kind regards, Roel You could use a mail filter like Sieve to redirect messages to the external addresses. Of course that would make maintainability a lot harder. -- Alex JOST
Re: virtual_alias_maps, continue after succesful match
Viktor Dukhovni writes: Basic question: if I have two virtual_mailbox_maps, is there a way to ensure lookups happen in both of them, even if the first already had a match? No. I was afraid it wouldn't. It seems the only way to make this work is to make sure that the LDAP lookup returns external addresses and actual mailboxes in one go (like it used to do with mailacceptinggeneralid/maildrop entries). You can specify multiple result attributes, any of which can be multi-valued. I didn't know about the multiple result attributes; that's very helpful! Thanks! Roel
Re: virtual_alias_maps, continue after succesful match
On Wed, Jul 09, 2014 at 10:40:07AM +0200, Roel van Meer wrote: You can specify multiple result attributes, any of which can be multi-valued. I didn't know about the multiple result attributes; that's very helpful! result_attribute = attr1 attr2 ... -- Viktor.
Re: virtual_alias_maps no longer working
Juerg Reimann j...@jworld.ch schrieb: Does anybody have an idea what could be wrong? Just a wild guess... Is your Postfix chroot'ed, and if so, have the listed files been copied there? Enabling debugging, what do the logs tell you about the mapping process? Cheers, Nik
Re: virtual_alias_maps no longer working
On Fri, Nov 22, 2013 at 09:00:01AM +0100, Juerg Reimann wrote: I had a perfectly working Postfix configuration, but after a server restart something went weird. Postfix claims several users are unknown. It turns out that these are aliases from my virtual_alias_maps file. I have the following in main.cf: virtual_alias_maps = dbm:/etc/postfix/vmail/alias Show postconf -n. Show complete NON-verbose logging for one such message. Show postmap -q address dbm:/etc/postfix/vmail/alias where address is the virtual alias that you think should have worked. Regarding Nik's reply, no, chroot does not sound likely, and map files do not need to be in a Postfix chroot; and no, verbose logs won't help. http://www.postfix.org/DEBUG_README.html#mail -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: virtual_alias_maps question
* Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? Yes. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote: * Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? Yes. So I have to write (and maintain) that entry like this? /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser Is there a better way?
Re: virtual_alias_maps question
* Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote: * Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? Yes. So I have to write (and maintain) that entry like this? /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser Is there a better way? That's the only way. Otherwise it would rewrite the address for all domains, even non-local ones. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: virtual_alias_maps question
Louis-David Mitterrand: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? RTFM: NAME virtual - Postfix virtual alias table format DESCRIPTION The optional virtual(5) alias table rewrites recipient addresses FOR ALL LOCAL, ALL VIRTUAL, AND ALL REMOTE MAIL DESTINATIONS. This is Wietse
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:49:43AM +0200, Louis-David Mitterrand wrote: On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote: * Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? Yes. So I have to write (and maintain) that entry like this? /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser Is there a better way? Nested, if/endif: if /@example\.(com|net|org)$/ /^(info|contact|etc)@ localuser@mydestination.domain endif Change your if line when adding more domains. This can probably be done better with SQL tricks rather than PCRE, BTW. Not worth changing to SQL if you're not already using it, of course. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 wrote: Is there a better way? Nested, if/endif: if /@example\.(com|net|org)$/ /^(info|contact|etc)@ localuser@mydestination.domain endif This is all silly, the list of virtual alias domains is known, use a Makefile to generate the boiler-plate aliases. -- Viktor.
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 forgot to terminate a PCRE expression: if /@example\.(com|net|org)$/ /^(info|contact|etc)@ localuser@mydestination.domain endif if /@example\.(com|net|org)$/ /^(info|contact|etc)@/ localuser@mydestination.domain endif -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:04:08AM -0500, /dev/rob0 wrote: On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 forgot to terminate a PCRE expression: if /@example\.(com|net|org)$/ /^(info|contact|etc)@ localuser@mydestination.domain endif if /@example\.(com|net|org)$/ /^(info|contact|etc)@/localuser@mydestination.domain endif This is really, really nice. I always forget the power of if/endif in posfix confs. Thanks!
Re: virtual_alias_maps question
On 24 Oct 2013, at 04:39 , Wietse Venema wie...@porcupine.org wrote: Louis-David Mitterrand: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? RTFM: NAME virtual - Postfix virtual alias table format DESCRIPTION The optional virtual(5) alias table rewrites recipient addresses FOR ALL LOCAL, ALL VIRTUAL, AND ALL REMOTE MAIL DESTINATIONS. This is BTW, this is very useful. My wife had used to email a bunch of different people at a edu domain, we'll call it fred.example.edu. These were not people that were in her address book or mail history, and she tyoped the domain nearly every time as ferd.example.edu. Virtual to the rescue. Something like this, IIRC. #Rewrite ferd! @ferd.example.edu @fred.example.edu -- I want to secede, but I don't know what state I'm in. - Bart Simpson, 2012
Re: virtual_alias_maps question
On 10/24/2013 11:20 PM, LuKreme wrote: On 24 Oct 2013, at 04:39 , Wietse Venema wie...@porcupine.org wrote: Louis-David Mitterrand: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? RTFM: NAME virtual - Postfix virtual alias table format DESCRIPTION The optional virtual(5) alias table rewrites recipient addresses FOR ALL LOCAL, ALL VIRTUAL, AND ALL REMOTE MAIL DESTINATIONS. This is BTW, this is very useful. My wife had used to email a bunch of different people at a edu domain, we'll call it fred.example.edu. These were not people that were in her address book or mail history, and she tyoped the domain nearly every time as ferd.example.edu. Virtual to the rescue. Something like this, IIRC. #Rewrite ferd! @ferd.example.edu @fred.example.edu Note that this will not alter headers set by the MUA. The recipient will still see the bad domain, and if you try to reply to a message where that was in the CC, it would bounce. -- J.
Re: virtual_alias_maps not being used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/2013 11:58 AM, Thomas Spuhler wrote: I have installed my brand new Kolab-3 mail server after extensive testing on a virtual box. Unfortunately, I did not test the alias feature. If I send e-mails to to root@btspuhler, I get a message back The mail system r...@btspuhler.com: host aargau.btspuhler.com[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) my main.cf looks like this: To report problems, please see: http://www.postfix.org/DEBUG_README.html#mail Specifically, main.cf snippings are not particularly helpful, always show postconf -n. receive_override_options = no_address_mappings Wonder if this has something to do with the reported problem... http://www.postfix.org/postconf.5.html#receive_override_options -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSCmkXAAoJEJGRUHb5Oh6gpswH/iCKRrPj1w+xmlYuJqVjzBAB Jp+GNCGzKltXrPZg/w51HNB+k89RvfURP4OZPgG+Ne37o/BUTA7c3KBPLDDPSTF0 KZfb/S5NZFF4BQma7DRlvmGrBbqv6CRTvOkpgBJknK69omF21P11kxoWLJSg0MIL BPFfDz8bSVdss3XmToa9iA02AiuziPDfRJW9+z+ECN2lc3/PzbhMyNksvILwoGyp 2bjswK9YsEDfdPB0SeVOw4TQg/5NkLZwupOUFvpaD0NL0apAfBWRGCZlXLoSC4SZ AA3KhpPZsUOs5SYoxdJzQNKuDfmgzrTK11S0/PZ3ySS0LDV4M+YAAA6bLH9p/2o= =n7Le -END PGP SIGNATURE-
Re: virtual_alias_maps not being used
On Tuesday, August 13, 2013 12:12:55 PM Noel Jones wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/2013 11:58 AM, Thomas Spuhler wrote: I have installed my brand new Kolab-3 mail server after extensive testing on a virtual box. Unfortunately, I did not test the alias feature. If I send e-mails to to root@btspuhler, I get a message back The mail system r...@btspuhler.com: host aargau.btspuhler.com[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) my main.cf looks like this: To report problems, please see: http://www.postfix.org/DEBUG_README.html#mail Specifically, main.cf snippings are not particularly helpful, always show postconf -n. receive_override_options = no_address_mappings Wonder if this has something to do with the reported problem... http://www.postfix.org/postconf.5.html#receive_override_options -- Noel Jones Thanks a lot. Commenting out receive_override_options = no_address_mappings solved the problem. Just for my information, is this very dependent on the postfix version? This line came from upstream -- Best regards Thomas Spuhler signature.asc Description: This is a digitally signed message part.
Re: virtual_alias_maps not being used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/2013 12:30 PM, Thomas Spuhler wrote: On Tuesday, August 13, 2013 12:12:55 PM Noel Jones wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/2013 11:58 AM, Thomas Spuhler wrote: I have installed my brand new Kolab-3 mail server after extensive testing on a virtual box. Unfortunately, I did not test the alias feature. If I send e-mails to to root@btspuhler, I get a message back The mail system r...@btspuhler.com: host aargau.btspuhler.com[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) my main.cf looks like this: To report problems, please see: http://www.postfix.org/DEBUG_README.html#mail Specifically, main.cf snippings are not particularly helpful, always show postconf -n. receive_override_options = no_address_mappings Wonder if this has something to do with the reported problem... http://www.postfix.org/postconf.5.html#receive_override_options - -- Noel Jones Thanks a lot. Commenting out receive_override_options = no_address_mappings solved the problem. Just for my information, is this very dependent on the postfix version? This line came from upstream That line is usually used with a content_filter (ie. mail passes through postfix twice with a filter in between), arranged such that address expansion is only performed once -- either pre-filter or post-filter depending on local requirements, but not both. -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSCm56AAoJEJGRUHb5Oh6gL88H/1kioIjygHbe962INyo+5oRI vIQoP1UG2lGyRXqCOLwcqgS9ZCFmYkv+swXYGbn1+pkKHKD4WJR+QsvuqthN457c i5d7avpRoJavmz+Y+GDyFhjaByvuQzqs0Ahrm1st0vWJg19RIoZFezIsgD1ivCC1 zFV05BD/SORxVdrx/jlOv4+OHz2kPW35BmE0ARv4cdlYTqRJehO7eC7X9Hcb15+W 35MI0uTB5rdkSrpmYNH7iz35snGCNkovvKSirSDrJiwivQYndzHrOyUWYjzpk/qo XmS8qTeOLhEmDTYmVryvfmF2oXosDFXBcOPEI8ckSt6ww9M3lpvfVDOFF+OKcX0= =Xx1S -END PGP SIGNATURE-
Re: virtual_alias_maps differs between internal and externally hosted domains
Forgot to add the proper postfinger file. postfinger - postfix configuration on Tue Mar 5 23:20:05 CET 2013 version: 1.30 --System Parameters-- mail_version = 2.10.0 hostname = black-mail.nl uname = Linux black-mail.nl 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux --Packaging information-- looks like this postfix comes from deb package: postfix-2.10.0-1 --main.cf non-default parameters-- alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no clamsmtp_destination_recipient_limit = 1 delay_warning_time = 4h disable_vrfy_command = yes enable_long_queue_ids = yes extraslow_destination_concurrency_failed_cohort_limit = 15 extraslow_destination_concurrency_limit = 1 extraslow_destination_rate_delay = 2s extraslow_destination_recipient_limit = 1 html_directory = /usr/share/doc/postfix/html inet_interfaces = 127.0.0.1,93.186.177.127,[2a00:d10:101::27:] mailbox_size_limit = 0 message_size_limit = 26214400 mydestination = localhost mynetworks = 127.0.0.1 myorigin = /etc/mailname postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org b.barracudacentral.org dnsbl-1.uceprotect.net bl.spamcop.net postscreen_greet_action = enforce recipient_delimiter = + slow_destination_concurrency_limit = 2 slow_destination_recipient_limit = 5 smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_helo_hostname, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, check_policy_service unix:private/policyspf, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_policy_service unix:private/quota-status smtpd_relay_restrictions = smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_login_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_authenticated_sender_login_mismatch smtpd_tls_CApath = /etc/apache2/ssl/black-mail.nl/ smtpd_tls_cert_file = /etc/apache2/ssl/black-mail.nl/ssl.crt smtpd_tls_key_file = /etc/apache2/ssl/black-mail.nl/ssl.key smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_use_tls = yes smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache spamassassin_destination_recipient_limit = 1 transport_maps = hash:/etc/postfix/transport virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf virtual_gid_maps = static:5000 virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_transport = clamsmtp:[127.0.0.1]:10025 virtual_uid_maps = static:5000 --master.cf-- smtpd pass - - - - - smtpd smtp inet n - n - 1 postscreen tlsproxy unix - - n - 0 tlsproxy dnsblog unix - - n - 0 dnsblog 616 inet n - n - - smtpd -o smtpd_etrn_restrictions=reject -o content_filter=dksign:[127.0.0.1]:10028 -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o receive_override_options=no_address_mappings -o smtpd_client_restrictions=permit_sasl_authenticated,reject submission inet n - - - - smtpd -o smtpd_etrn_restrictions=reject -o content_filter=dksign:[127.0.0.1]:10028 -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o receive_override_options=no_address_mappings -o smtpd_client_restrictions=permit_sasl_authenticated,reject pickupunix n - - 60 1 pickup -o content_filter=dksign:[127.0.0.1]:10028 cleanup unix n - - - 0 cleanup qmgr unix n - n 300 1 qmgr tlsmgrunix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounceunix - - - - 0 bounce defer unix - - - - 0 bounce trace unix - - - - 0 bounce verifyunix - - - - 1 verify flush unix n - - 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - - - - smtp relay unix - - - - - smtp showq unix n - - - - showq error unix - - - - - error retry unix - - - - - error discard unix - - - - - discard local unix -
Re: virtual_alias_maps differs between internal and externally hosted domains
On Tue, Mar 05, 2013 at 11:19:22PM +0100, Michiel Hazelhof wrote: which results in a reject, Mail.log: Mar 5 21:55:30 black-mail postfix/smtpd[19444]: NOQUEUE: reject: RCPT from domain.nl[2a00:d10:101::26:0]: 554 5.7.1 al...@hazelhof.nl: Recipient address rejected: Unknown user; from=i...@domain.nl to=al...@hazelhof.nl proto=ESMTP helo=domain.nl Nothing in Postfix generates an Unknown user response of any kind (the string Unknown user does not appear in the Postfix source code). Even such a string were returned it would not be with a 5.7.1 DSN code, which indicates site policy not address validity. Perhaps you have a milter or policy service that generates this response. -- Viktor.
Re: virtual_alias_maps map lookup problem
On 12/12/2012 02:01 AM, Wietse Venema wrote: Muzaffer: virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf .. Dec 12 01:11:27 kartagis postfix/trivial-rewrite[24213]: warning: connect to mysql server 127.0.0.1: Access denied for user 'pfuser'@'127.0.0.1' (using password: YES) Fix your mysql server. Wietse The problem was fixed. I had to replace 127.0.0.1 with localhost in mysql_virtual_* files. Thanks again, Muzaffer
Re: virtual_alias_maps map lookup problem
Muzaffer: virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf .. Dec 12 01:11:27 kartagis postfix/trivial-rewrite[24213]: warning: connect to mysql server 127.0.0.1: Access denied for user 'pfuser'@'127.0.0.1' (using password: YES) Fix your mysql server. Wietse
Re: virtual_alias_maps map lookup problem
On 12/12/2012 02:01 AM, Wietse Venema wrote: Muzaffer: virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf .. Dec 12 01:11:27 kartagis postfix/trivial-rewrite[24213]: warning: connect to mysql server 127.0.0.1: Access denied for user 'pfuser'@'127.0.0.1' (using password: YES) Fix your mysql server. Wietse If you mean my database credentials, they are correct, I've checked them again. Regards,
Fwd: Re: virtual_alias_maps map lookup problem
Original Message Subject:Re: virtual_alias_maps map lookup problem Date: Wed, 12 Dec 2012 09:01:51 +0200 From: Muzaffer Tolga Özses to...@ozses.net To: Wietse Venema wie...@porcupine.org CC: postfix users postfix-users@postfix.org On 12/12/2012 02:01 AM, Wietse Venema wrote: Muzaffer: virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf .. Dec 12 01:11:27 kartagis postfix/trivial-rewrite[24213]: warning: connect to mysql server 127.0.0.1: Access denied for user 'pfuser'@'127.0.0.1' (using password: YES) Fix your mysql server. Wietse If you mean my database credentials, they are correct, I've checked them again. Regards, One more thing. Could this have anything to do with mysql version? Regards,
Re: virtual_alias_maps ignored when used dovecot-lda?
hello list,
back again ;-)
on the dovecot list i got hint my problem must be postfix related.
( a bit of log is in mail downside )
Here is my output of postconf -n :
address_verify_negative_cache = yes
address_verify_negative_expire_time = 1d
address_verify_negative_refresh_time = 1h
address_verify_sender = ${double_bounce_sender}
allow_percent_hack = no
bounce_queue_lifetime = 2d
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id sleep 5
default_destination_concurrency_limit = 80
disable_dns_lookups = no
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
fallback_transport = virtual
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.9.3/html
inet_interfaces = xxx.9.84.1x 127.0.0.1
inet_protocols = ipv4
lmtp_destination_concurrency_limit =
${default_destination_concurrency_limit}
local_destination_concurrency_limit = 1
local_transport = local
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_domains = ${myorigin}
maximal_queue_lifetime = 2d
message_size_limit = 52428800
milter_command_timeout = 180
milter_connect_macros = b i j _ {daemon_name} {if_name} {if_addr}
milter_connect_timeout = 180
milter_content_timeout = 600
milter_default_action = accept
milter_end_of_data_macros = b i j _ {daemon_name} {if_name} {if_addr}
{mail_addr}
milter_helo_macros = {tls_version} {cipher} {cipher_bits}
{cert_subject} {cert_issuer}
milter_mail_macros = i {auth_type} {auth_authen} {auth_ssf}
{auth_author} {mail_mailer} {mail_host} {mail_addr} {client_addr}
milter_protocol = 6
milter_rcpt_macros = {rcpt_mailer} {rcpt_host} {rcpt_addr}
{client_addr}
mydestination = ${myhostname} localhost localhost.${mydomain}
mydomain = xxmail.de
myhostname = mail.xxxmail.de
mynetworks = xxx.9.84.1x/32 127.0.0.0/8
myorigin = ${myhostname}
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:127.0.0.1:8891 inet:127.0.0.1:8026
owner_request_special = no
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/lookups/cidr/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_cache_retention_time = 14d
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = swl.spamhaus.org*-4 b.barracudacentral.org*2
ix.dnsbl.manitu.net*2 bl.spamcop.net*2 l2.apews.org bl.spamcop.net
combined.rbl.msrbl.net dnsrbl.swinog.ch dnsbl.njabl.org
no-more-funn.moensted.dk db.wpbl.info psbl.surriel.com
zen.spamhaus.org*2
postscreen_dnsbl_threshold = 4
postscreen_greet_action = enforce
postscreen_greet_banner = ZBFMAIL MAILSERVER - Mailrelay and
Prefiltering Gateway - In Case of Problems contact we...@xxxmail.de
postscreen_greet_wait = ${stress?3}${stress:8}s
postscreen_helo_required = yes
proxy_read_maps = ${local_recipient_maps} ${mydestination}
${virtual_alias_maps} ${virtual_mailbox_maps} ${virtual_mailbox_domains}
${relay_recipient_maps} ${relay_domains} ${canonical_maps}
${sender_canonical_maps} ${recipient_canonical_maps} ${relocated_maps}
${transport_maps} ${mynetworks} ${virtual_mailbox_limit_maps}
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_alias_domain_catchall_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_alias_domain_mailbox_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_alias_domain_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_domains_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_alias_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_mailbox_limit_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_mailbox_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_check_sender_access.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_transport_maps.cf
proxy:mysql:${config_directory}/lookups/mysql/mysql_virtual_relay_domain_maps.cf
${smtp_sasl_auth_cache_name} ${smtpd_sender_login_maps}
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.9.3/readme
recipient_delimiter = +
relay_destination_concurrency_limit =
${default_destination_concurrency_limit}
relay_domains =
mysql:/etc/postfix/lookups/mysql/mysql_virtual_relay_domain_maps.cf
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
show_user_unknown_table_name = no
smtp_destination_concurrency_limit =
${default_destination_concurrency_limit}
smtp_sasl_auth_cache_name =
proxy:btree:${data_directory}/sasl_auth_cache
smtp_sasl_password_maps = hash:${config_directory}/saslpass
smtp_tls_CAfile = /etc/ssl/postfix/zbfmail-ca.crt
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_cert_file = /etc/ssl/postfix/zbfmail.crt
smtp_tls_key_file = /etc/ssl/postfix/zbfmail.key
Re: virtual_alias_maps ignored when used dovecot-lda?
* Marko Weber we...@zackbummfertig.de: Hello, i use virtual user and virtual domains in postfix with mysql. to existing users the mails will be delivered. but when i create a alias (postfixadmin), the mail is bounced. Jun 8 10:50:40 mail dovecot: auth-worker: sql(postmas...@zbfxxx.de): Unknown user Jun 8 10:50:40 mail postfix/pipe[20056]: 12BE02F17F: to=postmas...@zbfxxx.de, relay=dovecot, delay=0.14, delays=0.13/0/0/0.01, dsn=5.1.1, status=bounced (user unknown) Dovecot is rejecting the mail, not postfix. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
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
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
Re: virtual_alias_maps and recipient_delimiter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2011, at 2:08 PM, Noel Jones wrote: On 3/30/2011 3:53 PM, Ansgar Wiechers wrote: On 2011-03-30 Corey Quinn wrote: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ /^(.*)+/ $1...@example.com ENDIF Threw this verbatim into my generic.regexp: [root@mx1 postfix]# postmap -q user+t...@example.com regexp:generic.regexp postmap: warning: regexp map generic.regexp, line 1: Invalid preceding regular expression postmap: warning: regexp map generic.regexp, line 4: ignoring ENDIF without matching IF user+t...@example.com@example.com On the plus side, I figured out how to do something interesting by reading through the regexp documentation-- this solved another challenge I'd been facing. '+' has a special meaning in regular expressions (one or more times the preceding term), so you need to escape it to match a literal '+': if /\+.*@example\.com$/ /^(.*)\+/ $1...@example.com endif Regards Ansgar Wiechers that's what I get for posting an untested example and then walking away for a little while. Escaping the + fixes the expression to what I intended. Thanks everyone for cleaning up after me. Thanks-- that sorted it, and now I'm able to say I learned two new things about regular expressions today. Only several thousand left to go. - -- Corey / KB1JWQ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBAgAGBQJNlCIHAAoJEPmSS8816iBeorUH/A+6vAdxQzUYZRTrjEx1eEdY 22QDpB23TXqAPux6dXtSiRqFewIlLTe3IjmI6+DB6ye7767JjdcGQCHOq+/zJbiA SEBpfueI+sYCQtQ3gO17diN+2YIp/Z1v+6P6TrjILifvh4Fhxq9GrMiv3lxnlrgQ z+RcD41RshqempvSxDHIs1BzB+TRsKWoEo/SucYzfABtERxRwcclfGvPXv/4Rna5 bUqG3iJFqwcHOadMkTH96rSXeNeTTBKnKHz4J6v3pPHu5HL8UIuX4xK+qTmKIfNY 6v+BMuvWOI9XldZ+2Obo+NPbKdMtiVwh/DgHlqGnu0os3cvGOuyuFlFGriCNjEE= =0I35 -END PGP SIGNATURE-
Re: virtual_alias_maps and recipient_delimiter
On 03/31/2011 08:41 AM, Corey Quinn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2011, at 2:08 PM, Noel Jones wrote: On 3/30/2011 3:53 PM, Ansgar Wiechers wrote: On 2011-03-30 Corey Quinn wrote: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ /^(.*)+/ $1...@example.com ENDIF Threw this verbatim into my generic.regexp: [root@mx1 postfix]# postmap -q user+t...@example.com regexp:generic.regexp postmap: warning: regexp map generic.regexp, line 1: Invalid preceding regular expression postmap: warning: regexp map generic.regexp, line 4: ignoring ENDIF without matching IF user+t...@example.com@example.com On the plus side, I figured out how to do something interesting by reading through the regexp documentation-- this solved another challenge I'd been facing. '+' has a special meaning in regular expressions (one or more times the preceding term), so you need to escape it to match a literal '+': if /\+.*@example\.com$/ /^(.*)\+/ $1...@example.com endif Regards Ansgar Wiechers that's what I get for posting an untested example and then walking away for a little while. Escaping the + fixes the expression to what I intended. Thanks everyone for cleaning up after me. Thanks-- that sorted it, and now I'm able to say I learned two new things about regular expressions today. Only several thousand left to go. I don't know if this is limited to PCRE or usable in regexp too, but the above would match joefoo, and return joe+++ due to the greedy (.*). To avoid such edge-cases: /^([^+]+)\+[^+@]+@example.com/$1...@example.com That is, one or more of not a plus sign, followed by a plus sign, followed by one or more of not a plus nor an @. This would capture the first alpha-numeric sequence not including a plus, and completely ignore non-delimited addresses (since they don't contain a plus sign) and odd addresses that contain pluses but aren't delimited by one. -- J.
Re: virtual_alias_maps and recipient_delimiter
On Wed, Mar 30, 2011 at 11:35:03AM -0500, Clayton Keller wrote:
I would like to allow the use of the recipient_delimiter, but rewrite the
address to ensure that it is delivered to the original address.
i.e. clay+t...@domain.tld - c...@domain.tld
I would like this to be available to all addresses we accept mail for. To
do so I have been testing a regexp using virtual_alias_maps.
I would like to be able to rewrite the address as described, but properly
handle the recipient verification similar to that when the
virtual_alias_maps is not enabled. With this not enabled address which do
contain the recipient_delimiter are then properly known or unknown.
Is there a better way to handle the rewrite in my case rather than using
virtual_alias_maps?
Use virtual alias maps, but NOT regular expressions, rather:
main.cf:
indexed = ${default_database_type}:${config_directory}/
virtual_alias_maps = ${indexed}virtual
propagate_unmatched_extensions = canonical
virtual:
# Identity virtual alias mappings for all users that
# don't already have other alias entries.
#
c...@example.comc...@example.com
...
--
Viktor.
Re: virtual_alias_maps and recipient_delimiter
On 03/30/2011 11:43 AM, Victor Duchovni wrote:
On Wed, Mar 30, 2011 at 11:35:03AM -0500, Clayton Keller wrote:
I would like to allow the use of the recipient_delimiter, but rewrite the
address to ensure that it is delivered to the original address.
i.e. clay+t...@domain.tld - c...@domain.tld
I would like this to be available to all addresses we accept mail for. To
do so I have been testing a regexp using virtual_alias_maps.
I would like to be able to rewrite the address as described, but properly
handle the recipient verification similar to that when the
virtual_alias_maps is not enabled. With this not enabled address which do
contain the recipient_delimiter are then properly known or unknown.
Is there a better way to handle the rewrite in my case rather than using
virtual_alias_maps?
Use virtual alias maps, but NOT regular expressions, rather:
main.cf:
indexed = ${default_database_type}:${config_directory}/
virtual_alias_maps = ${indexed}virtual
propagate_unmatched_extensions = canonical
virtual:
# Identity virtual alias mappings for all users that
# don't already have other alias entries.
#
c...@example.comc...@example.com
...
I thought about that as well. However, the list could grow to over 20k+
addresses.
Should I use the virtual_alias_maps rather than my use of:
relay_recipient_maps = hash:/etc/postfix/relay_recipients
to handle the valid recipient checks? This would keep me from populating
two hash'd indexed files with basically the same data.
That combined with your propagate_unmatched_extensions I think will do
what I'm needing to do.
Re: virtual_alias_maps and recipient_delimiter
On Wed, Mar 30, 2011 at 11:54:32AM -0500, Clayton Keller wrote:
# Identity virtual alias mappings for all users that
# don't already have other alias entries.
#
c...@example.comc...@example.com
...
I thought about that as well. However, the list could grow to over 20k+
addresses.
I have a multiple of that many users in LDAP.
Should I use the virtual_alias_maps rather than my use of:
relay_recipient_maps = hash:/etc/postfix/relay_recipients
If all users are listed in virtual_alias_maps, your relay_recipient_table
can be empty, but you must still designate a table, since otherwise
validation is disabled.
main.cf:
relay_recipient_maps = ${indexed}empty
empty:
# Nobody here by that name
Postfix recipient validation always checks for a virtual alias (these
apply to all address classes) before checking any class-specific lookup
tables. If all users are listed in virtual(5) the remaining tables can
be empty, but are required to be defined, so that validation is not
disabled.
--
Viktor.
Re: virtual_alias_maps and recipient_delimiter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2011, at 9:35 AM, Clayton Keller wrote: I would like to allow the use of the recipient_delimiter, but rewrite the address to ensure that it is delivered to the original address. i.e. clay+t...@domain.tld - c...@domain.tld I'm attempting something similar today, although the specifics vary slightly. I've got a relayhost in the datacenter that I'd like to have rewrite user+...@example.com to u...@example.com before passing the message outwards to (ours, but externally hosted) example.com's MX server. So far setting propagate_unmatched_extensions = recipient_delimiter = + hasn't done what I wanted. Am I on the right path? - -- Corey / KB1JWQ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBAgAGBQJNk4C+AAoJEPmSS8816iBeH90H/3fjjbGFjqFaYDHcn55PtKNm Dt2dNeF7Q3+KqzXJ4dVDpxkfueIZ01C716hXLg16+QrXbLgYiztAB1Yz1uajhwt5 kiE82HS0OFYU8cFNCSvpHEs6O6t0EBm2wFnzP/yNO5ZPfWIGyVcjFothWDdcjgzz X4ogOgsJwMKNiqJIr3jPSHDCuzBGp/q+Sf9hu9IL0aCRTRmwvoLvY4We0ODXoesf 4bDoaBfj2iSL2FD0GDGBncmp2NKpGmpNg4w66LeVoMLaXb2XDUuVhUIyQhUr8i4V g8OscCqvuw4AH+Gl6R++Sg5bT9QMDij7U4AiNFfawhR+wmmt5qrmDAAWLfc7+/k= =evGU -END PGP SIGNATURE-
Re: virtual_alias_maps and recipient_delimiter
On 3/30/2011 2:13 PM, Corey Quinn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2011, at 9:35 AM, Clayton Keller wrote: I would like to allow the use of the recipient_delimiter, but rewrite the address to ensure that it is delivered to the original address. i.e. clay+t...@domain.tld - c...@domain.tld I'm attempting something similar today, although the specifics vary slightly. I've got a relayhost in the datacenter that I'd like to have rewrite user+...@example.com to u...@example.com before passing the message outwards to (ours, but externally hosted) example.com's MX server. So far setting propagate_unmatched_extensions = recipient_delimiter = + hasn't done what I wanted. Am I on the right path? That's a very different problem, ie. strip recipient delimiters from mail relayed externally. Sounds as if smtp_generic_maps will fill the need. http://www.postfix.org/ADDRESS_REWRITING_README.html#generic # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ /^(.*)+/ $1...@example.com ENDIF -- Noel Jones
Re: virtual_alias_maps and recipient_delimiter
Corey Quinn: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ Remove the initial + character. Wietse
Re: virtual_alias_maps and recipient_delimiter
On Wed, Mar 30, 2011 at 02:46:39PM -0500, Noel Jones wrote: That's a very different problem, ie. strip recipient delimiters from mail relayed externally. Sounds as if smtp_generic_maps will fill the need. http://www.postfix.org/ADDRESS_REWRITING_README.html#generic # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp It is possible to avoid a regexp, generic mapping is also subject to propagate_unmatched_extensions (which excludes generic by default). Therefore, one can use: generic: u...@example.comu...@example.com and this too will drop the extension in a perhaps more robust way, but the table needs a lookup key for each user. -- Viktor.
Re: virtual_alias_maps and recipient_delimiter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 30, 2011, at 1:29 PM, Wietse Venema wrote: Corey Quinn: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ Remove the initial + character. Definitely closer-- the error stopped, at least: [root@mx1 postfix]# postmap -q user+t...@example.com regexp:generic.regexp user+t...@example.com@example.com - -- Corey / KB1JWQ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBAgAGBQJNk5VSAAoJEPmSS8816iBeKeMIALTA1amszVY5LQFpLR9wqr0t ZLXDi94HxOocOp2M53ER0u2lmtixG/yHCnQnR8opQx5X/Da8w8kvODa5vlhzudaE OeUIH/pF5q5yvKS6XFkbM3pGsKP2RxN1YZWGkpx4EqWj6ZTBOjQicRnvONU9gBDJ 2dNRRrsYrM2HUdrWO+74Wj2s2CeQzyg9+StkF76paN987YaH84q//RhNInED4D/G VmcXc4eMorSyHt9SxeRuCjslQaqL8hsMdTBs9Dy91+G+8SSFbv4KnN2i9eTPu7ny 3M0WqW/DRHvA1R3XP2dS2dgDtGKneHyob1RYzRjNhg5ivrr5eqpQZRnA3jhR4w4= =6dzz -END PGP SIGNATURE-
Re: virtual_alias_maps and recipient_delimiter
On 2011-03-30 Corey Quinn wrote: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ /^(.*)+/ $1...@example.com ENDIF Threw this verbatim into my generic.regexp: [root@mx1 postfix]# postmap -q user+t...@example.com regexp:generic.regexp postmap: warning: regexp map generic.regexp, line 1: Invalid preceding regular expression postmap: warning: regexp map generic.regexp, line 4: ignoring ENDIF without matching IF user+t...@example.com@example.com On the plus side, I figured out how to do something interesting by reading through the regexp documentation-- this solved another challenge I'd been facing. '+' has a special meaning in regular expressions (one or more times the preceding term), so you need to escape it to match a literal '+': if /\+.*@example\.com$/ /^(.*)\+/ $1...@example.com endif Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: virtual_alias_maps and recipient_delimiter
On 3/30/2011 3:53 PM, Ansgar Wiechers wrote: On 2011-03-30 Corey Quinn wrote: On Mar 30, 2011, at 12:46 PM, Noel Jones wrote: # main.cf smtp_generic_maps = regexp:/etc/postfix/generic.regexp # generic.regexp IF /+.*@example\.com$/ /^(.*)+/ $1...@example.com ENDIF Threw this verbatim into my generic.regexp: [root@mx1 postfix]# postmap -q user+t...@example.com regexp:generic.regexp postmap: warning: regexp map generic.regexp, line 1: Invalid preceding regular expression postmap: warning: regexp map generic.regexp, line 4: ignoring ENDIF without matching IF user+t...@example.com@example.com On the plus side, I figured out how to do something interesting by reading through the regexp documentation-- this solved another challenge I'd been facing. '+' has a special meaning in regular expressions (one or more times the preceding term), so you need to escape it to match a literal '+': if /\+.*@example\.com$/ /^(.*)\+/ $1...@example.com endif Regards Ansgar Wiechers that's what I get for posting an untested example and then walking away for a little while. Escaping the + fixes the expression to what I intended. Thanks everyone for cleaning up after me. -- Noel Jones
Re: virtual_alias_maps and X-Original-To
On 2011-02-17 1:16 PM, Victor Duchovni wrote: On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: Postfix will not add X-Original-To when forwarding mail. Yes, really when not using a delivery agent that is typically used for outbound or relay email. In the case of lmtp(8) this should perhaps be revisited at some point. Just to make sure I understand this correctly... Currently, using virtual for deliver, I'm getting these X-Original-To headers, which I have gotten very used to and rely on - but if/when we switch to dovecot+LMTP, we will lose them? If so, that is a show-stopper for me... also, what are the chances of this being 'revisited' at any point in the foreseeable future? Last - am I correct that we will *not* lose them if we just use the dovecot LDA as opposed to LMTP? Thanks, -- Best regards, Charles
Re: virtual_alias_maps and X-Original-To
Charles Marcus: On 2011-02-17 1:16 PM, Victor Duchovni wrote: On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: Postfix will not add X-Original-To when forwarding mail. Yes, really when not using a delivery agent that is typically used for outbound or relay email. In the case of lmtp(8) this should perhaps be revisited at some point. Just to make sure I understand this correctly... Currently, using virtual for deliver, I'm getting these X-Original-To headers, which I have gotten very used to and rely on - but if/when we switch to dovecot+LMTP, we will lose them? You can fake it in the SMTP server with /etc/postfix/main.cf: smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/recipient_access.pcre /etc/postfix/recipient_access.pcre /(.+)/ prepend X-Original-To: $1 At a minor loss of privacy (plus that it would prepend multiple headers in the case of multi-recipient mail). If so, that is a show-stopper for me... also, what are the chances of this being 'revisited' at any point in the foreseeable future? Last - am I correct that we will *not* lose them if we just use the dovecot LDA as opposed to LMTP? The chances depend on available time. Implementing one thing means delaying another. Wietse
Re: virtual_alias_maps and X-Original-To
On 2011-03-01 3:35 PM, Wietse Venema wrote: Charles Marcus: Currently, using virtual for deliver, I'm getting these X-Original-To headers, which I have gotten very used to and rely on - but if/when we switch to dovecot+LMTP, we will lose them? You can fake it in the SMTP server with snip At a minor loss of privacy (plus that it would prepend multiple headers in the case of multi-recipient mail). Thanks very much for the workaround... I'll experiment and see if the privacy implications are anything we should worry about (most people don't even know what headers are, much less how to look at them, so probably not a big deal)... If so, that is a show-stopper for me... also, what are the chances of this being 'revisited' at any point in the foreseeable future? The chances depend on available time. Implementing one thing means delaying another. Understood... hopefully it is at least on a To-Do somewhere so it won't get lost in the shuffle. Thanks again Wietse! -- Best regards, Charles
RE: virtual_alias_maps and X-Original-To
Wietse Venema: If it is only for one special case, /etc/postfix/main.cf smtpd_recipient_restrictions = permit_mynetworks ... reject_unauth_destination ... check_recipient_access hash:/etc/postfix/recipient_access /etc/postfix/recipient_access: u...@example.com PREPEND: X-Original-To: usern...@example.com Wietse Just wanted to say thank you for the info. It turned out I needed PREPEND not PREPEND: (so, without the colon) - perhaps a different version or something, but it works! Thanks,adam
RE: virtual_alias_maps and X-Original-To
Aliasing via virtual(5) is brutally efficient. No content modification, just message routing, so the header is not added. To add an X-Original-Recipient header, messages to multiple recipients have to be split into one copy per-recipient since the header you want is recipient-specific. Since the queue file contains a single copy of the message for all recipients, such rewriting *cannot* happen on input, it can only happen on output via a delivery agent that is processing a single recipient. This means you need a custom transport for this destination that processes mail one recipient at a time and prepends the header. This can be done via an external program via pipe(8) or by modifying the source code of the smtp(8) delivery agent so that the header is added when a suitable boolean flag is set and the message has exactly one recipient. The pipe(8) approach would then re-submit the mail for outbound delivery to a different Postfix instance to avoid loops. -- Viktor. Thanks again Viktor. It sounds a bit more in depth than I was hoping for. Given the _only_ function for this alias is to forward to one address, would it be possible to do a simpler approach? Regards, adam
Re: virtual_alias_maps and X-Original-To
On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: I have an entry in the virtual_alias_maps for a few users to be redirected to zendesk.com. zendesk requires a X-Original-To header set for some stuff to work, but it isn't added in my postfix setup. I have a basic postfix setup with dovecot for virtual delivery, but from the logs it appears dovecot is not instantiated when using virtual_alias_maps since the alias means its forwarded - because its an smtp task??? No, the aliasing is not the crux of the issue when the resulting recipient is still delivered locally, but see below. It seems to make sense from this thread that: http://www.dovecot.org/list/dovecot/2011-January/056783.html postfix adds X-Original-To when delivering to a mailbox - which delivery via smtp/lmtp isn't., This is right, only the local(8), virtual(8) and pipe(8) (flag-dependent) prepend X-Original-To. The smtp(8) and lmtp(8) delivery agents do not prepend X-Original-To headers. and this one: http://tech.groups.yahoo.com/group/postfix-users/message/231881 Postfix will not add X-Original-To when forwarding mail. Yes, really when not using a delivery agent that is typically used for outbound or relay email. In the case of lmtp(8) this should perhaps be revisited at some point. It seems filters were suggested to be used, but it doesn't seem a common approach. I'd appreciate some guidance on this - I am a newbie trying hard not to get too lost... Are you in fact forwarding email off-site or are you using lmtp(8) to deliver email into a Dovecot IMAP store? -- Viktor.
RE: virtual_alias_maps and X-Original-To
On Thu, Feb 17, 2011 at 05:03:04PM +, Adam Hamer wrote: I have an entry in the virtual_alias_maps for a few users to be redirected to zendesk.com. zendesk requires a X-Original-To header set for some stuff to work, but it isn't added in my postfix setup. I have a basic postfix setup with dovecot for virtual delivery, but from the logs it appears dovecot is not instantiated when using virtual_alias_maps since the alias means its forwarded - because its an smtp task??? No, the aliasing is not the crux of the issue when the resulting recipient is still delivered locally, but see below. The resulting recipient is not delivered locally - it goes to zendesk.com an email 'helpdesk' system. Essentially I have a domain Y.com which points to postfix. Postfix is configure to handle it as a virtual domain with dovecot, but some aliases are set to forward say a...@y.com to zendesk.com. I'm guessing those that get forwarded have nothing to do with local/mailbox delivery agent - and hence its smtp which handles it. It seems to make sense from this thread that: http://www.dovecot.org/list/dovecot/2011-January/056783.html postfix adds X-Original-To when delivering to a mailbox - which delivery via smtp/lmtp isn't., This is right, only the local(8), virtual(8) and pipe(8) (flag-dependent) prepend X-Original-To. The smtp(8) and lmtp(8) delivery agents do not prepend X-Original-To headers. and this one: http://tech.groups.yahoo.com/group/postfix-users/message/231881 Postfix will not add X-Original-To when forwarding mail. Yes, really when not using a delivery agent that is typically used for outbound or relay email. In the case of lmtp(8) this should perhaps be revisited at some point. So my alias is outbound mail - I don't use lmtp (sorry - should have clarified that). It seems filters were suggested to be used, but it doesn't seem a common approach. I'd appreciate some guidance on this - I am a newbie trying hard not to get too lost... Are you in fact forwarding email off-site or are you using lmtp(8) to deliver email into a Dovecot IMAP store? Off-site. Any ideas for which way to go to make those aliases have the X-Original-To? -- Viktor. Thanks,adam
Re: virtual_alias_maps and X-Original-To
On Thu, Feb 17, 2011 at 09:43:05PM +, Adam Hamer wrote: Are you in fact forwarding email off-site or are you using lmtp(8) to deliver email into a Dovecot IMAP store? Off-site. Any ideas for which way to go to make those aliases have the X-Original-To? Aliasing via virtual(5) is brutally efficient. No content modification, just message routing, so the header is not added. To add an X-Original-Recipient header, messages to multiple recipients have to be split into one copy per-recipient since the header you want is recipient-specific. Since the queue file contains a single copy of the message for all recipients, such rewriting *cannot* happen on input, it can only happen on output via a delivery agent that is processing a single recipient. This means you need a custom transport for this destination that processes mail one recipient at a time and prepends the header. This can be done via an external program via pipe(8) or by modifying the source code of the smtp(8) delivery agent so that the header is added when a suitable boolean flag is set and the message has exactly one recipient. The pipe(8) approach would then re-submit the mail for outbound delivery to a different Postfix instance to avoid loops. -- Viktor.
Re: virtual_alias_maps and verify
On Mon, Jan 24, 2011 at 03:52:18PM +0100, Heinz A. Krebs wrote:
dear all,
i'm going to setup a backup-MX, and although i've now a working
solution, I'd like to ask, if this is the correct solution ...
PART 1 (working):
Backup for domain.com with a list of valid recipients in a database. my
main.cf looks like:
---
relay_domains = domain.com
relay_recipient_maps = mysql:/etc/postfix/mysql_relay.cf
# contains query = SELECT 'OK' FROM recipients WHERE email='%s'
smtpd_recipient_restrictions =
...,
check_recipient_access mysql:/etc/postfix/mysql_relay.cf,
The access check is generally not needed, by listing the
domain in relay_domains you ensure that it is not rejected by
reject_unauth_destination.
b) if postfix receives mail for t...@domain.com, then postfix answers
User unknown in relay recipient table.
but since my database-list is updated only once per week, i'd like check
the primary MX in situation b), if in the meantime user TWO has been
added.
It is best to avoid this mess by synchronizing more frequently, and
pre-provisioning email addresses sufficiently early in the user account
creation process that by the time people are sending the user email,
the data is already on the backup MX.
If that's impractical, DON'T check with the primary, the only time you
need a backup MX is when the primary is down, and that's exactly when
this won't work. So just assume the primary is down, and act accordingly.
This means that you should defer all unknown users. Since the primary
will reject them, this only happens when the primary is down, and in this
case you accept and queue just the most recently updated list of recipients.
---
relay_domains = domain.com
relay_recipient_maps = mysql:/etc/postfix/mysql_relay.cf
# contains query = SELECT 'OK' FROM recipients WHERE email='%s'
smtpd_recipient_restrictions =
...,
check_recipient_access mysql:/etc/postfix/mysql_relay.cf,
check_recipient_access hash:/etc/postfix/domains
# contains: domain.com reject_unverified_recipient
Change reject_unverified_recipient to defer.
PART 3 (problem):
domain.at is an alias for domain.com. so i added the following:
---
virtual_alias_maps = pcre:/etc/postfix/virtual.pcre
# contains /^([a-z\.]+)@domain.at$/ $1...@domain.com
---
Bad idea. Breaks recipient validation. If this is also to be a relay
domain for which you are a backup you need a table of valid recipients
for this domain. If it is an alias, you need data that contains
the same localpart addresses with the new domain suffix.
---
domain.at reject_unverified_recipient
---
if postfix receives mail for o...@domain.at, then the address is
rewritten to o...@domain.com, but then the primary MX is immediately
queried! why is postfix not checking the mysql-database after
rewriting??
Because it checks before.
MY CURRENT SOLUTION (working):
extend smtpd_recipient_restrictions in main.cf:
---
# contains query = SELECT 'OK' FROM recipients WHERE email='%s'
smtpd_recipient_restrictions =
...,
check_recipient_access mysql:/etc/postfix/mysql_relay.cf,
check_recipient_access mysql:/etc/postfix/mysql_relay_at.cf,
# contains query = SELECT 'OK' FROM recipients WHERE email=REPLACE('%
s','.at','.com')
NO, don't alias all .at domains to .com, replace just the domain
in question and only at the *end* of the address string.
this is working, so if postfix receives mail for o...@domain.at it
answers with OK, since the second table lookup returns a record, and if
postfix receives t...@domain.at, the mails queryies the primary MX if
t...@domain.com exists ...
but is this the correct solution? is there a more easy way to solve
this?
Better to treat the identical address lists for the two domains as
an coincidence that is subject to change and populate data for
both domains.
--
Viktor.
Re: virtual_alias_maps -- Re: Simple question?: Aliases and transport
On 12/2/2010 10:08 AM, Robert Moskowitz wrote: On 12/02/2010 09:40 AM, Brian Evans - Postfix List wrote: In order for this to work, you should add non-local user aliases to virtual_alias_maps using the fully qualified addresses on both the left and right sides. virtual_alias_maps are global and you *should not* add anything to virtual_alias_domains. Can virtual_alias_maps contain commands like aliases can? In particular the commands used for Mailman? For my system I am using an SQL table for my this: postconf -e ' virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf' No, you cannot run commands from virtual_alias_maps. The answers you seek are documented in Mailman http://www.list.org/mailman-install/postfix-virtual.html
Re: virtual_alias_maps -- Re: Simple question?: Aliases and transport
On 12/02/2010 10:29 AM, Brian Evans - Postfix List wrote: On 12/2/2010 10:08 AM, Robert Moskowitz wrote: On 12/02/2010 09:40 AM, Brian Evans - Postfix List wrote: In order for this to work, you should add non-local user aliases to virtual_alias_maps using the fully qualified addresses on both the left and right sides. virtual_alias_maps are global and you *should not* add anything to virtual_alias_domains. Can virtual_alias_maps contain commands like aliases can? In particular the commands used for Mailman? For my system I am using an SQL table for my this: postconf -e ' virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf' No, you cannot run commands from virtual_alias_maps. The answers you seek are documented in Mailman http://www.list.org/mailman-install/postfix-virtual.html I THINK I have things working now. More reading and rereading (for the 6th time at least) the mailman docs and things SEEM to be working. Now to do a rebuild and step through with no mis-steps. I hope.
Re: virtual_alias_maps
On 5/12/2010 7:36 AM, M.S. Lucas wrote: Hello, Newbie allert. I want to do the following us...@domain.nl mailto:us...@domain.nl us...@domain.nl mailto:us...@domain.nl, us...@domain.nl So every email to user1 is delivered to user1 and to user2. I try this in the virtual_alias_maps but is this the best place Yes, this is correct way. and don’t I get a loop this way? No, you'll have to get more creative to get a loop. -- Noel Jones With kind regards, met vriendelijke groet, Maurice Lucas *TAOS-IT* // Paulus Buijsstraat 191 2613 HR Delft www.taos-it.nl http://www.taos-it.nl/ KvK Haaglanden nr. 27254410 */P/* Denk aan het milieu; is het afdrukken van deze e-mail echt noodzakelijk?
Re: virtual_alias_maps mysql
On Jan 28, 2010, at 12:35 PM, Serge Fonville wrote: Hi, I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? I have but was hoping for something simpler like I do with dovecot deliver where you create a script that calls deliver after you do what you want for logging and then name your script in something like deliver_exec = script. Might be wrong with the names but thats more or less what takes place. I'd prefer to keep as much of this type of thing in the config files. It seems to be easier to quickly see what's up when there is a problem. I'll try the stored procedure if nothing more attractive turns up. Thank you, Bradley Giesbrecht
Re: virtual_alias_maps mysql
On Fri, Jan 29, 2010 at 9:19 AM, Bradley Giesbrecht bradley.giesbre...@gmail.com wrote: On Jan 28, 2010, at 12:35 PM, Serge Fonville wrote: Hi, I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? I have but was hoping for something simpler like I do with dovecot deliver where you create a script that calls deliver after you do what you want for logging and then name your script in something like deliver_exec = script. Might be wrong with the names but thats more or less what takes place. I'd prefer to keep as much of this type of thing in the config files. It seems to be easier to quickly see what's up when there is a problem. I'll try the stored procedure if nothing more attractive turns up. Well, possibly you could edit your transport to use a script and pass all the relevant variables to it, it can then also do an insert on your database. -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: virtual_alias_maps mysql
On Jan 29, 2010, at 12:29 AM, Serge Fonville wrote:
On Fri, Jan 29, 2010 at 9:19 AM, Bradley Giesbrecht
bradley.giesbre...@gmail.com wrote:
On Jan 28, 2010, at 12:35 PM, Serge Fonville wrote:
Hi,
I using virtual_alias_maps with mysql for storage. Working fine.
Does anyone have a suggestion on how to update a timestamp field
in the
mysql table when postfix finds a virtual_alias_maps match?
I'm looking for a way to measure alias usage and cull unused
aliases.
Have you considered a stored procedure?
I have but was hoping for something simpler like I do with dovecot
deliver
where you create a script that calls deliver after you do what you
want for
logging and then name your script in something like deliver_exec =
script.
Might be wrong with the names but thats more or less what takes
place.
I'd prefer to keep as much of this type of thing in the config
files. It
seems to be easier to quickly see what's up when there is a problem.
I'll try the stored procedure if nothing more attractive turns up.
Well, possibly you could edit your transport to use a script and pass
all the relevant variables to it, it can then also do an insert on
your database.
I was kinda hoping something like this was possible.
Does anyone have an example of something like this?
Maybe add a filter to my relay in master.cf?
http://www.postfix.org/FILTER_README.html
filterunix - n n - 10 pipe
flags=Rq user=filter null_sender=
argv=/path/to/script -f ${sender} -- ${recipient}
relay unix - - n - 10 smtp
-o content_filter=filter:dummy
OR
smtp unix - - n - 10 smtp
-o content_filter=filter:dummy
As everyone probably notices other then setting up postfix with
dovecot and virtual users in mysql I don't know postfix that well.
It's been working real well for over a year.
Thanks for any help. This isn't crucial, I'd just like to be able to
view counts of message passing through aliased users.
// Brad
RE: virtual_alias_maps mysql
I have but was hoping for something simpler like I do with dovecot deliver where you create a script that calls deliver after you do what you want for logging and then name your script in something like deliver_exec = script. Might be wrong with the names but thats more or less what takes place. I'd prefer to keep as much of this type of thing in the config files. It seems to be easier to quickly see what's up when there is a problem. I'll try the stored procedure if nothing more attractive turns up. Well, possibly you could edit your transport to use a script and pass all the relevant variables to it, it can then also do an insert on your database. Or write a simple policy daemon. All necessary information is sent to a policy deamon which in turn can put data in a table. (I wrote something in PHP using pcntl because I don't know how write it in C or Perl. It writes data to a MYSQL table taken from the details sent by Postfix. Our mailflow is not as big as some here, but so far it's proven to be quite stable and it fulfills our needs.) -- Rob
Re: virtual_alias_maps mysql
On 1/29/2010 2:41 AM, Serge Fonville wrote: On Thu, Jan 28, 2010 at 10:40 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: On 1/28/2010 4:12 PM, Serge Fonville wrote: I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? If you use a SELECT query, does it use CALL? This would be a stored function, not a procedure, to be called from a SELECT. A stored function *must* return a single result and cannot output a result set. This does not seem it would work for the OP because the query would always match from the Postfix point of view. Stored procedures in MySQL must be invoked by CALL.
Re: virtual_alias_maps mysql
On Fri, Jan 29, 2010 at 2:51 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: On 1/29/2010 2:41 AM, Serge Fonville wrote: On Thu, Jan 28, 2010 at 10:40 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: On 1/28/2010 4:12 PM, Serge Fonville wrote: I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? If you use a SELECT query, does it use CALL? This would be a stored function, not a procedure, to be called from a SELECT. A stored function *must* return a single result and cannot output a result set. This does not seem it would work for the OP because the query would always match from the Postfix point of view. Stored procedures in MySQL must be invoked by CALL. Hmmm... Makes sense. A stored function then would solve it? Regards, Serge Fonville -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: virtual_alias_maps mysql
Hi, I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? HTH Regards, Serge Fonville -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: virtual_alias_maps mysql
On 1/28/2010 3:35 PM, Serge Fonville wrote: Hi, I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? Stored procedures do not work in Postfix without code changes because the |CLIENT_MULTI_RESULTS connect flag, for MySQL API, is not turned on. |
Re: virtual_alias_maps mysql
I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? Stored procedures do not work in Postfix without code changes because the |CLIENT_MULTI_RESULTS connect flag, for MySQL API, is not turned on. From the manual: http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html CLIENT_MULTI_RESULTS Tell the server that the client can handle multiple result sets from multiple-statement executions or stored procedures. This flag is automatically enabled if CLIENT_MULTI_STATEMENTS is enabled. See the note following this table for more information about this flag. If your program uses CALL statements to execute stored procedures, the CLIENT_MULTI_RESULTS flag must be enabled. Not sure if I understand this right then, but to me this reads that if you use SELECT to get results from a stored procedure your fine Correct me if I'm wrong HTH Regards, Serge Fonville -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: virtual_alias_maps mysql
On 1/28/2010 4:12 PM, Serge Fonville wrote: I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? Stored procedures do not work in Postfix without code changes because the |CLIENT_MULTI_RESULTS connect flag, for MySQL API, is not turned on. From the manual: http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html CLIENT_MULTI_RESULTS [...] If your program uses CALL statements to execute stored procedures, the CLIENT_MULTI_RESULTS flag must be enabled. Reread this ^^^.
Re: virtual_alias_maps mysql
On Thu, Jan 28, 2010 at 10:40 PM, Brian Evans - Postfix List grkni...@scent-team.com wrote: On 1/28/2010 4:12 PM, Serge Fonville wrote: I using virtual_alias_maps with mysql for storage. Working fine. Does anyone have a suggestion on how to update a timestamp field in the mysql table when postfix finds a virtual_alias_maps match? I'm looking for a way to measure alias usage and cull unused aliases. Have you considered a stored procedure? Stored procedures do not work in Postfix without code changes because the |CLIENT_MULTI_RESULTS connect flag, for MySQL API, is not turned on. From the manual: http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html CLIENT_MULTI_RESULTS [...] If your program uses CALL statements to execute stored procedures, the CLIENT_MULTI_RESULTS flag must be enabled. Reread this ^^^. If you use a SELECT query, does it use CALL? -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: virtual_alias_maps and pipe to command
On Monday 03 August 2009 15:27:40 David Zejda wrote: I have many mappings in virtual_alias_maps to other mail addresses, but I am not succesfull in aliasing to a command using the | in the form: virtal...@zejda.net |/usr/bin/procmail /home/veronika/.procmailrc That's because it was never implemented. Absence from the Postfix documentation can be inferred to mean that the feature does not exist. If I try to add the entry to the alias_maps, I get: You need to understand that alias_maps is ONLY used by the local(8) delivery agent. Aug 3 22:18:14 o-it postfix/smtp[14594]: 1D1DC7FC2: to=al...@zejda.net, relay=127.0.0.1[127.0.0.1]:27, delay=0.94, delays=0.04/0.01/0.04/0.85, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2B29180A3) Aug 3 22:18:14 o-it postfix/qmgr[14586]: 1D1DC7FC2: removed Aug 3 22:18:14 o-it postfix/virtual[14598]: 2B29180A3: to=al...@zejda.net, relay=virtual, delay=0.86, delays=0.85/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user: al...@zejda.net) The address you gave it is using the virtual(8) delivery agent. Please, how can I let postfix to deliver to external command? ^ Incomplete question. Insert virtual mailbox addresses above. And BTW, this is indeed a FAQ here, where did you look? mydestination = [ ... what you needed before ... ], localhost, localhost.$mydomain virtual_alias_maps containing: addr...@virtual_mailbox al...@localhost virtual_mailbox_maps containing: addr...@virtual_mailbox anything here alias_maps containing: alias: |/path/to/your/command and arguments See aliases(5) for the details of running commands from an alias. Offer void where taxed or prohibited by law, or if you failed to build any necessary files with postmap(1)/newaliases(1). postconf -n alias_maps = btree:/etc/postfix/aliases allow_mail_to_commands = alias,forward,include append_dot_mydomain = no This setting removes the need for localhost.$mydomain as I gave you above. bounce_size_limit = 64000 command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp:[127.0.0.1]:27 daemon_directory = /usr/lib/postfix default_privs = neznamy Know what this one means. See postconf.5.html#default_privs . local_recipient_maps = Why? local_transport = virtual No, take this out. mail_owner = postfix mydestination = $myhostname, $mydomain, btree:/etc/postfix/virtdomains virtdomains included in mydestination? You seem to be very confused here. Did you try to follow some HOWTO or tutorial which you did not understand? *If* you really need virtual mailboxes (small sites and beginners generally do not!) you should follow the real documentation: http://www.postfix.org/VIRTUAL_README.html and understand the choices you have: http://www.postfix.org/ADDRESS_CLASS_README.html My guess is that you would have been better off forgetting about virtual mailboxes and just using the BASIC_CONFIGURATION_README. Virtual alias domains can easily provide namespace separation for multiple domains, still using local(8) delivery. myhostname = smtp.o-it.info mynetworks = 127.0.0.0/8, 82.113.54.166/32, 81.92.145.161/32, 192.168.30.136/32 myorigin = $mydomain relay_domains = $mynetworks Wrong. Most sites should just unset this. Anyway, $mynetworks is a network list, not a domain list. smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_delay_reject = yes smtpd_recipient_restrictions = permit_mynetworkscheck_policy_service inet:127.0.0.1:6check_recipient_access btree:/etc/postfix/virtaccessreject This looks very odd too. Is virtaccess what you used in place of doing virtual_mailbox_domains/maps the documented way? transport_maps = btree:/etc/postfix/transport Why? What's in here? virtual_alias_maps = btree:/etc/postfix/virtalias virtual_gid_maps = static:8 Such a low GID/UID is an unusual choice. Not necessarily wrong per se, but you should know why you chose it. virtual_mailbox_base = /var/mail virtual_mailbox_maps = btree:/etc/postfix/virtmbox virtual_minimum_uid = 7 virtual_uid_maps = btree:/etc/postfix/virtuid -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: virtual_alias_maps and pipe to command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you for the extensive reply, you pointed me to look on the config in whole more seriously and really, there were odd remains of experiments from the past, which caused the behavior.. it seems, that everything works OK now. D. /dev/rob0 napsal(a): On Monday 03 August 2009 15:27:40 David Zejda wrote: I have many mappings in virtual_alias_maps to other mail addresses, but I am not succesfull in aliasing to a command using the | in the form: virtal...@zejda.net |/usr/bin/procmail /home/veronika/.procmailrc That's because it was never implemented. Absence from the Postfix documentation can be inferred to mean that the feature does not exist. If I try to add the entry to the alias_maps, I get: You need to understand that alias_maps is ONLY used by the local(8) delivery agent. Aug 3 22:18:14 o-it postfix/smtp[14594]: 1D1DC7FC2: to=al...@zejda.net, relay=127.0.0.1[127.0.0.1]:27, delay=0.94, delays=0.04/0.01/0.04/0.85, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2B29180A3) Aug 3 22:18:14 o-it postfix/qmgr[14586]: 1D1DC7FC2: removed Aug 3 22:18:14 o-it postfix/virtual[14598]: 2B29180A3: to=al...@zejda.net, relay=virtual, delay=0.86, delays=0.85/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user: al...@zejda.net) The address you gave it is using the virtual(8) delivery agent. Please, how can I let postfix to deliver to external command? ^ Incomplete question. Insert virtual mailbox addresses above. And BTW, this is indeed a FAQ here, where did you look? mydestination = [ ... what you needed before ... ], localhost, localhost.$mydomain virtual_alias_maps containing: addr...@virtual_mailbox al...@localhost virtual_mailbox_maps containing: addr...@virtual_mailbox anything here alias_maps containing: alias: |/path/to/your/command and arguments See aliases(5) for the details of running commands from an alias. Offer void where taxed or prohibited by law, or if you failed to build any necessary files with postmap(1)/newaliases(1). postconf -n alias_maps = btree:/etc/postfix/aliases allow_mail_to_commands = alias,forward,include append_dot_mydomain = no This setting removes the need for localhost.$mydomain as I gave you above. bounce_size_limit = 64000 command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp:[127.0.0.1]:27 daemon_directory = /usr/lib/postfix default_privs = neznamy Know what this one means. See postconf.5.html#default_privs . local_recipient_maps = Why? local_transport = virtual No, take this out. mail_owner = postfix mydestination = $myhostname, $mydomain, btree:/etc/postfix/virtdomains virtdomains included in mydestination? You seem to be very confused here. Did you try to follow some HOWTO or tutorial which you did not understand? *If* you really need virtual mailboxes (small sites and beginners generally do not!) you should follow the real documentation: http://www.postfix.org/VIRTUAL_README.html and understand the choices you have: http://www.postfix.org/ADDRESS_CLASS_README.html My guess is that you would have been better off forgetting about virtual mailboxes and just using the BASIC_CONFIGURATION_README. Virtual alias domains can easily provide namespace separation for multiple domains, still using local(8) delivery. myhostname = smtp.o-it.info mynetworks = 127.0.0.0/8, 82.113.54.166/32, 81.92.145.161/32, 192.168.30.136/32 myorigin = $mydomain relay_domains = $mynetworks Wrong. Most sites should just unset this. Anyway, $mynetworks is a network list, not a domain list. smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_delay_reject = yes smtpd_recipient_restrictions = permit_mynetworkscheck_policy_service inet:127.0.0.1:6check_recipient_access btree:/etc/postfix/virtaccessreject This looks very odd too. Is virtaccess what you used in place of doing virtual_mailbox_domains/maps the documented way? transport_maps = btree:/etc/postfix/transport Why? What's in here? virtual_alias_maps = btree:/etc/postfix/virtalias virtual_gid_maps = static:8 Such a low GID/UID is an unusual choice. Not necessarily wrong per se, but you should know why you chose it. virtual_mailbox_base = /var/mail virtual_mailbox_maps = btree:/etc/postfix/virtmbox virtual_minimum_uid = 7 virtual_uid_maps = btree:/etc/postfix/virtuid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp3Z5oACgkQ3oCkkciamVF5PgCfU96TqJlTOf/HGTS0YQIXiomq NX8Anik8BZIOmp/7MV6JNpv1WKwy2gfa =Odrx -END PGP SIGNATURE-
Re: [Re: virtual_alias_maps works with hash but not LDAP (Postfix 2.5.1)]
John/SML a écrit : [snip] cleanup unix n - - - 0 cleanup mouss said: make sure the 5th field is 'n' (and not 'y' nor '-'). then you said: I have disbabled chroot in master.cf Wasn't that a lie? [snip]
Re: [Re: virtual_alias_maps works with hash but not LDAP (Postfix 2.5.1)]
John/SML: Jul 24 14:16:22 imapsv02 postfix/master[17734]: warning: process /usr/lib/postfix/cleanup pid 17969 exit status 2 ... I googled the problem, but find no clue. Any idea? This is the official reference: http://www.postfix.org/DEBUG_README.html#logging And please turn off that verbose logging. All the information you need at this point is already logged, you are only adding noise. Wietse Look for obvious signs of trouble Postfix logs all failed and successful deliveries to a logfile. The file is usually called /var/log/maillog or /var/log/mail; the exact pathname is defined in the /etc/syslog.conf file. When Postfix does not receive or deliver mail, the first order of business is to look for errors that prevent Postfix from working properly: % egrep '(warning|error|fatal|panic):' /some/log/file | more Note: the most important message is near the BEGINNING of the output. Error messages that come later are less useful. The nature of each problem is indicated as follows: * panic indicates a problem in the software itself that only a programmer can fix. Postfix cannot proceed until this is fixed. * fatal is the result of missing files, incorrect permissions, incorrect configuration file settings that you can fix. Postfix cannot proceed until this is fixed. * error reports an error condition. For safety reasons, a Postfix process will terminate when more than 13 of these happen. * warning indicates a non-fatal error. These are problems that you may not be able to fix (such as a broken DNS server elsewhere on the network) but may also indicate local configuration errors that could become a problem later.
Re: [Re: virtual_alias_maps works with hash but not LDAP (Postfix 2.5.1)]
On Monday 27 July 2009 05:38:17 Wietse Venema wrote: John/SML: Jul 24 14:16:22 imapsv02 postfix/master[17734]: warning: process /usr/lib/postfix/cleanup pid 17969 exit status 2 ... I googled the problem, but find no clue. Any idea? This is the official reference: http://www.postfix.org/DEBUG_README.html#logging And please turn off that verbose logging. All the information you need at this point is already logged, you are only adding noise. Perhaps a cleanup -v would give a hint. Obviously smtpd -v is not helping. I often see these sort of symptoms with botched upgrades. John, did something like that happen? It's difficult to read upthread because your silly mail client breaks threading, but all you suggested before was that the problem began when switching from hash: to ldap: maps. Try pasting some postmap(1) -q tests into your next mail. Is postmap(1) able to do the LDAP query? -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Re: virtual_alias_maps works with hash but not LDAP (Postfix 2.5.1)]
John/SML a écrit : [snip] however, there is an error about cleanup server in the verbose log when using LDAP :- mouss said: next time, do not show VERBOSE logs unless asked. ... [verbose log ignored] I googled the problem, but find no clue. Any idea? Please be collaborative, and show the infos that we need to see in order to help you. This is described in the DEBUG README. In particular: - show 'postconf -n' output - show master.cf - show NORMAL logs (not verbose) also, it would be appropriate to test the SAME config with ldap and with hash, to make sure that the problem only happens with ldap.
[Re: virtual_alias_maps works with hash but not LDAP (Postfix 2.5.1)]
the pipe(8) man page for information about ${recipient}
# and other message envelope options.
#
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
#
# Other external delivery methods.
#
ifmailunix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender
$recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extension}
mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}
=== end of master.cf ===
The log (at /var/log/mail.log) follows :-
=== begin of error log ===
Jul 28 08:31:51 imapsv02 postfix/master[17401]: daemon started --
version 2.5.1, configuration /etc/postfix
Jul 28 08:32:01 imapsv02 postfix/smtpd[17407]: connect from
imapsv02.auth.hk1.sml.citizen.co.jp[10.144.1.50]
Jul 28 08:32:23 imapsv02 postfix/smtpd[17407]: 78C2F25E6F:
client=imapsv02.auth.hk1.sml.citizen.co.jp[10.144.1.50]
Jul 28 08:32:23 imapsv02 postfix/master[17401]: warning: process
/usr/lib/postfix/cleanup pid 17410 exit status 2
Jul 28 08:32:23 imapsv02 postfix/master[17401]: warning:
/usr/lib/postfix/cleanup: bad command startup -- throttling
=== end of error log ===
I have disabled chroot in SMTP but Postfix failed with an error 451 4.3.0
Error: queue file write error :-
Trying 10.144.1.50...
Connected to imapsv02.auth.hk1.sml.citizen.co.jp.
Escape character is '^]'.
220 imapsv02.auth.hk1.sml.citizen.co.jp ESMTP Postfix (Ubuntu)
helo auth.hk1.sml.citizen.co.jp
250 imapsv02.auth.hk1.sml.citizen.co.jp
mail from: j...@sml.citizen.co.jp
250 2.1.0 Ok
rcpt to: venus@auth.hk1.sml.citizen.co.jp
250 2.1.5 Ok
data
354 End data with CRLF.CRLF
This is a line text.
451 4.3.0 Error: queue file write error
bye
221 2.0.0 Bye
Please help to advise what is the problem.
Thanks a lot.
John Mok
mouss mo...@ml.netoyen.net
Sent by: owner-postfix-us...@postfix.org
07/28/2009 05:40 AM
Please respond to mouss+nobulk
To: postfix-users@postfix.org
cc:
Subject:Re: [Re: virtual_alias_maps works with hash but not
LDAP (Postfix 2.5.1)]
John/SML a écrit :
[snip]
however, there is an error about cleanup server in the verbose log when
using LDAP :-
mouss said:
next time, do not show VERBOSE logs unless asked. ...
[verbose log ignored]
I googled the problem, but find no clue. Any idea?
Please be collaborative, and show the infos that we need to see in order
to help you. This is described in the DEBUG README. In particular:
- show 'postconf -n' output
- show master.cf
- show NORMAL logs (not verbose)
also, it would be appropriate to test the SAME config with ldap and with
hash, to make sure that the problem only happens with ldap.
