Re: Blocking "unknown"
On Fri, 30 Sep 2016 06:26:35 -0400 Postfix User wrote: > Postfix-3.2-20160917 with FreeBSD-11.0 /64 bit > > Lately, I have been finding the following entries in the maillog: > > 13643:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: warning: hostname > ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.251.67: > hostname nor servname provided, or not known 13822:Sep 30 02:00:40 > scorpio postfix/smtpd[83056]: connect from unknown[118.71.251.67] > 13904:Sep 30 02:00:41 scorpio postfix/smtpd[83056]: disconnect from > unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3 This will pull these hackers off your maillog. bzgrep -e auth=0/1 maillog* | sed 's/.*\[\([^]]*\)\].*/\1/g' >iplist sort iplist | uniq I'm going to wait a bit regarding automatically rejecting these attempts per the method listed in the rest of the thread, but I'd like to hear a follow up. FWIW, I took the list of shady IP addresses and made a table for ipfw for the ones I'm pretty sure I can block.
Re: Blocking "unknown"
On 30.09.16 15:14, /dev/rob0 wrote: > I think it's reasonable now to expect a legitimate SMTP client to > have a PTR record, and perhaps in the not-too-distant future to > expect PTR/A matching. Based on personal experience, I stand by my recommendation to not reject e-mail based on the absence of a reverse DNS entry alone. It is easy enough to increase spam scores if you so desire, but flat out rejecting mail is is not something I would do. -Ralph
Re: Blocking "unknown"
Hi, On Fri, Sep 30, 2016 at 9:14 AM, /dev/rob0 wrote: > On Fri, Sep 30, 2016 at 01:02:34PM +0200, Ralph Seichter wrote: >> On 30.09.2016 12:26, Postfix User wrote: >> >> > 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: >> > connect from unknown[118.71.251.67] >> >> You can use reject_unknown_reverse_client_hostname, but I recommend >> you don't. Many legitimate mail sources have not configured reverse >> DNS entries. > > Hmm, I have been using this for many years, since one time when my > own PTR lookup failed and I found I was being rejected by gmail and > numerous other providers. I'd like to now add this as well. Would you recommend adding it after reject_unauth_destination? smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, reject_unlisted_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, reject_unknown_reverse_client_hostname, reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net, reject_rhsbl_sender mykey.dbl.dq.spamhaus.net, reject_rhsbl_helo mykey.dbl.dq.spamhaus.net check_sender_access hash:/etc/postfix/check_backscatterer, check_helo_access pcre:/etc/postfix/helo_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_policy_service unix:private/policy-spf, check_policy_service inet:127.0.0.1:2501, check_recipient_access pcre:/etc/postfix/relay_recips_access, check_recipient_access pcre:/etc/postfix/recipient_checks, permit smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/client_checks, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns-042715a.pcre, check_reverse_client_hostname_access pcre:/etc/postfix/reverse_client_hostname_access.pcre, check_client_access cidr:/etc/postfix/client_access_blocklist smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/sender_checks, check_sender_access hash:/etc/postfix/spamsources, check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf, reject_unknown_sender_domain Thanks, Alex
Re: WoSign/StartCom CA in the news
Yes, I understand DANE can be used for MTAs. My musing is could it completely replace the existing CA mess, and I suppose the follow up is how? On September 30, 2016 09:12:30 wie...@porcupine.org (Wietse Venema) wrote: John: This may be way off topic, if I apologise. Looking a the available CAs many of them do not seem to pass the /s//niff test//./ WoSign/Startcom are not alone in being found to be either incompetent or dishonest. Which made me wonder if there might be an alternative to CA issued certs. Is there anyway that DNS/DNSSEC could be used to publish and verify certs. DANE can be used to implement TLS authentication without PKI. Available in Postfix since 2.11. Wietse
Re: Blocking "unknown"
On Fri, Sep 30, 2016 at 06:26:35AM -0400, Postfix User wrote: > Postfix-3.2-20160917 with FreeBSD-11.0 /64 bit > > Lately, I have been finding the following entries in the maillog: > > 13643:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: warning: > hostname ip-address-pool-xxx.fpt.vn does not resolve to address > 118.71.251.67: hostname nor servname provided, or not known > 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: connect from > unknown[118.71.251.67] > 13904:Sep 30 02:00:41 scorpio postfix/smtpd[83056]: disconnect from > unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3 > > While the IP, etcetera will change, the basic message is the same. > I thought I had postfix configured to block attempts like this. It IS blocked. It disconnected after EHLO. We don't know why the client was unable to continue; the SMTP protocol does not provide a means for the client to tell the server what it didn't like. > Obviously not though. My config file is below. What am I missing? > > ~ $ postconf -nf You did not show "postconf -Mf". Is there a " -o syslog_name=..." setting for submission? If not there should be. It would be of interest to know whether this one was on port 25 or 587. > broken_sasl_auth_clients = yes why? In 2016 that's much like taping a "KICK ME" sign on your back and walking blindfolded around a schoolyard. You will get kicked. The Microsoft mail clients from that era have been unmaintained for many years now, and they are the darlings of the malware purveyors. > enable_long_queue_ids = yes Very good. :) This is one of my pet projects: to try to get more adoption of long queue IDs. I think it's quite appropriate since the last version without it is almost 2 years past EOL now. (Wietse, any thoughts on making this the default, at least for new installs? Perhaps "make upgrade" could put in a "no" setting if enable_long_queue_ids is not found in main.cf?) > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated > permit_tls_clientcerts reject_unknown_client_hostname > reject_unauth_destination I don't have this in main.cf, I have it as mua_relay_restrictions and used as an override on submission only. And you probably do not want reject_unknown_client_hostname here, because that demands PTR/A matching, whereas many submitting clients will have no PTR at all, or PTR/A mismatch. > smtpd_sasl_auth_enable = yes This, likewise, I'd only enable on submission. You should not accept nor offer AUTH on port 25. * * * All that said, your relay restrictions would have rejected that client if it had proceeded all the way to RCPT TO. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Blocking "unknown"
On Fri, Sep 30, 2016 at 01:02:34PM +0200, Ralph Seichter wrote: > On 30.09.2016 12:26, Postfix User wrote: > > > 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: > > connect from unknown[118.71.251.67] > > You can use reject_unknown_reverse_client_hostname, but I recommend > you don't. Many legitimate mail sources have not configured reverse > DNS entries. Hmm, I have been using this for many years, since one time when my own PTR lookup failed and I found I was being rejected by gmail and numerous other providers. I admit I am not watching the logs, but likewise I have not had any complaints from users in this time. I think it's reasonable now to expect a legitimate SMTP client to have a PTR record, and perhaps in the not-too-distant future to expect PTR/A matching. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: WoSign/StartCom CA in the news
John: > This may be way off topic, if I apologise. > > Looking a the available CAs many of them do not seem to pass the > /s//niff test//./ WoSign/Startcom are not alone in being found to be > either incompetent or dishonest. Which made me wonder if there might be > an alternative to CA issued certs. Is there anyway that DNS/DNSSEC could > be used to publish and verify certs. DANE can be used to implement TLS authentication without PKI. Available in Postfix since 2.11. Wietse
Re: WoSign/StartCom CA in the news
On Fri, Sep 30, 2016 at 08:36:58AM -0400, John wrote: > This may be way off topic, if I apologise. Not really, not much anyway. > Looking a the available CAs many of them do not seem to pass the > /s//niff test//./ WoSign/Startcom are not alone in being found to > be either incompetent or dishonest. Which made me wonder if there > might be an alternative to CA issued certs. Is there anyway that > DNS/DNSSEC could be used to publish and verify certs. It's called DANE, see RFC 6698 and Victor's post earlier in this thread. To understand this you need to understand the different roles a Postfix MTA might serve. DANE is for MTA-to-MTA mail exchange. WebPKI (commercial or free) certs are more useful for user-to-MTA (MSA) submission. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: WoSign/StartCom CA in the news
This may be way off topic, if I apologise. Looking a the available CAs many of them do not seem to pass the /s//niff test//./ WoSign/Startcom are not alone in being found to be either incompetent or dishonest. Which made me wonder if there might be an alternative to CA issued certs. Is there anyway that DNS/DNSSEC could be used to publish and verify certs. JohnA // On 27/09/16 06:29 PM, Viktor Dukhovni wrote: WoSign (who seemingly purchased StartCom) seem to have run into some compliance issues as reported by Firefox: http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/ Many SMTP servers are using certs from StartCom. In my DANE adoption survey, out of 2201 certificates used by DANE MX hosts 411 are issued by StartCom and 47 by WoSign. So that's just over 20% of observed certificates. While the rate is likely different for the larger SMTP ecosystem (DANE users are bleeding edge, not representative at this time), I expect that these CAs are still quite popular overall. If you're using StartCom/WoSign certs, and rely on them being verified by MUAs and/or peer MTAs. you may want to make contingency plans if Mozilla and perhaps others go through with delisting (or disabling) the related root CAs from their trusted CA bundles.
Re: Blocking "unknown"
On 30/09/16 11:26, Postfix User wrote: > Lately, I have been finding the following entries in the maillog: > > 13643:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: warning: hostname > ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.251.67: > hostname nor servname provided, or not known > 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: connect from > unknown[118.71.251.67] > 13904:Sep 30 02:00:41 scorpio postfix/smtpd[83056]: disconnect from > unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3 I notice that the last line of the log contains "auth=0/1" As I understand it, this indicates the remote is probing for username/password pairs. It may be a good idea to sweep the log for that pattern and add the offending IP address to some sort of local blacklist. What do others think? Allen C
Re: Blocking "unknown"
On 30.09.2016 12:26, Postfix User wrote: > 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: > connect from unknown[118.71.251.67] You can use reject_unknown_reverse_client_hostname, but I recommend you don't. Many legitimate mail sources have not configured reverse DNS entries. -Ralph
Blocking "unknown"
Postfix-3.2-20160917 with FreeBSD-11.0 /64 bit Lately, I have been finding the following entries in the maillog: 13643:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: warning: hostname ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.251.67: hostname nor servname provided, or not known 13822:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: connect from unknown[118.71.251.67] 13904:Sep 30 02:00:41 scorpio postfix/smtpd[83056]: disconnect from unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3 While the IP, etcetera will change, the basic message is the same. I thought I had postfix configured to block attempts like this. Obviously not though. My config file is below. What am I missing? ~ $ postconf -nf alias_maps = lmdb:/usr/local/etc/postfix/aliases authorized_submit_users = !www, static:all broken_sasl_auth_clients = yes canonical_maps = lmdb:/usr/local/etc/postfix/canonical command_directory = /usr/local/sbin compatibility_level = 2 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 default_database_type = lmdb disable_vrfy_command = yes dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes html_directory = /usr/local/share/doc/postfix inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/local/libexec/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT" mailbox_size_limit = 0 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man message_size_limit = 3000 meta_directory = /usr/local/libexec/postfix milter_default_action = accept msa_tls_ciphers = medium msa_tls_dh1024_param_file = /usr/local/etc/postfix/ssl/DHparams/dh2048.pem msa_tls_exclude_ciphers = MD5, RC4, 3DES msa_tls_protocols = !SSLv2, !SSLv3 mydestination = mydomain = seibercom.net myhostname = scorpio.seibercom.net mynetworks = lmdb:/usr/local/etc/postfix/my-networks mynetworks_style = host myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix sample_directory = /usr/local/etc/postfix sender_dependent_relayhost_maps = lmdb:/usr/local/etc/postfix/sender_relay sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop shlib_directory = /usr/local/lib/postfix smtp_sasl_auth_enable = yes smtp_sasl_password_maps = lmdb:/usr/local/etc/postfix/sasl_passwd smtp_sasl_security_options = noplaintext, noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sender_dependent_authentication = yes smtp_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtp_tls_ciphers = medium smtp_tls_exclude_ciphers = MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5, aNULL smtp_tls_loglevel = 1 smtp_tls_mandatory_ciphers = medium smtp_tls_mandatory_exclude_ciphers = RC4, MD5 smtp_tls_note_starttls_offer = yes smtp_tls_protocols = !SSLv2 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_tls_session_cache smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_reject_footer = For assistance, please provide the following information in your problem report: time ($localtime), client ($client_address) and server ($server_name). smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated permit_tls_clientcerts reject_unknown_client_hostname reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /usr/local/etc/postfix/certs/postfix-cert.pem smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/ssl/DHparams/dh2048.pem smtpd_tls_dh512_param_file = /usr/local/etc/postfix/ssl/DHparams/dh512.pem smtpd_tls_key_file = /usr/local/etc/postfix/certs/postfix-key.pem smtpd_tls_loglevel = 1 smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom transport_maps = lmdb:/usr/local/etc/postfix/transport_maps unknown_local_recipient_reject_code = 550 virtual_alias_maps = lmdb:/usr/local/etc/postfix/virtual_alias virtual_gid_maps = static:1002 virtual_mailbox_base = /var/mail/vmail/ virtual_mailbox_domains = seibercom.net stemnc.org virtual_mailbox_maps = lmdb:/usr/local/etc/postfix/vmailbox virtual_minimum_uid = 100 virtual_transport = dovecot virtual_uid_maps = static:1002
Re: can't connect/send to postfix
Hi, looks like your mysql table for mysql-virtual-alias-maps.cf is not, what postfix expects: Am 30.09.2016 um 09:27 schrieb patg: > Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: mysql query failed: > Unknown column 'address' in 'where clause' > Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: > mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for > "t...@domain.com" > Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: B8077376081C: > virtual_alias_maps map lookup problem for t...@domain.com -- message not > accepted, try again later --- If mysql table lookups work, look, if you still have problems with amavis and come back if necessary. > Sep 30 09:01:06 mail postfix/cleanup[8397]: warning: > mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for > "ama...@domain.com" Willi
can't connect/send to postfix
Hello,
i try to use postfix with some others tools (amavis, spamassassin,
dovecot...), but i can't send mail message to server(1.80) from an other
computer (1.50). i use the smtp (25) port (but i want use 25 or 587
ports), for the tests i want to use only 25.
i used this tutorial : https://mondedie.fr/viewtopic.php?id=5750
but when i want to send a message trought the server, i have errors "Le
serveur SMTP ne supporte pas l'authentification
" (SMTP server doesn't support authentication) :
Sep 30 08:59:51 mail postfix/smtpd[8605]: connect from unknown[192.168.1.50]
Sep 30 08:59:51 mail postfix/smtpd[8605]: Anonymous TLS connection
established from unknown[192.168.1.50]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Sep 30 08:59:53 mail postfix/smtpd[8605]: lost connection after EHLO
from unknown[192.168.1.50]
Sep 30 08:59:53 mail postfix/smtpd[8605]: disconnect from
unknown[192.168.1.50]
Sep 30 09:00:06 mail postfix/pickup[8346]: warning: B8077376081C:
message has been queued for 1 days
Sep 30 09:00:06 mail postfix/pickup[8346]: B8077376081C: uid=0 from=
Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: mysql query failed:
Unknown column 'address' in 'where clause'
Sep 30 09:00:06 mail postfix/cleanup[8397]: warning:
mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for
"t...@domain.com"
Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: B8077376081C:
virtual_alias_maps map lookup problem for t...@domain.com -- message not
accepted, try again later
i ve others errors which seems linked to amavis :
Sep 30 09:00:06 mail postfix/pickup[8346]: warning: D626E376081C:
message has been queued for 2 days
Sep 30 09:00:06 mail postfix/pickup[8346]: D626E376081C: uid=113
from=
Sep 30 09:00:06 mail postfix/cleanup[8397]: warning:
mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for
"ama...@domain.com"
Sep 30 09:00:06 mail postfix/cleanup[8397]: warning: D626E376081C:
virtual_alias_maps map lookup problem for ama...@domain.com -- message
not accepted, try again later
Sep 30 09:01:06 mail postfix/pickup[8346]: warning: 743A9376081C:
message has been queued for 1 days
Sep 30 09:01:06 mail postfix/pickup[8346]: 743A9376081C: uid=0 from=
Sep 30 09:01:06 mail postfix/cleanup[8397]: warning:
mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for
"t...@domain.com"
Sep 30 09:01:06 mail postfix/cleanup[8397]: warning: 743A9376081C:
virtual_alias_maps map lookup problem for t...@domain.com -- message not
accepted, try again later
Sep 30 09:01:06 mail postfix/pickup[8346]: warning: 92592376081C:
message has been queued for 2 days
Sep 30 09:01:06 mail postfix/pickup[8346]: 92592376081C: uid=113
from=
Sep 30 09:01:06 mail postfix/cleanup[8397]: warning:
mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for
"ama...@domain.com"
Sep 30 09:01:06 mail postfix/cleanup[8397]: warning: 92592376081C:
virtual_alias_maps map lookup problem for ama...@domain.com -- message
not accepted, try again later
Sep 30 09:02:06 mail postfix/pickup[8346]: warning: D5CA0376081C:
message has been queued for 1 days
Sep 30 09:02:06 mail postfix/pickup[8346]: D5CA0376081C: uid=0 from=
Sep 30 09:02:06 mail postfix/cleanup[8397]: warning: mysql query failed:
Unknown column 'address' in 'where clause'
Sep 30 09:02:06 mail postfix/cleanup[8397]: warning:
mysql:/etc/postfix/mysql-virtual-alias-maps.cf lookup error for
"t...@domain.com"
Sep 30 09:02:06 mail postfix/cleanup[8397]: warning: D5CA0376081C:
virtual_alias_maps map lookup problem for t...@domain.com -- message not
accepted, try again later
# mysql-sender-login-maps.cf :
hosts = 127.0.0.1
user = postfix
password =
dbname = postfix
query = SELECT username FROM mailbox WHERE username='%s' AND active = 1
# mysql-virtual-alias-maps.cf
hosts = 127.0.0.1
user = postfix
password =
dbname = postfix
query = SELECT destination FROM alias WHERE address='%s' AND active = 1
# mysql-virtual-mailbox-domains.cf
hosts = 127.0.0.1
user = postfix
password =
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' and backupmx = 0 and
active = 1
# mysql-virtual-mailbox-maps.cf
hosts = 127.0.0.1
user = postfix
password =
dbname = postfix
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = 1
# in master.cf :
smtp inet n - - - - smtpd
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_dh1024_param_file=${config_directory}/dh2048.pem
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps inet n - n - - smtpd -o
smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
587 inet n - n - - smtpd -o
smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
# in main.cf :
smtpd_use_tls=yes
smtpd_relay_restrict
