Re: Stucked with "unable to look up host"
On 10 Feb 2021, at 04:13, Matus UHLAR - fantomas wrote: > On 09.02.21 14:22, @lbutlr wrote: >> But yes, each admin needs to look at their logs and see who >> is still using encryption they should not be using (especially since this >> probably indicates they have not updated the ssl libraries and are going >> to be open to any flaws/attacks/CVEs discovered since TLSv1 and TLSv1.1 >> were EOLed, making them less-trustworthy in general. > still more trustworthy than no encryption at all That is one way of looking at it, yes. Another way of looking at it is that a server that hasn't updated their cryptography libraries in nearly a year is not a trustworthy source of mail. There's not a single answer. (I haven't dropped TLSv1/1.1 yet, but I am checking the logs over the next week or so and probably will if I continue to see only spammers suing it.) -- 'In the Fyres of Struggle let us bake New Men, who Will Notte heed the old Lies.'
Re: Stucked with "unable to look up host"
On 09 Feb 2021, at 04:23, Dominic Raferd wrote: This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 - including the postfix-users list servers. Of course they would probably downgrade to plaintext if required, but that would reduce security. On 09/02/2021 12:36, @lbutlr wrote: That is odd. My mails from the postfix list server are using TLSv1.2. Are you sure the postfix list is using end-of-life encryption?... On 09 Feb 2021, at 06:21, Dominic Raferd wrote: It depends how far back one's logs go! Now I look just at my logs for this calendar year I see you are right. But there are still a few other 'good' senders using TLSv1 or TLSv1.1, even if they shouldn't be. Not 'plenty', I admit... On 09.02.21 14:22, @lbutlr wrote: Ah, I am only looking at recent logs. I don't see how moths-ago behavior is relevant. But yes, each admin needs to look at their logs and see who is still using encryption they should not be using (especially since this probably indicates they have not updated the ssl libraries and are going to be open to any flaws/attacks/CVEs discovered since TLSv1 and TLSv1.1 were EOLed, making them less-trustworthy in general. still more trustworthy than no encryption at all, as was multiple times mentioned here. https://marc.info/?l=postfix-users=143884497605106=2 https://marc.info/?l=postfix-users=152907910501143=2 https://marc.info/?l=postfix-users=158344470515844=2 and, of course: https://tools.ietf.org/html/rfc7435#section-1.2 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: Stucked with "unable to look up host"
On 09 Feb 2021, at 04:20, Doug Hardie wrote: > > Cc: Postfix users > To: "@lbutlr" Please do not do this. I am subscribed to the list. I will see your message on the list. -- 'I thought dwarfs didn't believe in devils and demons and stuff like that.' 'That's true, but... we're not sure if they know.'
Re: Stucked with "unable to look up host"
On 09 Feb 2021, at 06:21, Dominic Raferd wrote: > On 09/02/2021 12:36, @lbutlr wrote: >> On 09 Feb 2021, at 04:23, Dominic Raferd wrote: >>> This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 - >>> including the postfix-users list servers. Of course they would probably >>> downgrade to plaintext if required, but that would reduce security. >> That is odd. My mails from the postfix list server are using TLSv1.2. Are >> you sure the postfix list is using end-of-life encryption?... > It depends how far back one's logs go! Now I look just at my logs for this > calendar year I see you are right. But there are still a few other 'good' > senders using TLSv1 or TLSv1.1, even if they shouldn't be. Not 'plenty', I > admit... Ah, I am only looking at recent logs. I don't see how moths-ago behavior is relevant. But yes, each admin needs to look at their logs and see who is still using encryption they should not be using (especially since this probably indicates they have not updated the ssl libraries and are going to be open to any flaws/attacks/CVEs discovered since TLSv1 and TLSv1.1 were EOLed, making them less-trustworthy in general. -- Vitamins are a waste of money, you can eat like $200 worth and still feel hungry.
Re: Stucked with "unable to look up host"
On 09/02/2021 12:36, @lbutlr wrote: On 09 Feb 2021, at 04:23, Dominic Raferd wrote: This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 - including the postfix-users list servers. Of course they would probably downgrade to plaintext if required, but that would reduce security. That is odd. My mails from the postfix list server are using TLSv1.2. Are you sure the postfix list is using end-of-life encryption?... It depends how far back one's logs go! Now I look just at my logs for this calendar year I see you are right. But there are still a few other 'good' senders using TLSv1 or TLSv1.1, even if they shouldn't be. Not 'plenty', I admit...
Re: Stucked with "unable to look up host"
On 09 Feb 2021, at 04:23, Dominic Raferd wrote: > This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 - including > the postfix-users list servers. Of course they would probably downgrade to > plaintext if required, but that would reduce security. That is odd. My mails from the postfix list server are using TLSv1.2. Are you sure the postfix list is using end-of-life encryption? postfix/smtpd[99319] Anonymous TLS connection established from english-breakfast.cloud9.net[168.100.1.7]: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) It's also in the received headers: Received: from english-breakfast.cloud9.net (english-breakfast.cloud9.net [168.100.1.7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.covisp.net (Postfix) with ESMTPS id 4DZgWP1ktlz2rP86 for ; Tue, 9 Feb 2021 04:23:45 -0700 (MST) Received: by english-breakfast.cloud9.net (Postfix) id E6D03338687; Tue, 9 Feb 2021 06:23:29 -0500 (EST) Delivered-To: postfix-users-outgo...@cloud9.net I have five times as many TLSv1.2 connections as TLSv1.3 connections today, so far, and about 7 times as many yesterday. Still no TLSv1 or TLSv1.1 today, -- What we have here is a failure to communicate.
Re: Stucked with "unable to look up host"
On 31.01.21 09:56, Daniel Armando Rodriguez wrote: >Indeed, it was running chrooted but resolv.conf has the same content >=== # postconf -nf >smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 this is superflous and not a good idea. Many servers support TLS1.0 max. !SSLv2, !SSLv3 should be enough for now. >After adjusting values the recommended way not getting > >connect to correo.dominio.com.ar[]:25: Connection timed out El lun., 8 de febrero de 2021 10:20, Matus UHLAR - fantomas < uh...@fantomas.sk> escribió: % host -t any correo.dominio.com.ar Host correo.dominio.com.ar not found: 3(NXDOMAIN) correo.dominio.com.ar does not exist, so you can't send mail there. It is also reason why it was not resolved. On 08.02.21 13:10, Daniel Armando Rodriguez wrote: That's not a real domain well, it's really hard to guess what's the error if you censor that info. and > >Jan 31 09:43:42 domiinio postfix/smtp[13099]: Untrusted TLS connection >established to alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25: TLSv1.2 >with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits) >Jan 31 09:43:42 dominio postfix/smtp[13099]: E6AA880124FF7: to=< >u...@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com [172.217.218.26]:25, >delay=40220, delays=40215/0/4.5/0, dsn=4.7.5, status=deferred (Server >certificate not trusted) you clearly can resolve and connect to gmail.com mail servers, so the DNS resolution is apparently not the problem -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself.
Re: Stucked with "unable to look up host"
On 31.01.21 09:56, Daniel Armando Rodriguez wrote: Indeed, it was running chrooted but resolv.conf has the same content === # postconf -nf smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 On 08 Feb 2021, at 06:20, Matus UHLAR - fantomas wrote: this is superflous and not a good idea. Many servers support TLS1.0 max. !SSLv2, !SSLv3 should be enough for now. On 09.02.21 03:53, @lbutlr wrote: Both TLSv1 and TLSv1.1 are end-of-life, so it is reasonable as no servers should be supporting. Now, is it needed? That's another question. There are no servers that connected to me today with TLSv1 or TLSv1.1. Looking over the last few days, I see connections rom servers I do not accept mail from, so it looks to me based on my logs that I could easily reject TLSv1 or TLSv1.1 without missing a single mail. I still see connections to my mail server using TLSv1.0. That means, disabling it would make those servers go plaintext. Encryption is not mandatory on server-server SMTP. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: Stucked with "unable to look up host"
On 09/02/2021 10:58, @lbutlr wrote: On 09 Feb 2021, at 03:53, @lbutlr wrote: Looking over the last few days, I see connections rom servers I do not accept mail from, so it looks to me based on my logs that I could easily reject TLSv1 or TLSv1.1 without missing a single mail. Meant to include this in case this helps: bzgrep TLSv1 /var/log/mail.log.* | egrep -v '(TLSv1.3|TLSv1.2)' | egrep -o 'established from [^:]*' | sort -u My logs are unzipped or gzipped, so I needed: zgrep -ha TLSv1 /var/log/mail.log*|egrep -v 'TLSv1\.[23]'|egrep -o 'established from [^:]*'|cut -d" " -f3|sort|uniq -c|sort -n This shows plenty of 'good' servers still using TLSv1 or TLSv1.1 - including the postfix-users list servers. Of course they would probably downgrade to plaintext if required, but that would reduce security.
Re: Stucked with "unable to look up host"
> On 9 February 2021, at 02:58, @lbutlr wrote: > > zgrep TLSv1 /var/log/mail.log.* | egrep -v '(TLSv1.3|TLSv1.2)' | egrep -o > 'established from [^:]*' | sort -u For the last week of my maillogs, I get 298 entries. Some of them are from the US Census, several health organizations, a mail server that is normally not sending spam, some California legislators, but I believe probably 80% are spam. I am not ready to block those yet. If that is the best they can do, then it's better than in the clear. -- Doug
Re: Stucked with "unable to look up host"
On 09 Feb 2021, at 03:53, @lbutlr wrote: > Looking over the last few days, I see connections rom servers I do not accept > mail from, so it looks to me based on my logs that I could easily reject > TLSv1 or TLSv1.1 without missing a single mail. Meant to include this in case this helps: bzgrep TLSv1 /var/log/mail.log.* | egrep -v '(TLSv1.3|TLSv1.2)' | egrep -o 'established from [^:]*' | sort -u -- And Super Heroes come to feast To taste the flesh not yet deceased And all I know is still the beast is feeding.
Re: Stucked with "unable to look up host"
On 08 Feb 2021, at 06:20, Matus UHLAR - fantomas wrote: > On 31.01.21 09:56, Daniel Armando Rodriguez wrote: >> Indeed, it was running chrooted but resolv.conf has the same content > === # postconf -nf >> smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 > > this is superflous and not a good idea. Many servers support TLS1.0 max. > !SSLv2, !SSLv3 should be enough for now. Both TLSv1 and TLSv1.1 are end-of-life, so it is reasonable as no servers should be supporting. Now, is it needed? That's another question. There are no servers that connected to me today with TLSv1 or TLSv1.1. Looking over the last few days, I see connections rom servers I do not accept mail from, so it looks to me based on my logs that I could easily reject TLSv1 or TLSv1.1 without missing a single mail. YMMV. >> smtp_tls_security_level = verify > smtp, by default, is plaintext, and encryption is not fully standard, so you > disable sending mail to part of internet. smtp_tls_security_level = may Is the correct setting. "Verify" should only be used when your server talks only to specific servers that you know are encrypted and want to ensure the communication to those are encrypted. -- Don't kink-shame!
Re: Stucked with "unable to look up host"
El lun., 8 de febrero de 2021 10:20, Matus UHLAR - fantomas < uh...@fantomas.sk> escribió: > On 31.01.21 09:56, Daniel Armando Rodriguez wrote: > >Indeed, it was running chrooted but resolv.conf has the same content > > >=== # postconf -nf > >smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 > > this is superflous and not a good idea. Many servers support TLS1.0 max. > !SSLv2, !SSLv3 should be enough for now. > > >After adjusting values the recommended way not getting > > > >connect to correo.dominio.com.ar[]:25: Connection timed out > > % host -t any correo.dominio.com.ar > Host correo.dominio.com.ar not found: 3(NXDOMAIN) > > correo.dominio.com.ar does not exist, so you can't send mail there. > It is also reason why it was not resolved. > That's not a real domain >and > > > >Jan 31 09:43:42 domiinio postfix/smtp[13099]: Untrusted TLS connection > >established to alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25: > TLSv1.2 > >with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits) > >Jan 31 09:43:42 dominio postfix/smtp[13099]: E6AA880124FF7: to=< > >u...@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com > [172.217.218.26]:25, > >delay=40220, delays=40215/0/4.5/0, dsn=4.7.5, status=deferred (Server > >certificate not trusted) > > This is caused by your setting: > > >smtp_tls_security_level = verify > > smtp, by default, is plaintext, and encryption is not fully standard, so > you > disable sending mail to part of internet. > You're right, already noted that >
Re: Stucked with "unable to look up host"
On 31.01.21 09:56, Daniel Armando Rodriguez wrote: Indeed, it was running chrooted but resolv.conf has the same content === # postconf -nf smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 this is superflous and not a good idea. Many servers support TLS1.0 max. !SSLv2, !SSLv3 should be enough for now. After adjusting values the recommended way not getting connect to correo.dominio.com.ar[]:25: Connection timed out % host -t any correo.dominio.com.ar Host correo.dominio.com.ar not found: 3(NXDOMAIN) correo.dominio.com.ar does not exist, so you can't send mail there. It is also reason why it was not resolved. and Jan 31 09:43:42 domiinio postfix/smtp[13099]: Untrusted TLS connection established to alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25: TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits) Jan 31 09:43:42 dominio postfix/smtp[13099]: E6AA880124FF7: to=< u...@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25, delay=40220, delays=40215/0/4.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted) This is caused by your setting: smtp_tls_security_level = verify smtp, by default, is plaintext, and encryption is not fully standard, so you disable sending mail to part of internet. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Silvester Stallone: Father of the RISC concept.
Re: Stucked with "unable to look up host"
Indeed, it was running chrooted but resolv.conf has the same content
=== # postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
disable_dns_lookups = no
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 20971520
milter_default_action = accept
milter_protocol = 6
mydestination = localhost
mydomain = dominio.com.ar
myhostname = correo.$mydomain
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = $myhostname
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_host_lookup = dns
smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
smtp_tls_loglevel = $smtpd_tls_loglevel
smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
smtp_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
smtp_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_security_level = verify
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated
smtpd_enforce_tls = yes
smtpd_helo_required = yes
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = reject_unknown_sender_domain,
permit_mynetworks,
permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org,
reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_helo
dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org,
check_policy_service
unix:private/policyd-spf, check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_auth_only = yes
smtpd_tls_cert_file =
/etc/apache2/md/domains/correo.dominio.com.ar/pubcert.pem
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
smtpd_tls_key_file =
/etc/apache2/md/domains/correo.dominio.com.ar/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES,
eNULL,
aNULL
smtpd_tls_mandatory_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
spamassassin_destination_recipient_limit = 1
tls_disable_workarounds = 0x
tls_preempt_cipherlist = yes
tls_ssl_options = NO_RENEGOTIATION
virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
=== # postconf -Mf
smtp inet n - n - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_tls_security_level=encrypt
-o tls_preempt_cipherlist=yes
-o content_filter=spamassassin
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o tls_preempt_cipherlist=yes
smtps inet n - y - - smtpd
pickup unix n - y 60 1 pickup
cleanupunix n - y - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - y 1000? 1 tlsmgr
rewriteunix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
trace unix - - y - 0 bounce
verify unix - - y - 1 verify
flush unix n - y 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - y - - smtp
-o syslog_name=postfix/$service_name
showq unix n - y - - showq
error unix - - y - - error
retry unix - - n - - error
discardunix - - y - - discard
local unix - n n - - local
virtual
Re: Stucked with "unable to look up host"
On Sat, Jan 30, 2021 at 09:39:01PM -0700, Bob Proulx wrote: > My best guess is that your chroot does not have a working resolv.conf file. Certainly a good place to start. The only odd detail is that the errors are 5.3.0 errors, so the lookup returned a definitive "no such host", rather than just failing to get an answer. Another possibility therefore, is that the OP (who failed to post "postconf -nf" and "postconf -Mf" details) has disabled DNS lookups entirely, either in main.cf or in master.cf. The correct (default) values of the relevant parameters are: # "yes" is almost never the right setting. # disable_dns_lookups = no # For MTAs setting mail directly to the Internet, # "dns" is the only correct value # smtp_host_lookup = dns The OP should probably post "postconf -nf" and "postconf -Mf" output as explained in: http://www.postfix.org/DEBUG_README.html#mail -- Viktor.
Re: Stucked with "unable to look up host"
Daniel Armando Rodriguez wrote: > , relay=none, delay=1.2, delays=0.15/0.01/1/0, dsn=5.3.0, status=bounced > (unable to look up host host.domain.com: No address associated with > hostname) > > However, DNS resolution works as expected and has a PTR record associated > with it. It is very common for postfix to be run with a chroot configuration specified in the master.cf file. It's the default for many software distributions. Your description fits a case where you can look up the name in the host system outside the chroot but postfix inside the chroot cannot. You can check the configuration this way. $ postconf -F smtp/unix/chroot $ postconf -F relay/unix/chroot The first thing I would try is stopping postfix and then starting it again. Because many start up scripts sync the host DNS configuration into the chroot at startup. This can "just fix it" for many of the problems that might cause this. Try that first. And the detail is that the /etc/resolv.conf file is copied into the chroot location. In other words these two files should have the same contents. And since it is a chroot the chroot version should be a copy (not a symlink) to the main one outside the chroot. $ echo diff /etc/resolv.conf $(postconf -h queue_directory)/etc/resolv.conf diff /etc/resolv.conf /var/spool/postfix/etc/resolv.conf $ diff /etc/resolv.conf $(postconf -h queue_directory)/etc/resolv.conf ...no output...sameno differences... My best guess is that your chroot does not have a working resolv.conf file. Bob
Stucked with "unable to look up host"
Messages log this error , relay=none, delay=1.2, delays=0.15/0.01/1/0, dsn=5.3.0, status=bounced (unable to look up host host.domain.com: No address associated with hostname) However, DNS resolution works as expected and has a PTR record associated with it. Any pointers would be greatly appreciated! ___ Daniel A. Rodriguez Departamento de Tecnología para la Gestión Escuela Provincial de Educación Técnica N° 1 Posadas - Misiones - Argentina (0376) 443-8578 www.epet1.edu.ar
