Re: (ot) beware libressl on Freebsd
On Tue, Sep 13, 2016 at 12:13 AM, wrote: > Openssl and libressl have a conflict, so I had uninstalled libressl prior to > reinstalling openssl. You should have in your /etc/make.conf DEFAULT_VERSIONS+= ssl=base or ssl=openssl (openssl from ports) or ssl=libressl -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/
Re: Is there actual postfix 3.1 + cyrus-sasl + gssapi howto ?
On Tue, Sep 13, 2016 at 01:47:52PM +0500, Вадим Бажов wrote: > Anyone ? Wietse, Viktor ? http://postfix.1071664.n5.nabble.com/Is-there-actual-postfix-3-1-cyrus-sasl-gssapi-howto-tt86083.html#a86089 -- Viktor.
Re: mysql lookup table and utf8
On 12/09/2016 17:04, Wietse Venema wrote: Just for test, what happens when you do: (this is what Postfix daemons use by default) LC_ALL=C postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf (this is to test what happens with an UTF-8 locale) LC_ALL=en_US.UTF-8 postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf Just a stupid question but am I right to think the use case I'm trying to implement using Postfix 3+ and a SQL backend should work ? Thanks in advance, Antoine Nguyen
Re: mysql lookup table and utf8
Antoine Nguyen: > On 12/09/2016 17:04, Wietse Venema wrote: > > > > Just for test, what happens when you do: > > > > (this is what Postfix daemons use by default) > > LC_ALL=C postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf > > > > (this is to test what happens with an UTF-8 locale) > > LC_ALL=en_US.UTF-8 postmap -q rat?.com > > mysql:/etc/postfix/sql-domains.cf > > > Just a stupid question but am I right to think the use case I'm trying > to implement using Postfix 3+ and a SQL backend should work ? Yes, UTF-8 queries are supposed to work with all Postfix lookup tables, so the question is where things go wrong. Wietse
Re: (ot) beware libressl on Freebsd
On 09/12/2016 03:13 PM, li...@lazygranch.com wrote: Freebsd 10.3 I ran freebsd "pkg" and didn't see any of the mail suite or openssl in the list of files to update, so I figured it was safe to run. (I've been burnt by pkg messing up dovecot or postfix, so I always use the ports). Some program must of needed libressl and openssl got replaced, breaking my email. Even reinstalling openssl wasn't sufficient because any program using openssl broke. SpamAssassin was having none of this, so I ended up reinstalling the whole email suite. No con file issues fortunately. Openssl and libressl have a conflict, so I had uninstalled libressl prior to reinstalling openssl. I think ntp was the program that wanted libressl. It didn't occur to me the program even used TLS I run with both libraries on CentOS 7. The shared libraries have different versions, so no conflict. With LibreSSL I rename the binary to libressl and the configuration file to libressl.cnf and patch the source to look for that. I only have the devel headers for one installed at a time. -- -=- Sent my from my laptop, may not be able to respond timely
Re: mysql lookup table and utf8
On 13/09/2016 12:43, Wietse Venema wrote: Antoine Nguyen: On 12/09/2016 17:04, Wietse Venema wrote: Just for test, what happens when you do: (this is what Postfix daemons use by default) LC_ALL=C postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf (this is to test what happens with an UTF-8 locale) LC_ALL=en_US.UTF-8 postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf Just a stupid question but am I right to think the use case I'm trying to implement using Postfix 3+ and a SQL backend should work ? Yes, UTF-8 queries are supposed to work with all Postfix lookup tables, so the question is where things go wrong. Fine. Do you have any hint/idea on what I could do to locate the issue ? Antoine
Question for socketmap_table
Hi, I just looked into the socketmap_table man page. I try to understand several things: First: Is it correct that request and response are not terminated by newline? Second the respone: OK data The requested data was found. NOTFOUND The requested data was not found. TEMP reason TIMEOUT reason PERM reason The request failed. The reason, if non-empty, is descriptive text. Which of these return values do work with postscreen_access_list? Could someone give me an example please :-) ? I no of the expected results of postscreen_access_list: permit_mynetworks, dunno, reject, permit, type:table As the response tokens are not described in detail, I ask for help here. OK permit (or dunno) NOTFOUND TEMP What is done with this reason? TIMEOUT What does it do and what is the reason for? PERM reject Is the OK and PERM correct for this access list? Thanks in advance Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
Message size limit responses
Is it possible to return a message to someone who wants to attach files that pass my message_size_limit? Thanks, Jos Chrispijn
Re: Message size limit responses
On 9/13/2016 8:39 AM, JosC wrote: > Is it possible to return a message to someone who wants to attach > files that pass my message_size_limit? > > Thanks, > Jos Chrispijn > Usually the sender will disconnect when they see your SIZE banner, so you never have an opportunity to send them anything. All you'll see in your logs is a connect/disconnect. -- Noel Jones
Re: mysql lookup table and utf8
Am 13.09.2016 um 14:22 schrieb Antoine Nguyen: On 13/09/2016 12:43, Wietse Venema wrote: Antoine Nguyen: On 12/09/2016 17:04, Wietse Venema wrote: Just for test, what happens when you do: (this is what Postfix daemons use by default) LC_ALL=C postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf (this is to test what happens with an UTF-8 locale) LC_ALL=en_US.UTF-8 postmap -q rat?.com mysql:/etc/postfix/sql-domains.cf Just a stupid question but am I right to think the use case I'm trying to implement using Postfix 3+ and a SQL backend should work ? Yes, UTF-8 queries are supposed to work with all Postfix lookup tables, so the question is where things go wrong. Fine. Do you have any hint/idea on what I could do to locate the issue ? Antoine hello ;) not sure if this will help? but had a similar issue with mysql queries a while back. it actually had nothing to do with postfix and sql lookup tables ... but ran into trouble with different mysql character sets ... causing queries to also fail not sure how your data made it into the mysql tables? but i had problems with latin-1 characters set ending up in a UTF-8 character set table and the whole thing got messed up ... it's called mysql character set hell ;) this link might help? https://www.blueboxcloud.com/insight/blog-article/getting-out-of-mysql-character-set-hell but again ... i'm not sure in your case. just an idea, perhaps it might help? greetings becki
Re: Question for socketmap_table
Christian Ro??ner: > Hi, > > I just looked into the socketmap_table man page. I try to understand several > things: > > First: Is it correct that request and response are not terminated by newline? I think that is the least of your problems. This is not a text-based protocol where messages are terminated with some end-of-line character. Instead this uses netstrings, which encode message boundaries with byte counts. You may have some additional coding ahead of you. > Second the respone: > >OK data > The requested data was found. > >NOTFOUND > The requested data was not found. > >TEMP reason > >TIMEOUT reason > >PERM reason > The request failed. The reason, if non-empty, is descriptive > text. > > Which of these return values do work with postscreen_access_list? None of them. The OK, NOTFOUND, etc. are part of the socketmap protocol. They are never visible to the postscreen_access_list. > Could someone give me an example please :-) ? You need ti distinguish between: 1 - Table-driven mechanisms, for example, transport_maps or postscreen_access_list. These use simple key-value API that is exposed by things in [2]. 2 - Table lookup mechanisms, for example, hash, mysql, or socketmap. These expose a simple key-value API that is used by things in [1]. Under the covers, table lookup mechanisms encapsulate those keys and values as "name key" or "SELECT 'foo' FROM bar" depending on whether they talk to a socketmap server or to an SQL server, but that is never visible to things in [1]. > As the response tokens are not described in detail, I ask for help here. They are. You just need to combine the postcreen_access_list documentation with the socketmap encapsulation. > OK permit (or dunno) > NOTFOUND > TEMP What is done with this reason? It is up to the table-driven mechanism to report it as a warning or to report it as a fatal error. Wietse
Re: Question for socketmap_table
> Am 13.09.2016 um 16:51 schrieb Wietse Venema : > > Christian Ro??ner: >> Hi, >> >> I just looked into the socketmap_table man page. I try to understand several >> things: >> >> First: Is it correct that request and response are not terminated by newline? > > I think that is the least of your problems. > > This is not a text-based protocol where messages are terminated > with some end-of-line character. > > Instead this uses netstrings, which encode message boundaries with > byte counts. You may have some additional coding ahead of you. > >> Second the respone: >> >> OK data >> The requested data was found. >> >> NOTFOUND >> The requested data was not found. >> >> TEMP reason >> >> TIMEOUT reason >> >> PERM reason >> The request failed. The reason, if non-empty, is descriptive >> text. >> >> Which of these return values do work with postscreen_access_list? > > None of them. The OK, NOTFOUND, etc. are part of the socketmap > protocol. They are never visible to the postscreen_access_list. > >> Could someone give me an example please :-) ? > > You need ti distinguish between: > > 1 - Table-driven mechanisms, for example, transport_maps or >postscreen_access_list. These use simple key-value API that >is exposed by things in [2]. > > 2 - Table lookup mechanisms, for example, hash, mysql, or socketmap. >These expose a simple key-value API that is used by things in [1]. > >Under the covers, table lookup mechanisms encapsulate those >keys and values as "name key" or "SELECT 'foo' FROM >bar" depending on whether they talk to a socketmap server or >to an SQL server, but that is never visible to things in [1]. > >> As the response tokens are not described in detail, I ask for help here. > > They are. You just need to combine the postcreen_access_list > documentation with the socketmap encapsulation. > >> OK permit (or dunno) >> NOTFOUND >> TEMP What is done with this reason? > > It is up to the table-driven mechanism to report it as a warning > or to report it as a fatal error. The background to my question is that I already implemented a fully working tcp-map-driven service for postscreen and I just thought about switching it to socketmap, if socketmap would give me more choices for replying. But as I guess that "reject", "permit" and "dunno" are the only possible results, this switch seems useless. What I miss is something like "defer" Thanks anyways for helping me to understand this map. Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
Re: Question for socketmap_table
On Tue, Sep 13, 2016 at 05:00:01PM +0200, Christian Rößner wrote: > > They are. You just need to combine the postcreen_access_list > > documentation with the socketmap encapsulation. > > > >> OK permit (or dunno) > >> NOTFOUND > >> TEMP What is done with this reason? > > > > It is up to the table-driven mechanism to report it as a warning > > or to report it as a fatal error. > > The background to my question is that I already implemented a fully working > tcp-map-driven service for postscreen and I just thought about switching > it to socketmap, if socketmap would give me more choices for replying. > But as I guess that "reject", "permit" and "dunno" are the only possible > results, this switch seems useless. > > What I miss is something like "defer" > > Thanks anyways for helping me to understand this map. Don't confuse the socketmap layer protocol which can find, not find or tempfail a lookup, with the Postfix syntax for the lookup result, which, depending on context access(5), header_checks(5), ... may begin with various keywords such as: OK DUNNO REJECT DEFER WARN or just some address or transport spec as with virtual(5) or transport(5). -- Viktor.
Re: mysql lookup table and utf8
On 13/09/2016 16:10, Admin Beckspaced wrote: hello ;) not sure if this will help? but had a similar issue with mysql queries a while back. it actually had nothing to do with postfix and sql lookup tables ... but ran into trouble with different mysql character sets ... causing queries to also fail not sure how your data made it into the mysql tables? but i had problems with latin-1 characters set ending up in a UTF-8 character set table and the whole thing got messed up ... it's called mysql character set hell ;) this link might help? https://www.blueboxcloud.com/insight/blog-article/getting-out-of-mysql-character-set-hell but again ... i'm not sure in your case. just an idea, perhaps it might help? Thank you for this link but, since it is a new setup, I have no data. I've already checked mysql configuration : default character set is utf8, default collation is utf8_general_ci and database and tables are using those values. Also, it looks like the data inserted by Modoboa (the tool I use to manage domains) is encoded using utf8. I'm still stuck with this and I don't understand why yet... Antoine
Re: Question for socketmap_table
> Am 13.09.2016 um 17:11 schrieb Viktor Dukhovni : > > On Tue, Sep 13, 2016 at 05:00:01PM +0200, Christian Rößner wrote: > >>> They are. You just need to combine the postcreen_access_list >>> documentation with the socketmap encapsulation. >>> OK permit (or dunno) NOTFOUND TEMP What is done with this reason? >>> >>> It is up to the table-driven mechanism to report it as a warning >>> or to report it as a fatal error. >> >> The background to my question is that I already implemented a fully working >> tcp-map-driven service for postscreen and I just thought about switching >> it to socketmap, if socketmap would give me more choices for replying. >> But as I guess that "reject", "permit" and "dunno" are the only possible >> results, this switch seems useless. >> >> What I miss is something like "defer" >> >> Thanks anyways for helping me to understand this map. > > Don't confuse the socketmap layer protocol which can find, not find or > tempfail a lookup, with the Postfix syntax for the lookup result, which, > depending on context access(5), header_checks(5), ... > may begin with various keywords such as: > > OK > DUNNO > REJECT > DEFER > WARN > > or just some address or transport spec as with virtual(5) or transport(5). Yes I know. But the "map"-logic must be somehow interpreted by the calling option. So for tcp-map I found out that I need to send 200 dunno or 200 reject to get the wanted results from postscreen_access_list I looked for the same syntax in socketmap (knowing that it needs to be encoded). But at the end I can stay with tcp-map, as the postfix option in postscreen itself does not know more than the described responses. Is there some chance that postscreen could be extended to also have "defer"? If you use a dynamic service like tcp-map, decisions might be not black or white and therefor reject or dunno (or permit) might not be enough. I use postscreen with a tcp-map, as I can quickly decide just before asking remote DNS black lists. If I had a "defer" I might have some internal TTL like greylisting capability in a tcp-map-service. Thanks Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
Re: Question for socketmap_table
On Tue, Sep 13, 2016 at 05:40:09PM +0200, Christian Rößner wrote: > > Don't confuse the socketmap layer protocol which can find, not find or > > tempfail a lookup, with the Postfix syntax for the lookup result, which, > > depending on context access(5), header_checks(5), ... > > may begin with various keywords such as: > > > > OK > > DUNNO > > REJECT > > DEFER > > WARN > > > > or just some address or transport spec as with virtual(5) or transport(5). > > Yes I know. But the "map"-logic must be somehow interpreted by the calling > option. So for tcp-map I found out that I need to send > > 200 dunno > or > 200 reject > > to get the wanted results from postscreen_access_list > > I looked for the same syntax in socketmap (knowing that it needs to be > encoded). > > But at the end I can stay with tcp-map, as the postfix option in postscreen > itself does not know more than the described responses. > > Is there some chance that postscreen could be extended to also have "defer"? Clients that you're unwilling to block outright should probably be deferred by smtpd(8) and not postscreen(8). The latter is designed to reject botnet traffic from definitely illegitimate clients. Postscreen does not seem to at present support a blacklist 'defer' action. -- Viktor.
Re: mysql lookup table and utf8
On Tue, Sep 13, 2016 at 05:30:40PM +0200, Antoine Nguyen wrote: > Thank you for this link but, since it is a new setup, I have no data. I've > already checked mysql configuration : default character set is utf8, default > collation is utf8_general_ci and database and tables are using those values. > Also, it looks like the data inserted by Modoboa (the tool I use to manage > domains) is encoded using utf8. > > I'm still stuck with this and I don't understand why yet... Make sure your shell or terminal emulator is not mangling utf-8 input or command-line arguments. * Post your map.cf file content, perhaps that map file restricts which lookup keys are passed on to the underlying database. * Place the lookup key in a file. * Ensure that the file's content is correctly utf-8 encoded. * Run: postmap -v -q - mysql:... < input-file Repeat with various values of LANG. Note that Postfix applies MySQL string quoting to input arguments, and the MySQL client confgiration must somehow decide to use UTF-8 encoding for the query string. -- Viktor.
Re: Question for socketmap_table
Christian Ro??ner: > Is there some chance that postscreen could be extended to also have "defer"? That is a good question, but you might want to ask that in a thread that isn't about socketmaps. Wietse
Feature request for postscreen: "defer"
> Am 13.09.2016 um 18:09 schrieb Wietse Venema : > > Christian Ro??ner: >> Is there some chance that postscreen could be extended to also have "defer"? > > That is a good question, but you might want to ask that in a thread > that isn't about socketmaps. You are totally right. I created a new thread for this. The idea is to give postscreen a "defer" option. At connect time, dynamic services can work with the IP address of a connecting client. In some cases, this can result in whitelisting, blacklisting or no decision. But a fourth decision: "defer" might be interesting in cases, where the risk of a false-positive decision is too big. Having this in postscreen reduces load on external DNS queries, if you also use dnsblog. Thanks in advance Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
Re: Feature request for postscreen: "defer"
Christian Ro??ner: > > Am 13.09.2016 um 18:09 schrieb Wietse Venema : > > > > Christian Ro??ner: > >> Is there some chance that postscreen could be extended to also have > >> "defer"? > > > > That is a good question, but you might want to ask that in a thread > > that isn't about socketmaps. > > You are totally right. I created a new thread for this. > > The idea is to give postscreen a "defer" option. At connect time, > dynamic services can work with the IP address of a connecting > client. In some cases, this can result in whitelisting, blacklisting > or no decision. But a fourth decision: "defer" might be interesting > in cases, where the risk of a false-positive decision is too big. > > Having this in postscreen reduces load on external DNS queries, > if you also use dnsblog. Unlike DNS lookups, the access map lookup is a blocking operation, and if your tcp map takes 80ms to complete (a typical trans-atlantic query), then you can handle only 12 connections per second, and make postsceen the largest performance bottleneck on the system. Wietse
Complaints due to helo restrictions
Hello, We are running postfix v2.11.0 on CentOS 6.8 as a gateway server and we have recently imposed helo restrictions. Few servers have problems sending us mail due to the helo restrictions: Sep 8 09:35:37 mailgw1 postfix/smtpd[18791]: NOQUEUE: reject: RCPT from mail.ipta.demokritos.gr[143.233.230.2]: 450 4.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= We have notified them that their helo answer is different than their mail server name / FQDN (so as to change it) and they say that we should not be restricting access due to this: "The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. http://www.ietf.org/rfc/rfc1123.txt (section 5.2.5)" From your experience and knowledge: 1. How should we treat this issue? 2. How should we respond to the complaints? 3. If we are supposed to remove these restrictions, which settings should we remove from our config to resolve the problem? Should we remove all of: reject_unknown_helo_hostname, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname ? Here is our postconf -n: # postconf -n allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject allowed_list2 = check_client_access cidr:/etc/postfix/internalnetworks.cidr,reject command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 default_process_limit = 50 disable_vrfy_command = yes enable_long_queue_ids = yes html_directory = no inet_interfaces = all inet_protocols = ipv4, ipv6 local_recipient_maps = local_transport = error:local mail delivery is disabled mail_name = NOA Mail Srv XAPITI XPICTOY mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 15728640 mydestination = mynetworks = 127.0.0.1/32 [::1]/128 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_exceptions.cidr postscreen_blacklist_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2, psbl.surriel.com*2 postscreen_dnsbl_threshold = 2 postscreen_greet_action = enforce queue_directory = /var/spool/postfix relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr relay_recipient_maps = sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_helo_required = yes smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/amavis_bypass check_sender_access hash:/etc/postfix/blacklisted_senders reject_unverified_recipient reject_unauth_destination check_recipient_access hash:/etc/postfix/protected_destinations check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre permit_mynetworks reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unknown_helo_hostname reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_rbl_client b.barracudacentral.org reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service unix:postgrey/socket permit smtpd_restriction_classes = allowed_list1,allowed_list2 transport_maps = hash:/etc/postfix/transportmap unknown_local_recipient_reject_code = 550 unverified_sender_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtualmap Thanks in advance, Nick
Re: Complaints due to helo restrictions
On Tue, Sep 13, 2016 at 08:16:30PM +0300, Nikolaos Milas wrote: > We have notified them that their helo answer is different than their > mail server name / FQDN (so as to change it) and they say that we > should not be restricting access due to this: > > "The HELO receiver MAY verify that the HELO parameter really > corresponds to the IP address of the sender. However, the receiver > MUST NOT refuse to accept a message, even if the sender's HELO > command fails verification. http://www.ietf.org/rfc/rfc1123.txt > (section 5.2.5)" This applies to the mapping from (valid) name to IP. You must not refuse mails because of that. It however does not apply to the check if the name is actually valid. > 1. How should we treat this issue? You can get the same result easier by pulling the plug. reject_unknown_helo_hostname is an easy way to remove yourself from the mail universe. > # postconf -n > mail_name = NOA Mail Srv XAPITI XPICTOY Not good, as the string ESMTP is expected in it. > postscreen_dnsbl_action = enforce > postscreen_dnsbl_sites = b.barracudacentral.org*2, > zen.spamhaus.org*2, psbl.surriel.com*2 > postscreen_dnsbl_threshold = 2 Why do you use wheights if one RBL is again enough to reject? > smtpd_recipient_restrictions = check_client_access > hash:/etc/postfix/amavis_bypass check_sender_access > hash:/etc/postfix/blacklisted_senders reject_unverified_recipient > reject_unauth_destination check_recipient_access > hash:/etc/postfix/protected_destinations > check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre > permit_mynetworks reject_invalid_hostname reject_unauth_pipelining > reject_non_fqdn_sender reject_unknown_sender_domain > reject_non_fqdn_recipient reject_unknown_recipient_domain > reject_unknown_helo_hostname reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname reject_rbl_client > b.barracudacentral.org reject_rbl_client zen.spamhaus.org > reject_rbl_client psbl.surriel.com reject_rbl_client bl.spamcop.net > reject_rbl_client dnsbl.sorbs.net reject_rhsbl_client > dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org > reject_rhsbl_helo dbl.spamhaus.org check_policy_service > unix:postgrey/socket permit I'm not gonna decode this. There is a reason why the documentation is pretty clear on how to use postconf (aka use -nf) Bastian# -- Suffocating together ... would create heroic camaraderie. -- Khan Noonian Singh, "Space Seed", stardate 3142.8
Re: Complaints due to helo restrictions
On 9/13/2016 1:16 PM, Nikolaos Milas wrote: > Hello, > > We are running postfix v2.11.0 on CentOS 6.8 as a gateway server and > we have recently imposed helo restrictions. > > Few servers have problems sending us mail due to the helo restrictions: > > Sep 8 09:35:37 mailgw1 postfix/smtpd[18791]: NOQUEUE: reject: RCPT > from mail.ipta.demokritos.gr[143.233.230.2]: 450 4.7.1 > : Helo command rejected: Host not found; > from= to= proto=ESMTP > helo= > > We have notified them that their helo answer is different than their > mail server name / FQDN (so as to change it) and they say that we > should not be restricting access due to this: > > "The HELO receiver MAY verify that the HELO parameter really > corresponds to the IP address of the sender. However, the receiver > MUST NOT refuse to accept a message, even if the sender's HELO command > fails verification. http://www.ietf.org/rfc/rfc1123.txt (section 5.2.5)" > > From your experience and knowledge: > > 1. How should we treat this issue? > > 2. How should we respond to the complaints? > For myself this comes down to a question of how important is mail with this domain that can't properly configure their mail server to send a proper FQDN HELO as well as how much spam does rejecting based off invalid HELO hostnames. For myself looking at my logwatch reports for this month I reject about 15-33% of the messages for either HELO/EHLO, unknown user, recipient address, sender address or RBL each day. The HELO/EHLO rejection rate is between 1-13% of the total rejections and varies quite a bit from day to day. By far though most of my rejects come from RBLs. I also run messages through Amavis for content filtering before accepting into the queue at all and that tends to reject anywhere frmo 45-55% of the messages daily as well. > 3. If we are supposed to remove these restrictions, which settings > should we remove from our config to resolve the problem? Should we > remove all of: reject_unknown_helo_hostname, > reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname ? > I only have the following for my smtpd_*_restrictions: smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, check_policy_service unix:private/policyd-spf, permit smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_mx_access cidr:/etc/postfix/drop.cidr, check_sender_ns_access cidr:/etc/postfix/drop.cidr, check_sender_mx_access cidr:/etc/postfix/bogon_networks.cidr, check_sender_access pcre:/etc/postfix/sender_access, reject_rhsbl_sender dsn.rfc-ignorant.org, permit_sasl_authenticated, permit_mynetworks, permit > > Thanks in advance, > Nick > > smime.p7s Description: S/MIME Cryptographic Signature
Re: Complaints due to helo restrictions
Nikolaos Milas: > Sep 8 09:35:37 mailgw1 postfix/smtpd[18791]: NOQUEUE: reject: RCPT from > mail.ipta.demokritos.gr[143.233.230.2]: 450 4.7.1 : Helo > command rejected: Host not found; > from= to= proto=ESMTP > helo= I don't recommend using reject_unknown_helo_hostname, because there are many false positives. > 3. If we are supposed to remove these restrictions, which settings > should we remove from our config to resolve the problem? Should we > remove all of: reject_unknown_helo_hostname, > reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname ? I'd use none of these. reject_unknown_helo_hostname and reject_non_fqdn_helo_hostname have many false positives. It's for fanatics who receive very little email. reject_invalid_helo_hostname doesn't stop much because spambots have evolved. Wietse
Re: Message size limit responses
In een bericht van 13-9-2016 15:55: Usually the sender will disconnect when they see your SIZE banner, so you never have an opportunity to send them anything. All you'll see in your logs is a connect/disconnect. With Thunderbird I sometimes do see a message that attachments are oversized. Who is generating this message? Thought it might be postfix? /Jos
postscreen-policy (was: Feature request for postscreen: "defer")
Wietse Venema: > Unlike DNS lookups, the access map lookup is a blocking operation, > and if your tcp map takes 80ms to complete (a typical trans-atlantic > query), then you can handle only 12 connections per second, and > make postsceen the largest performance bottleneck on the system. After starting work on postscreen by the middle of 2009, I soon realized that I might have to add some postscreen-policy interface for things that are too complex or that take too much time compared to a quick access map lookup. Perhaps the time has come. Basically this would be a very small subset of the SMTP server policy protocol with just the network 5-tuple (source/destination address/port, protocol, client concurrency), enough to do some simple reputation work. Perhaps it also makes sense for postscreen to make a postscreen-policy call based on the information that it has collected with its dummy SMTP engine. Wietse
Re: postscreen-policy (was: Feature request for postscreen: "defer")
* Wietse Venema : > Wietse Venema: > > Unlike DNS lookups, the access map lookup is a blocking operation, > > and if your tcp map takes 80ms to complete (a typical trans-atlantic > > query), then you can handle only 12 connections per second, and > > make postsceen the largest performance bottleneck on the system. > > After starting work on postscreen by the middle of 2009, I soon > realized that I might have to add some postscreen-policy interface > for things that are too complex or that take too much time compared > to a quick access map lookup. Perhaps the time has come. > > Basically this would be a very small subset of the SMTP server > policy protocol with just the network 5-tuple (source/destination > address/port, protocol, client concurrency), enough to do some > simple reputation work. > > Perhaps it also makes sense for postscreen to make a postscreen-policy > call based on the information that it has collected with its dummy > SMTP engine. That's great news! The reason Christian is using tcp tables is that there's no postscreen API to call external policy services at the moment. If there was he/we would be eager to use that instead. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: mysql lookup table and utf8
On 13/09/2016 18:08, Viktor Dukhovni wrote: Make sure your shell or terminal emulator is not mangling utf-8 input or command-line arguments. * Post your map.cf file content, perhaps that map file restricts which lookup keys are passed on to the underlying database. * Place the lookup key in a file. * Ensure that the file's content is correctly utf-8 encoded. * Run: postmap -v -q - mysql:... < input-file Repeat with various values of LANG. Note that Postfix applies MySQL string quoting to input arguments, and the MySQL client confgiration must somehow decide to use UTF-8 encoding for the query string. The map.cf file content is the following : user = modoboa password = password dbname = modoboa hosts = 127.0.0.1 query = SELECT name FROM admin_domain WHERE name='%s' AND type='domain' AND enabled=1 I've tried the different steps you proposed and unfortunately, it is not better: $ echo raté.com > test $ file test test: UTF-8 Unicode text $ postmap -v -q - mysql:/etc/postfix/sql-domains.cf < test postmap: name_mask: ipv4 postmap: inet_addr_local: configured 3 IPv4 addresses postmap: cfg_get_str: /etc/postfix/sql-domains.cf: user = modoboa postmap: cfg_get_str: /etc/postfix/sql-domains.cf: password = modoboa postmap: cfg_get_str: /etc/postfix/sql-domains.cf: dbname = modoboa postmap: cfg_get_str: /etc/postfix/sql-domains.cf: result_format = %s postmap: cfg_get_str: /etc/postfix/sql-domains.cf: option_file = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: option_group = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: tls_key_file = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: tls_cert_file = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: tls_CAfile = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: tls_CApath = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: tls_ciphers = postmap: cfg_get_bool: /etc/postfix/sql-domains.cf: tls_verify_cert = on postmap: cfg_get_int: /etc/postfix/sql-domains.cf: expansion_limit = 0 postmap: cfg_get_str: /etc/postfix/sql-domains.cf: query = SELECT name FROM admin_domain WHERE name='%s' AND type='domain' AND enabled=1 postmap: cfg_get_str: /etc/postfix/sql-domains.cf: domain = postmap: cfg_get_str: /etc/postfix/sql-domains.cf: hosts = 127.0.0.1 postmap: dict_open: mysql:/etc/postfix/sql-domains.cf postmap: dict_mysql_get_active: attempting to connect to host 127.0.0.1 postmap: dict_mysql: successful connection to host 127.0.0.1 postmap: dict_mysql: successful query from host 127.0.0.1 postmap: dict_mysql_lookup: retrieved 0 rows The result is always the same even if I change LANG (tried C and en_US.UTF-8). Antoine
Re: postscreen-policy (was: Feature request for postscreen: "defer")
Patrick Ben Koetter: > * Wietse Venema : > > Wietse Venema: > > > Unlike DNS lookups, the access map lookup is a blocking operation, > > > and if your tcp map takes 80ms to complete (a typical trans-atlantic > > > query), then you can handle only 12 connections per second, and > > > make postsceen the largest performance bottleneck on the system. > > > > After starting work on postscreen by the middle of 2009, I soon > > realized that I might have to add some postscreen-policy interface > > for things that are too complex or that take too much time compared > > to a quick access map lookup. Perhaps the time has come. > > > > Basically this would be a very small subset of the SMTP server > > policy protocol with just the network 5-tuple (source/destination > > address/port, protocol, client concurrency), enough to do some > > simple reputation work. > > > > Perhaps it also makes sense for postscreen to make a postscreen-policy > > call based on the information that it has collected with its dummy > > SMTP engine. > > That's great news! The reason Christian is using tcp tables is that there's no > postscreen API to call external policy services at the moment. If there was > he/we would be eager to use that instead. Yes, I wanted the discussion to end on an optimistic note. Something to work on in the train. Wietse
Re: postscreen-policy
On 13/09/16 20:01, Wietse Venema wrote: > Wietse Venema: >> Unlike DNS lookups, the access map lookup is a blocking operation, >> and if your tcp map takes 80ms to complete (a typical trans-atlantic >> query), then you can handle only 12 connections per second, and >> make postsceen the largest performance bottleneck on the system. > After starting work on postscreen by the middle of 2009, I soon > realized that I might have to add some postscreen-policy interface > for things that are too complex or that take too much time compared > to a quick access map lookup. Perhaps the time has come. From a slightly different angle, I would like to see some sort of "probationary" status, where the temporary whitelist is not activated. I frequently receive a well-behaved connection, earning PASS NEW, immediately followed by abusive behaviour (see the log extract below). In this instance, my fail-2-ban lookalike kicked in, and blocked several thousand packets, before the IPTABLES counters were reset. The zz.countries.nerd.dk entry tells me the host was located in China - a spam hot-spot for me. (One demerit point, but not enough to blacklist) Allen C Sep 13 15:23:14 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:2600 to [192.168.150.12]:25 Sep 13 15:23:14 geronimo postfix/dnsblog[9769]: addr 202.106.74.102 listed by domain zz.countries.nerd.dk as 127.0.0.156 Sep 13 15:23:20 geronimo postfix/postscreen[9767]: PASS NEW [202.106.74.102]:2600 Sep 13 15:23:21 geronimo postfix/smtpd[9777]: connect from unknown[202.106.74.102] Sep 13 15:23:24 geronimo postfix/smtpd[9777]: disconnect from unknown[202.106.74.102] ehlo=1 quit=1 commands=2 Sep 13 15:23:27 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:4225 to [192.168.150.12]:25 Sep 13 15:23:29 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:1202 to [192.168.150.12]:25 Sep 13 15:23:31 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:2070 to [192.168.150.12]:25 Sep 13 15:23:31 geronimo postfix/postscreen[9767]: NOQUEUE: reject: CONNECT from [202.106.74.102]:2070: too many connections Sep 13 15:23:31 geronimo postfix/postscreen[9767]: DISCONNECT [202.106.74.102]:2070 Sep 13 15:23:33 geronimo postfix/postscreen[9767]: PASS OLD [202.106.74.102]:4225 Sep 13 15:23:33 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:2478 to [192.168.150.12]:25 Sep 13 15:23:33 geronimo postfix/postscreen[9767]: NOQUEUE: reject: CONNECT from [202.106.74.102]:2478: too many connections Sep 13 15:23:33 geronimo postfix/postscreen[9767]: DISCONNECT [202.106.74.102]:2478 Sep 13 15:23:33 geronimo postfix/smtpd[9777]: connect from unknown[202.106.74.102] Sep 13 15:23:34 geronimo postfix/postscreen[9767]: CONNECT from [202.106.74.102]:1393 to [192.168.150.12]:25 Sep 13 15:23:34 geronimo postfix/postscreen[9767]: PASS OLD [202.106.74.102]:1393 Sep 13 15:23:34 geronimo postfix/smtpd[9786]: connect from unknown[202.106.74.102] Sep 13 15:23:35 geronimo postfix/postscreen[9767]: PASS OLD [202.106.74.102]:1202 Sep 13 15:23:35 geronimo postfix/smtpd[9788]: connect from unknown[202.106.74.102] Sep 13 15:23:35 geronimo postfix/smtpd[9788]: warning: Connection concurrency limit exceeded: 3 from unknown[202.106.74.102] for service smtpd Sep 13 15:23:35 geronimo postfix/smtpd[9788]: disconnect from unknown[202.106.74.102] commands=0/0 .. Etc, etc, until the IP address is blocked.
Concurrency limit for port 25
Not wanting to hijack the thread from Alan Coates, but I noticed the concurrency limit of three, which I assume was on port 25. Is there some science behind how to set this limit?
Re: Concurrency limit for port 25
I am a little guy; one connection an hour and I am *BUSY* Three concurrent connections is more than I will ever need. The limit is set low to fend off D-o-S attacks like the one I described. By-and-large, default values are set to a reasonable value for a wide range of circumstances. However, I felt in my case, there was a special need to change it. I would not advocate frivolously changing a default value *before* it has proved to be unsatisfactory. Hope this helps. Allen C On 13/09/16 23:40, li...@lazygranch.com wrote: > Not wanting to hijack the thread from Alan Coates, but I noticed the > concurrency limit of three, which I assume was on port 25. Is there some > science behind how to set this limit? > >
Re: mysql lookup table and utf8
On Tue, Sep 13, 2016 at 09:52:16PM +0200, Antoine Nguyen wrote: > query = SELECT name FROM admin_domain WHERE name='%s' AND type='domain' AND > enabled=1 What is not clear is how MySQL's quoting behaves given the input UTF-8 string. > postmap: cfg_get_str: /etc/postfix/sql-domains.cf: query = SELECT name FROM > admin_domain WHERE name='%s' AND type='domain' AND enabled=1 > > postmap: dict_mysql: successful query from host 127.0.0.1 > > postmap: dict_mysql_lookup: retrieved 0 rows I was hoping to see the expanded query string, but it is not output with "-v". Perhaps there's some sort of logging you can enable in the MySQL server or client libraries. Do make sure that your tests with the sql CLI really make the same query against the same database: SELECT name FROM admin_domain WHERE name='' AND type='domain' AND enabled=1 -- Viktor.
Re: Message size limit responses
On 13 Sep 2016, at 14:10, JosC wrote: In een bericht van 13-9-2016 15:55: Usually the sender will disconnect when they see your SIZE banner, so you never have an opportunity to send them anything. All you'll see in your logs is a connect/disconnect. With Thunderbird I sometimes do see a message that attachments are oversized. Who is generating this message? Thought it might be postfix? By "message" do you mean an actual piece of email reporting the problem or a notification in the Thunderbird user interface? Email messages reporting a delivery failure are almost always generated by some MTA, e.g. Postfix. There's a standard format for such failure report messages that most MTAs use which includes an explicit "Reporting-MTA" field identifying the generator of the report. A "message" from the TBird UI (i.e. an alert window or error message in a status area of the main widow, etc.) is almost certainly generated by TBird itself. The first step in submitting a message is the MUA (TBird) saying "EHLO " to the MSA/MTA (Postfix) and getting a response listing the supported extensions to SMTP supported by that server. Example: $ telnet localhost 587 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 toaster.scconsult.com ESMTP Postfix EHLO localhost 250-toaster.scconsult.com 250-PIPELINING 250-SIZE 4096 250-ETRN 250-STARTTLS 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 quit 221 2.0.0 Bye Connection closed by foreign host. All of the lines starting with a 3-digit number are coming from Postfix. The line "250-SIZE 4096" tells the client that the server is willing to consider accepting a 40MB message, because I have "message_size_limit = 4096" in my main.cf. A well-designed MUA will parse the EHLO response for a "SIZE" line and if the declared size is smaller than the message it wants to send, simply send a 'quit' and tell the user that their message was too big. If a message is rejected later by a policy server or milter that imposes more complex rules regarding message size, the client should pass back to the user whatever rejection reply Postfix passed along from that external program. For example, I use code run via the MIMEDefang milter to impose smaller limits on some sender/recipient combinations which can reply with text saying the message is too large. In that case, Postfix is sending an explicit rejection response to the client and it is up to the client to relay that back to the user.
Re: Feature request for postscreen: "defer"
> Am 13.09.2016 um 19:00 schrieb Wietse Venema : > > Christian Ro??ner: >>> Am 13.09.2016 um 18:09 schrieb Wietse Venema : >>> >>> Christian Ro??ner: Is there some chance that postscreen could be extended to also have "defer"? >>> >>> That is a good question, but you might want to ask that in a thread >>> that isn't about socketmaps. >> >> You are totally right. I created a new thread for this. >> >> The idea is to give postscreen a "defer" option. At connect time, >> dynamic services can work with the IP address of a connecting >> client. In some cases, this can result in whitelisting, blacklisting >> or no decision. But a fourth decision: "defer" might be interesting >> in cases, where the risk of a false-positive decision is too big. >> >> Having this in postscreen reduces load on external DNS queries, >> if you also use dnsblog. > > Unlike DNS lookups, the access map lookup is a blocking operation, > and if your tcp map takes 80ms to complete (a typical trans-atlantic > query), then you can handle only 12 connections per second, and > make postsceen the largest performance bottleneck on the system. Good point. I will think about moving the tcp-map to "smtpd". Thank you very much for clarifying the performance impact Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
Re: Feature request for postscreen: "defer"
> Am 14.09.2016 um 07:50 schrieb Christian Rößner > : > >> Am 13.09.2016 um 19:00 schrieb Wietse Venema : >> >> Christian Ro??ner: Am 13.09.2016 um 18:09 schrieb Wietse Venema : Christian Ro??ner: > Is there some chance that postscreen could be extended to also have > "defer"? That is a good question, but you might want to ask that in a thread that isn't about socketmaps. >>> >>> You are totally right. I created a new thread for this. >>> >>> The idea is to give postscreen a "defer" option. At connect time, >>> dynamic services can work with the IP address of a connecting >>> client. In some cases, this can result in whitelisting, blacklisting >>> or no decision. But a fourth decision: "defer" might be interesting >>> in cases, where the risk of a false-positive decision is too big. >>> >>> Having this in postscreen reduces load on external DNS queries, >>> if you also use dnsblog. >> >> Unlike DNS lookups, the access map lookup is a blocking operation, >> and if your tcp map takes 80ms to complete (a typical trans-atlantic >> query), then you can handle only 12 connections per second, and >> make postsceen the largest performance bottleneck on the system. > > Good point. I will think about moving the tcp-map to "smtpd". > > Thank you very much for clarifying the performance impact Ah... Just read about the postscreen-policy idea. :-) -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com smime.p7s Description: S/MIME cryptographic signature
