Re: domain-aliases / recipient_canonical_maps / vrfy
Zitat von Reindl Harald : Hm, OK, i will start my IDE and develop something nice local_recipient_maps = mysql:/etc/postfix/mysql-recipients.cf virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_alias.cf Can i use both as above because "mysql-recipients.cf" are from the dbmail-alias-table and i would like to implement a function that fills a additional table with the alias-mappings outside the scope of dbmail himself? What i would expect is that postfix will use both for verify and if receive a message to a virtual_alias it deliver the message to dbmail-lmtp with the "real address" local_recipient_maps is used for recipients with domain part listed in mydestination (= local domain class) virtual_alias_maps is used for domains listed in virtual_alias_domains (= virtual alias domain class) Virtual aliases are expected to rewrite the envelope address (routing information), local aliases don't alter the envelope address. Don't list any domain in both virtual alias domains and local domains! One way to use *could* be the following - A "pseudo" domain matching myhostname as local domain with all login IDs listed as bare user in local_recipient_maps - Virtual alias domains for all hosted domains and a virtual alias map to rewrite real-mailaddress@virtual.domain --> user@myhostname With this you can match any mailaddress to any user you like. You can also skip local at all and use a transport entry to route all @myhostname mail to "ltmp" or something like that. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: domain-aliases / recipient_canonical_maps / vrfy
* lst_ho...@kwsoft.de : > virtual_alias_maps is used for domains listed in > virtual_alias_domains (= virtual alias domain class) No, it's always applied! -- 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: domain-aliases / recipient_canonical_maps / vrfy
Zitat von Ralf Hildebrandt : * lst_ho...@kwsoft.de : virtual_alias_maps is used for domains listed in virtual_alias_domains (= virtual alias domain class) No, it's always applied! Upps, yes. This has confused me some time ago already... Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: postconf changes file ownership in 2.7 and later
Quanah Gibson-Mount: > Unlike previous postfix releases, postconf changes the ownership of the > "main.cf" file when it is executed. This breaks things that specifically > set the ownership on main.cf prior to executing postconf. Postfix main.cf and master.cf MUST BE OWNED BY ROOT. Wietse
Re: check_client_access using smtp auth usernames
Thanks Jeroen, I checked the documentation and I think smtpd_sender_login_maps might do the trick. Does anyone know if a many-to-many (M-to-M) mapping is allowed in these maps? That is, the following example is valid (a hash file)? ma...@example.com user1 ma...@example.com user2 ma...@example.com user3 ma...@example.com user1 ma...@example.com user2 ma...@example.com user1 ma...@example.com user3 If a M-to-M relationship is allowed, what is the correct table format (if the above is not correct)? Thanks very much, Nick On 8/2/2011 1:15 πμ, Jeroen Geilman wrote: You can restrict the sender addresses an SASL authenticated user can use with smtpd_sender_login_maps; these senders can then be combined with specific recipients in a restriction class.
Re: check_client_access using smtp auth usernames
* Nikolaos Milas : > Thanks Jeroen, > > I checked the documentation and I think smtpd_sender_login_maps might > do the trick. > > Does anyone know if a many-to-many (M-to-M) mapping is allowed in > these maps? That is, the following example is valid (a hash file)? No >ma...@example.com user1 >ma...@example.com user2 >ma...@example.com user3 >ma...@example.com user1 >ma...@example.com user2 >ma...@example.com user1 >ma...@example.com user3 > > If a M-to-M relationship is allowed, what is the correct table format > (if the above is not correct)? That's documented: In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by comma and/or whitespace. -- 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
MAIL FROM rewriting per smtp client IP
Hi All, I need to rewrite the envelope field "MAIL FROM:" but only for emails which come from particular smtp client IP. Is there any possibility how to do it? Regards, Peter Micunek --- Stavebna fakulta STU, Bratislava Faculty of Civil Engineering STU, Bratislava http://www.svf.stuba.sk
Re: MAIL FROM rewriting per smtp client IP
Peter Micunek: > Hi All, > > I need to rewrite the envelope field "MAIL FROM:" but only for > emails which come > from particular smtp client IP. > Is there any possibility how to do it? Can you describe the problem, instead of the solution (per client rewriting)? Wietse
Re: check_client_access using smtp auth usernames
Thanks Ralf, That means that the following format should be OK? ma...@example.com user1,user2,user3 ma...@example.com user1,user2 ma...@example.com user1,user3 This is still a M-to-M mapping (many mail addresses are mapped to many SASL login usernames), it's just formatted differently. All the best, Nick On 8/2/2011 2:56 μμ, Ralf Hildebrandt wrote: That's documented: In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by comma and/or whitespace.
Re: check_client_access using smtp auth usernames
* Nikolaos Milas : > Thanks Ralf, > > That means that the following format should be OK? > >ma...@example.com user1,user2,user3 >ma...@example.com user1,user2 >ma...@example.com user1,user3 > > This is still a M-to-M mapping (many mail addresses are mapped to > many SASL login usernames), it's just formatted differently. Yes -- 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: MAIL FROM rewriting per smtp client IP
Wietse, problem is that I need to have one domain in the field "MAIL FROM:" for all emails come from particular client for example 10.10.10.10 to my postfix server. The mail header field "From:" will be preserved. I need to do because these emails is routed via transport map to the destination (MMS center) which have policy based on MAIL FROM: domain. I can not allow all domains on MMSC. regards, PM On Tue, 8 Feb 2011 08:24:17 -0500 (EST), Wietse Venema wrote > Peter Micunek: > > Hi All, > > > > I need to rewrite the envelope field "MAIL FROM:" but only for > > emails which come > > from particular smtp client IP. > > Is there any possibility how to do it? > > Can you describe the problem, instead of the solution (per > client rewriting)? > > Wietse --- Stavebna fakulta STU, Bratislava Faculty of Civil Engineering STU, Bratislava http://www.svf.stuba.sk
Re: MAIL FROM rewriting per smtp client IP
Peter Micunek: > Wietse, > > problem is that I need to have one domain in the field "MAIL FROM:" > for all emails come from particular client for example 10.10.10.10 > to my postfix server. The mail header field "From:" will be > preserved. You need to configure as follows: 1) Configure Postfix to preserve the From: address in mail from this client. For control over Postfix header rewriting, see: http://www.postfix.org/postconf.5.html#local_header_rewrite_clients 2) Configure the client to send mail with the "right" From: address. The details for doing this are specific to the client. Wietse
Re: MAIL FROM rewriting per smtp client IP
On 2/8/2011 8:08 AM, Peter Micunek wrote: Wietse, problem is that I need to have one domain in the field "MAIL FROM:" for all emails come from particular client for example 10.10.10.10 to my postfix server. The mail header field "From:" will be preserved. I need to do because these emails is routed via transport map to the destination (MMS center) which have policy based on MAIL FROM: domain. I can not allow all domains on MMSC. If you are unable to properly configure the sending client, have your transport map route to a different postfix instance that uses virtual_alias_maps to rewrite the sender, then the second postfix instance can use its own transport_maps to route to the final destination. http://www.postfix.org/MULTI_INSTANCE_README.html -- Noel Jones
Re: MAIL FROM rewriting per smtp client IP
Wietse Venema: > Peter Micunek: > > Wietse, > > > > problem is that I need to have one domain in the field "MAIL FROM:" > > for all emails come from particular client for example 10.10.10.10 > > to my postfix server. The mail header field "From:" will be > > preserved. > > You need to configure as follows: > > 1) Configure Postfix to preserve the From: address in mail from >this client. For control over Postfix header rewriting, see: >http://www.postfix.org/postconf.5.html#local_header_rewrite_clients > > 2) Configure the client to send mail with the "right" From: address. >The details for doing this are specific to the client. If (2) is not possible, you can use a null content filter instead, where a customized Postfix SMTP client "replaces" the From: header using PCRE regular expressions, and then sends the result directly into a Postfix SMTP server on 127.0.0.1 port 10026. /etc/postfix/main.cf: smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access /etc/postfix/client_access: 10.10.10.10 FILTER foobar:127.0.0.1:10026 /etc/postfix/master.cf: foobar unix - - n - - smtp -o smtp_generic_maps=pcre:/etc/postfix/foobar_generic.pcre 127.0.0.1:10026 inet n - n - - smtpd -o receive_override_options=no_address_mappings,no_milters /etc/postfix/foobar_generic.pcre: /^From: something/ REPLACE From: something This assumes that you aren't already using FILTER for other purposes. References: http://www.postfix.org/FILTER_README.html http://www.postfix.org/master.5.html http://www.postfix.org/postconf.5.html#receive_override_options http://www.postfix.org/postconf.5.html#smtp_generic_maps http://www.postfix.org/generic.html http://www.postfix.org/pcre_table.html Wietse
Re: MAIL FROM rewriting per smtp client IP
Wietse, It seems that you helped me. Thanks a lot PM On Tue, 8 Feb 2011 10:26:19 -0500 (EST), Wietse Venema wrote > Wietse Venema: > > Peter Micunek: > > > Wietse, > > > > > > problem is that I need to have one domain in the field "MAIL FROM:" > > > for all emails come from particular client for example 10.10.10.10 > > > to my postfix server. The mail header field "From:" will be > > > preserved. > > > > You need to configure as follows: > > > > 1) Configure Postfix to preserve the From: address in mail from > >this client. For control over Postfix header rewriting, see: > >http://www.postfix.org/postconf.5.html#local_header_rewrite_clients > > > > 2) Configure the client to send mail with the "right" From: address. > >The details for doing this are specific to the client. > > If (2) is not possible, you can use a null content filter instead, > where a customized Postfix SMTP client "replaces" the From: header > using PCRE regular expressions, and then sends the result directly > into a Postfix SMTP server on 127.0.0.1 port 10026. > > /etc/postfix/main.cf: > smtpd_client_restrictions = > check_client_access hash:/etc/postfix/client_access > > /etc/postfix/client_access: > 10.10.10.10 FILTER foobar:127.0.0.1:10026 > > /etc/postfix/master.cf: > foobar unix - - n - - smtp > -o smtp_generic_maps=pcre:/etc/postfix/foobar_generic.pcre > 127.0.0.1:10026 inet n - n - - smtpd > -o receive_override_options=no_address_mappings,no_milters > > /etc/postfix/foobar_generic.pcre: > /^From: something/REPLACE From: something > > This assumes that you aren't already using FILTER for other purposes. > > References: > http://www.postfix.org/FILTER_README.html > http://www.postfix.org/master.5.html > http://www.postfix.org/postconf.5.html#receive_override_options > http://www.postfix.org/postconf.5.html#smtp_generic_maps > http://www.postfix.org/generic.html > http://www.postfix.org/pcre_table.html > > Wietse --- Stavebna fakulta STU, Bratislava Faculty of Civil Engineering STU, Bratislava http://www.svf.stuba.sk
Re: domain-aliases / recipient_canonical_maps / vrfy
On Tue, Feb 08, 2011 at 09:25:06AM +0100, lst_ho...@kwsoft.de wrote: > local_recipient_maps is used for recipients with domain part listed in > mydestination (= local domain class) > virtual_alias_maps is used for domains listed in virtual_alias_domains (= > virtual alias domain class) NO, virtual(5) rewriting is applied to ALL recipients. With virtual alias domains, it is *required* that an address be rewritten to another domain, but rewriting via virtual(5) is NOT restricted to such domains. Therefore, the virtual(5) table is used an additional source of valid users for ALL address classes. -- Viktor.
Re: MAIL FROM rewriting per smtp client IP
Peter Micunek: > Wietse, > > It seems that you helped me. > > Thanks a lot Good. for posteriority, the examples below uses smtp_header_checks syntax instead of smtp_generic_checks syntax. Either feature should do the job, when used appropriately. Wietse > PM > > On Tue, 8 Feb 2011 10:26:19 -0500 (EST), Wietse Venema wrote > > Wietse Venema: > > > Peter Micunek: > > > > Wietse, > > > > > > > > problem is that I need to have one domain in the field "MAIL FROM:" > > > > for all emails come from particular client for example 10.10.10.10 > > > > to my postfix server. The mail header field "From:" will be > > > > preserved. > > > > > > You need to configure as follows: > > > > > > 1) Configure Postfix to preserve the From: address in mail from > > >this client. For control over Postfix header rewriting, see: > > >http://www.postfix.org/postconf.5.html#local_header_rewrite_clients > > > > > > 2) Configure the client to send mail with the "right" From: address. > > >The details for doing this are specific to the client. > > > > If (2) is not possible, you can use a null content filter instead, > > where a customized Postfix SMTP client "replaces" the From: header > > using PCRE regular expressions, and then sends the result directly > > into a Postfix SMTP server on 127.0.0.1 port 10026. > > > > /etc/postfix/main.cf: > > smtpd_client_restrictions = > > check_client_access hash:/etc/postfix/client_access > > > > /etc/postfix/client_access: > > 10.10.10.10 FILTER foobar:127.0.0.1:10026 > > > > /etc/postfix/master.cf: > > foobar unix - - n - - smtp > > -o smtp_generic_maps=pcre:/etc/postfix/foobar_generic.pcre > > 127.0.0.1:10026 inet n - n - - smtpd > > -o receive_override_options=no_address_mappings,no_milters > > > > /etc/postfix/foobar_generic.pcre: > > /^From: something/ REPLACE From: something > > > > This assumes that you aren't already using FILTER for other purposes. > > > > References: > > http://www.postfix.org/FILTER_README.html > > http://www.postfix.org/master.5.html > > http://www.postfix.org/postconf.5.html#receive_override_options > > http://www.postfix.org/postconf.5.html#smtp_generic_maps > > http://www.postfix.org/generic.html > > http://www.postfix.org/pcre_table.html > > > > Wietse > > > --- > Stavebna fakulta STU, Bratislava > Faculty of Civil Engineering STU, Bratislava > http://www.svf.stuba.sk > > > >
aNULL cipher suite
OpenSSL.org states: aNULL the cipher suites offering no authentication. This is currently the anonymous DH algorithms. These cipher suites are vulnerable to a ``man in the middle'' attack and so their use is normally discouraged. However, this cipher suite is enabled by default with postfix for the smtpd process: smtp_tls_mandatory_ciphers = medium tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH Shouldn't it be excluded by default? I got rid of it by adding it to smtpd_tls_exclude_ciphers --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: aNULL cipher suite
--On Tuesday, February 08, 2011 11:39 AM -0800 Quanah Gibson-Mount wrote: OpenSSL.org states: aNULL the cipher suites offering no authentication. This is currently the anonymous DH algorithms. These cipher suites are vulnerable to a ``man in the middle'' attack and so their use is normally discouraged. However, this cipher suite is enabled by default with postfix for the smtpd process: smtp_tls_mandatory_ciphers = medium tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH Shouldn't it be excluded by default? I got rid of it by adding it to smtpd_tls_exclude_ciphers Never mind, I see it's automatically disabled if client certs are requested. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
sender_dependent_relayhost_maps vs aliases file
Hello, I noticed after configuring sender_dependent_relayhost_maps and expecting it to forward mail to my listed destination does not work as expected. I need sender_dependent_relayhost_maps to forward mail depending what the the source is. Our team has split into 2 so since we have 2 relays I figured I would change the root alias on the second relay and forward mail depending from the from= The main relay root alias points to blablabla@domain and the second relay got changed to albalb...@domain.com So, I need to configure ALL hosts that start wth the letter "L" to go to the second relay and the rest of the mails continue to be serviced by the main relay MAIN RELAY CONFIG - aliases root: blablabla@domain main.cf -snip- sender_dependent_relayhost_maps = regexp:/etc/postfix-hd/sender_relayhost -snip- sender_relayhost file /root@myserver.domain/[1.2.3.4] when I look at my logs I noticed that from= gets sent to blablabla@domain when in reality I want it to be relayed to the relay defined in the sender_relay file 1.2.3.4 and get sent to albalb...@domain.com thx in advance,
Re: aNULL cipher suite
On Tue, Feb 08, 2011 at 11:39:14AM -0800, Quanah Gibson-Mount wrote: > OpenSSL.org states: > > aNULL > > the cipher suites offering no authentication. This is currently the > anonymous DH algorithms. These cipher suites are vulnerable to a ``man in > the middle'' attack and so their use is normally discouraged. > > However, this cipher suite is enabled by default with postfix for the smtpd > process: > > smtp_tls_mandatory_ciphers = medium > tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH > > Shouldn't it be excluded by default? I got rid of it by adding it to > smtpd_tls_exclude_ciphers No, it SHOULD NOT be disabled. http://www.postfix.org/TLS_README.html#server_cipher By default anonymous ciphers are enabled. They are automatically disabled when remote SMTP client certificates are requested. If clients are expected to always verify the Postfix SMTP server certificate you may want to disable anonymous ciphers by setting "smtpd_tls_mandatory_exclude_ciphers = aNULL" or "smtpd_tls_exclude_ciphers = aNULL", as appropriate. One can't force a remote SMTP client to check the server certificate, so excluding anonymous ciphers is generally unnecessary. http://www.postfix.org/TLS_README.html#client_cipher By default anonymous ciphers are allowed, and automatically disabled when remote SMTP server certificates are verified. If you want to disable anonymous ciphers even at the "encrypt" security level, set "smtp_tls_mandatory_exclude_ciphers = aNULL"; and to disable anonymous ciphers even with opportunistic TLS, set "smtp_tls_exclude_ciphers = aNULL". There is generally no need to take these measures. Anonymous ciphers save bandwidth and TLS session cache space, if certificates are ignored, there is little point in requesting them. Without certificate checks, you vulnerable to MITM regardless of the cipher-suite. SMTP TLS is almost always opportunistic, or "encrypt" nobody but lunatics like myself uses "secure-channel" TLS with SMTP. -- Viktor.
Re: MAIL FROM rewriting per smtp client IP
On Tue, Feb 08, 2011 at 02:01:43PM -0500, Wietse Venema wrote: > Good. for posteriority, the examples below uses smtp_header_checks > syntax instead of smtp_generic_checks syntax. Either feature should > do the job, when used appropriately. That would be smtp_generic_maps of course, which rewrites header addresses, using a more complete parser than can be shoe-horned into PCRE regular expressions. -- Viktor.
Re: sender_dependent_relayhost_maps vs aliases file
On 02/08/2011 08:47 PM, GB GB wrote: Hello, I noticed after configuring sender_dependent_relayhost_maps and expecting it to forward mail to my listed destination does not work as expected. I need sender_dependent_relayhost_maps to forward mail depending what the the source is. Our team has split into 2 so since we have 2 relays I figured I would change the root alias on the second relay and forward mail depending from the from= The main relay root alias points to blablabla@domain and the second relay got changed to albalb...@domain.com So, I need to configure ALL hosts that start wth the letter "L" to go to the second relay and the rest of the mails continue to be serviced by the main relay MAIN RELAY CONFIG - aliases root: blablabla@domain main.cf -snip- sender_dependent_relayhost_maps = regexp:/etc/postfix-hd/sender_relayhost -snip- sender_relayhost file /root@myserver.domain/[1.2.3.4] when I look at my logs I noticed that from= gets sent to blablabla@domain when in reality I want it to be relayed to the relay defined in the sender_relay file 1.2.3.4 and get sent to albalb...@domain.com r...@ltest01.domain.com != root@myserver.domain Your regex makes no sense, as it will only match one address. A normal hash: map is perfectly suited for exact matches. -- J.
geotrust intermediate ca question
Hi, geotrust has changed ssl procedures for this in i.e apache i have to add intermediate in a extra SSLCACertificateFile like written here http://www.geotrust.com/resources/extended-validation-ssl/installation-instructions.html for some browsers so now comes the question related to postfix before i used smtpd_tls_cert_file = /etc/postfix/wildcard.crt smtpd_tls_key_file = /etc/postfix/wildcard.key smtpd_tls_CAfile = /etc/postfix/wildcard.pem smtp_tls_CAfile = /etc/postfix/wildcard.pem where /etc/postfix/wildcard.pem was build with cat /etc/postfix/wildcard.crt /etc/postfix/wildcard.key > /etc/postfix/wildcard.pem i am not quite sure if or how i should include intermediate ca in postfix -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: domain-aliases / recipient_canonical_maps / vrfy
Zitat von Victor Duchovni : On Tue, Feb 08, 2011 at 09:25:06AM +0100, lst_ho...@kwsoft.de wrote: local_recipient_maps is used for recipients with domain part listed in mydestination (= local domain class) virtual_alias_maps is used for domains listed in virtual_alias_domains (= virtual alias domain class) NO, virtual(5) rewriting is applied to ALL recipients. With virtual alias domains, it is *required* that an address be rewritten to another domain, but rewriting via virtual(5) is NOT restricted to such domains. Therefore, the virtual(5) table is used an additional source of valid users for ALL address classes. I already noticed, thanks. I even made this mistake some time ago and wonder why it has not settled yet in mind. Maybe because it is not that straight as expected. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: sender_dependent_relayhost_maps vs aliases file
My apologies, the sender_relay contains /r...@ltest01.domain.com/ [1.2.3.4] Regxp is what I will use for this map Regards, On 2011-02-08, at 3:48 PM, Jeroen Geilman wrote: > On 02/08/2011 08:47 PM, GB GB wrote: >> Hello, >> >> I noticed after configuring sender_dependent_relayhost_maps and >> expecting it to forward mail to my listed destination does not work as >> expected. >> >> I need sender_dependent_relayhost_maps to forward mail depending what >> the the source is. >> Our team has split into 2 so since we have 2 relays I figured I would >> change the root alias on the second relay and forward mail >> depending from the from= >> >> The main relay root alias points to blablabla@domain and the second >> relay got changed to albalb...@domain.com >> So, I need to configure ALL hosts that start wth the letter "L" to go >> to the second relay and the rest of the mails continue to be serviced >> by the main relay >> >> MAIN RELAY CONFIG >> - >> aliases >> root: blablabla@domain >> >> main.cf >> -snip- >> sender_dependent_relayhost_maps = regexp:/etc/postfix-hd/sender_relayhost >> -snip- >> >> sender_relayhost file >> /root@myserver.domain/[1.2.3.4] >> >> when I look at my logs I noticed that from= >> gets sent to blablabla@domain when in reality I want it to be relayed >> to >> the relay defined in the sender_relay file 1.2.3.4 and get sent to >> albalb...@domain.com >> > > r...@ltest01.domain.com != root@myserver.domain > > Your regex makes no sense, as it will only match one address. > A normal hash: map is perfectly suited for exact matches. > > -- > J. >
Re: sender_dependent_relayhost_maps vs aliases file
gbcy...@gmail.com: > My apologies, the sender_relay contains > /r...@ltest01.domain.com/ [1.2.3.4] > > Regxp is what I will use for this map Please show COMPLETE postconf -n output. As documented at http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps the sender_dependent_relayhost_maps feature has no effect when you use relay_transport, sender_dependent_default_transport_maps, default_transport or transport_maps. Wietse
Re: domain-aliases / recipient_canonical_maps / vrfy
On 2011-02-07 8:28 PM, Noel Jones wrote: > On 2/7/2011 5:44 PM, Reindl Harald wrote: >> "mysql-recipients.cf" is querying dbmail for valid addresses >> dbmail do not have domain-aliases and so postfix should handle >> this by saying "thelounge.at is an alias for the lounge.net >> and if someone sends a mal at inva...@thelounge.net i check >> if inva...@thelounge.net exists" >> >> the "recipient_canonical_maps" seems to use the @targetdomain >> and DO NOT use "mysql-recipients.cf" becasue "invalid@domain" >> does not exist and is received for the alias-domain and the >> reject happens later after rewrite the rctp by the lmtp > Don't use "domain aliases". > > Wildcard address rewrites disable recipient validation. Postfixadmin (2.3.2+) has working recipient verification with alias domains... -- Best regards, Charles
Re: domain-aliases / recipient_canonical_maps / vrfy
Am 08.02.2011 22:32, schrieb Charles Marcus: >> Don't use "domain aliases". >> >> Wildcard address rewrites disable recipient validation. > > Postfixadmin (2.3.2+) has working recipient verification with alias > domains... Hm - I will take a look what they do if i find no simple solution external admin-software is a no-go because we have centralized and self-developed backends for postfix/dbmail, pureftpd, httpd, bind, dhcpd, domain-registration which is all tuned to work with each other in one admin-ui signature.asc Description: OpenPGP digital signature
Re: domain-aliases / recipient_canonical_maps / vrfy
On 2/8/2011 3:32 PM, Charles Marcus wrote: On 2011-02-07 8:28 PM, Noel Jones wrote: On 2/7/2011 5:44 PM, Reindl Harald wrote: "mysql-recipients.cf" is querying dbmail for valid addresses dbmail do not have domain-aliases and so postfix should handle this by saying "thelounge.at is an alias for the lounge.net and if someone sends a mal at inva...@thelounge.net i check if inva...@thelounge.net exists" the "recipient_canonical_maps" seems to use the @targetdomain and DO NOT use "mysql-recipients.cf" becasue "invalid@domain" does not exist and is received for the alias-domain and the reject happens later after rewrite the rctp by the lmtp Don't use "domain aliases". Wildcard address rewrites disable recipient validation. Postfixadmin (2.3.2+) has working recipient verification with alias domains... ... because it's not a wildcard rewrite, but rather a carefully crafted SQL schema with an appropriate multi-domain query. Simple "example.com -> example.net" domain aliases break recipient validation. -- Noel Jones
Re: domain-aliases / recipient_canonical_maps / vrfy
On 2011-02-08 4:39 PM, Noel Jones wrote: > On 2/8/2011 3:32 PM, Charles Marcus wrote: >> On 2011-02-07 8:28 PM, Noel Jones wrote: >>> Don't use "domain aliases". >>> >>> Wildcard address rewrites disable recipient validation. >> Postfixadmin (2.3.2+) has working recipient verification with alias >> domains... > ... because it's not a wildcard rewrite, but rather a carefully crafted > SQL schema with an appropriate multi-domain query. > > Simple "example.com -> example.net" domain aliases break recipient > validation. I know, I didn't claim otherwise... I was just pointing him to somewhere for an idea on how to get it working... -- Best regards, Charles
Re: sender_dependent_relayhost_maps vs aliases file
here is the outputthe current version of postfix is 2.3.19
2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map =
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = postmaster
address_verify_service_name = error: verify service is disabled.
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = dbm:/etc/postfix-hd/aliases
alias_maps = dbm:/etc/postfix-hd/aliases,
ldap:/etc/postfix-hd/ldap_cip, ldap:/etc/postfix-hd/ldap_mail,
ldap:/etc/postfix-hd/ldap_mail_fqdn
allow_mail_to_commands = alias
allow_mail_to_files = alias
allow_min_user = no
allow_percent_hack = no
allow_untrusted_routing = no
alternate_config_directories = /etc/postfix-hd /etc/postfix-i
/etc/postfix-o /etc/postfix-s
always_bcc =
append_at_myorigin = yes
append_dot_mydomain = yes
application_event_drain_time = 100s
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport =
biff = no
body_checks =
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 1d
bounce_service_name = bounce
bounce_size_limit = 5
broken_sasl_auth_clients = no
canonical_maps =
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_expansion_filter =
1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix-hd
content_filter =
daemon_directory = /usr/lib/postfix
daemon_timeout = 18000s
debug_peer_level = 2
debug_peer_list =
default_database_type = dbm
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_limit = 20
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = postrsh
default_process_limit = 100
default_rbl_reply = $rbl_code Service unavailable; $rbl_class
[$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}
default_recipient_limit = 1
default_transport = smtp
default_verp_delimiters = +=
defer_code = 450
defer_service_name = defer
defer_transports =
delay_notice_recipient = postmaster
delay_warning_time = 0h
deliver_lock_attempts = 20
deliver_lock_delay = 1s
disable_dns_lookups = no
disable_mime_input_processing = no
disable_mime_output_conversion = no
disable_verp_bounces = no
disable_vrfy_command = yes
dont_remove = 0
double_bounce_sender = double-bounce
duplicate_filter_limit = 1000
empty_address_recipient = MAILER-DAEMON
enable_original_recipient = yes
error_notice_recipient = postmaster
error_service_name = error
expand_owner_alias = no
export_environment = TZ MAIL_CONFIG
fallback_transport =
fast_flush_domains = $relay_domains
fast_flush_purge_time = 7d
fast_flush_refresh_time = 12h
fault_injection_code = 0
flush_service_name = flush
fork_attempts = 5
fork_delay = 1s
forward_expansion_filter =
1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
forward_path =
hash_queue_depth = 1
hash_queue_names = incoming, active, deferred, bounce, defer, flush, hold, trace
header_address_token_limit = 10240
header_checks = regexp:/etc/postfix-hd/header_checks
header_size_limit = 102400
helpful_warnings = yes
home_mailbox =
hopcount_limit = 50
html_directory = no
ignore_mx_lookup_error = no
import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ
in_flow_delay = 1s
inet_interfaces = 127.0.0.1, xx.xx.xx.xx
initial_destination_concurrency = 5
invalid_hostname_reject_code = 501
ipc_idle = 100s
ipc_timeout = 3600s
ipc_ttl = 1000s
line_length_limit = 2048
lmtp_connect_timeout = 0s
lmtp_data_done_timeout = 600s
lmtp_data_init_timeout = 120s
lmtp_data_xfer_timeout = 180s
lmtp_destination_concurrency_limit = $default_destination_concurrency_limit
lmtp_destination_recipient_limit = $default_destination_recipient_limit
lmtp_lhlo_timeout = 300s
lmtp_mail_timeout = 300s
lmtp_quit_timeout = 300s
lmtp_rcpt_timeout = 300s
lmtp_rset_timeout = 120s
lmtp_sasl_auth_enable = no
lmtp_sasl_password_maps =
lmtp_sasl_security_options = noplaintext, noanonymous
lmtp_send_xforward_command = no
lmtp_tcp_port = 24
lmtp_xforward_timeout = 300s
local_command_shell = /usr/lib/smrsh -c
local_destination_concurrency_limit = 2
local_destination_recipient_limit = 1
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
local_transport = local:$myhostname
luser_relay =
mail_name = mail
mail_owner = postfix
mail_release_date = 20040915
mail_spool_directory = /var/mail
mail_version =
Re: sender_dependent_relayhost_maps vs aliases file
GB GB: > here is the outputthe current version of postfix is 2.3.19 > I asked for "postconf -n" output. I did not ask for hundreds of parameter settings. Wietse
Un message de Mickael t'attend...
Un message de Mickael t'attend... L'expéditeur et le contenu seront visibles seulement par toi et tu peux le supprimer à tout moment. Tu peux aussi y répondre directement au travers du messenger. Pour découvrir qui est à l'origine du message, suis simplement ce lien: http://eu1.badoo.com/0199422682/in/eqC0pblDW0U/?lang_id=6 D'autres personnes sont aussi présentes: Sino (Beijing Shi, Chine) Nath (Liège, Belgique) Emanuele (Guidonia Montecelio, Italie) http://eu1.badoo.com/0199422682/in/eqC0pblDW0U/?lang_id=6 Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur. Tu as reçu cet email suite à une requête de Mickael sur notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système. Merci, L'équipe Badoo Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir: http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=63&email=postfix-users%40postfix.org&secret=&invite_id=87213&user_id=199422682
Re: sender_dependent_relayhost_maps vs aliases file
postconf -n -c /etc/postfix-hd will render the output I sent in the earlier mail regards, On Tue, Feb 8, 2011 at 5:20 PM, Wietse Venema wrote: > GB GB: >> here is the outputthe current version of postfix is 2.3.19 >> > > I asked for "postconf -n" output. > > I did not ask for hundreds of parameter settings. > > Wietse >
Re: sender_dependent_relayhost_maps vs aliases file
On 2/8/2011 5:39 PM, GB GB wrote: postconf -n -c /etc/postfix-hd will render the output I sent in the earlier mail regards, On Tue, Feb 8, 2011 at 5:20 PM, Wietse Venema wrote: GB GB: here is the outputthe current version of postfix is 2.3.19 I asked for "postconf -n" output. I did not ask for hundreds of parameter settings. Wietse /var/log# postconf -n -c /etc/postfix/ | wc -l 56 /var/log# postconf -d -c /etc/postfix/ | wc -l 644 I think you were sending postconf -d instead? -DB
Re: sender_dependent_relayhost_maps vs aliases file
GB GB: > postconf -n -c /etc/postfix-hd will render the output I sent in the > earlier mail I don't have time for people with hundreds of parameters in their main.cf file. You can find out for yourself if the requirements for sender_dependent_relayhost_maps are met: no transport_maps, no relayhost, etc. as described in the documentation. Wietse > > On Tue, Feb 8, 2011 at 5:20 PM, Wietse Venema wrote: > > GB GB: > >> here is the outputthe current version of postfix is 2.3.19 > >> > > > > I asked for "postconf -n" output. > > > > I did not ask for hundreds of parameter settings. > > > > ? ? ? ?Wietse > > > >
Re: sender_dependent_relayhost_maps vs aliases file
When I search for those clauses I come up with the following address_verify_relayhost = $relayhost address_verify_transport_maps = $transport_maps 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 relayhost = myrelay.$mydomain sender_dependent_relayhost_maps = regexp:/etc/postfix-hd/sender_relayhost transport_maps = dbm:/etc/postfix-hd/transport so if I understand correctly, when I use sender_dependent_relayhost_maps transport and relayhost need to be empty the transport file is configured with the domain name ex relay8:mydomain thx for the help, regards On Tue, Feb 8, 2011 at 5:44 PM, Wietse Venema wrote: > GB GB: >> postconf -n -c /etc/postfix-hd will render the output I sent in the >> earlier mail > > I don't have time for people with hundreds of parameters > in their main.cf file. > > You can find out for yourself if the requirements for > sender_dependent_relayhost_maps are met: no transport_maps, > no relayhost, etc. as described in the documentation. > > Wietse > >> >> On Tue, Feb 8, 2011 at 5:20 PM, Wietse Venema wrote: >> > GB GB: >> >> here is the outputthe current version of postfix is 2.3.19 >> >> >> > >> > I asked for "postconf -n" output. >> > >> > I did not ask for hundreds of parameter settings. >> > >> > ? ? ? ?Wietse >> > >> >> > >
Re: geotrust intermediate ca question
On Tue, 2011-02-08 at 22:04:38 +0100, Robert Schetterer wrote: > Hi, geotrust > has changed ssl procedures > for this in i.e apache > i have to add intermediate in a extra > SSLCACertificateFile [ .. ] > i am not quite sure if or how i should include > intermediate ca in postfix The TLS_README contains a few words on configuration with intermediate CAs. -- Sahil Tandon
Re: message tracking logging request
On 2/3/11 11:52 AM, Reindl Harald wrote: >> When someone reports a problem with mail from a given server, I can >> grep for the ip address of the server, then re-grep for the connection >> ids associated with that address and get everything that was ever logged >> about mail from that server. > > what is the benefit? > > connection id = one id for each connection > so hwat would be the difference grep the ip oder id? The most common question is "where did my email go?" To answer it, you ask "from, to, when?" Find the log file for the when Ideally, you could grep "fromaddr.*toaddr" but in reality, it's grep fromaddr, get list of message ids, grep them | grep toaddr. that gives you a final list of message ids to grep for. currently, that actually doesn't give you all the log messages: you have to find the ip address and smtpd process id from the initial client= log message, then go back and grep for them to see the actual connect/disconnect, TLS setup and who knows what else messages that are connection related. And then try to match them back up to any actual messages. if every connection has an id that is in every log message, if you have a message id, you grep for the connection part and get everything related to it. If you have an ip address, you get a list of all the connections it made and again, you do one more search to get everything related to that server. It just makes life simpler. It's not terribly difficult to do this stuff, but when you have order gigabyte daily logfiles, the fewer and easier searches you have to do, the better... smime.p7s Description: S/MIME Cryptographic Signature
Re: multiple ssl certificates for multiple domains but just one IP
On 2/4/11 3:31 AM, Alokat wrote: > On 02/03/2011 08:10 PM, Reindl Harald wrote: >> AFAIK this is a problem that does not exist in the real world >> We are hosting 200 mail domains and there is one hostname >> and one certificate for all of them > yeah I guess I will just use one certificate for all domains. > But it would be cool if it would work. :-) More than cool; our main server is setup with the "you'll use our host name" approach so ssl works. An inherited server has a large number of domains that are all setup as "mail.domain.name", and the ssl cert problem is one of the large barriers to getting people to use ssl. It's something fixed with TLS/SNI (apparently OpenSSL 0.9.8f or later supports it, though client side support is anyone's guess), but not something I've had time to investigate and deploy yet. smime.p7s Description: S/MIME Cryptographic Signature
Re: How to get a list of mails from mail log?
> I'm afraid Wolfgang's method is the only one, then - you'd have to > correlate all recipients by incoming queue-id. > A perl array could probably do this moderately efficiently, but I know > of no ready-made tools that do this - especially since, as you said, the > Subject: logging was customized to begin with. I would be surprised if no one before was interested in clearly readable and complete mail lists... H.
Re: sender_dependent_relayhost_maps vs aliases file
GB GB put forth on 2/8/2011 4:52 PM: > so if I understand correctly, when I use > sender_dependent_relayhost_maps transport and relayhost need to be > empty GB GB put forth on 2/8/2011 4:10 PM: > here is the outputthe current version of postfix is 2.3.19 > > mail_release_date = 20040915 > mail_version = 2.1.5 According to your postconf -n output you're actually using Postfix 2.1.5, not 2.3.19, which means that sender_dependent_relayhost_maps is not available to you. It requires 2.3.x or later. Seriously consider upgrading to a much newer version of Postfix. In the mean time, you need to fix whatever problem is causing version reporting discrepancy WRT your Postfix environment. The mail_version reported via postconf should be authoritative. Where did you obtain 2.3.19 as your running version? -- Stan
Re: How to get a list of mails from mail log?
meyer-jor...@t-online.de put forth on 2/8/2011 11:59 PM: >> I'm afraid Wolfgang's method is the only one, then - you'd have to >> correlate all recipients by incoming queue-id. >> A perl array could probably do this moderately efficiently, but I know >> of no ready-made tools that do this - especially since, as you said, the >> Subject: logging was customized to begin with. > > I would be surprised if no one before was interested in clearly readable and > complete mail lists... The Barracuda A/S appliances do this via a web UI. It lists every incoming mail, ever--from, to, date/time, and when you click it, the entire individual email is displayed with all headers. It sounds like this is what you're looking for. I don't know of a purely open source equivalent of this one UI feature exists, but I've never gone looking for such. Sounds like you're a good candidate for a mail appliance. -- Stan
