send to ESP with broken STARTTLS
Hello, I hit an MX-Server with weak DH: # SLES-Host # posttls-finger iutax.de posttls-finger: Connected to iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25 posttls-finger: < 220 gmy2-mh901.smtproutes.com kath-5.0.3 ESMTP Ready posttls-finger: > EHLO idvmailout03.datev.de posttls-finger: < 250-gmy2-mh901.smtproutes.com says Hello [193.27.49.129] posttls-finger: < 250-8BITMIME posttls-finger: < 250-STARTTLS posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250 OK posttls-finger: > STARTTLS posttls-finger: < 220 Ready to start TLS posttls-finger: SSL_connect error to iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: -1 posttls-finger: warning: TLS library problem: error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338: messages to that destination are delivered without STARTTLS later. But: the destination host multiple domains. So a significant portion of out outbound volume goes unencrypted over the wire. The TLS connect don't fail on all of my systems. Some hosts (other OS) do succeed: # Debian Jessie Host # posttls-finger -c iutax.de posttls-finger: iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: Matched subjectAltName: *.smtproutes.com posttls-finger: iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: subjectAltName: smtproutes.com posttls-finger: iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25 CommonName *.smtproutes.com posttls-finger: certificate verification failed for iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority posttls-finger: iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: subject_CN=*.smtproutes.com, issuer_CN=RapidSSL CA, fingerprint=C5:0D:BC:A1:89:83:5D:95:CE:65:BA:F2:31:3C:7F:52:CA:1A:C3:DB, pkey_fingerprint=E9:BF:E7:6F:79:E0:42:59:59:BB:A0:DC:69:F9:AC:73:96:D0:29:5F posttls-finger: Untrusted TLS connection established to iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits) I guess first I should know why same postfix version behave different on SLES and Debian OS -> which settings should I check to find potential different configurations? Andreas
How to log output from whatever pipe runs ?
The setup : postfix + maildrop in a virtual user setup. Maildirs are in
/var/vmail/domain{1,2,...}/user{1,2,...}
When maildrop is invoked from the command line, it delievers the mail
correctly. But when it is invoked by postfix, the mail is delivered to the
wrong place (/var/vmail/Maildir instead of /var/vmail/domain/user)
I would like to log the output of maildir -V 9 when it is launched from
postfix. Here's what I tried :
in /etc/postfix/master.cf
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -V9 -d ${recipient} -w 80 >>
/tmp/maildrop 2>&1
/tmp/malidrop remains empty (not even created).
How do I get maildrop -V to log to /tmp/maildrop ?
Re: How to log output from whatever pipe runs ?
How about running a logging wrapper script, instead. Rather than invoking the maildrop executable, invoke a script, perhaps something like #!/bin/sh exec >/tmp/maildrop.log 2>&1 echo $0 "$@" set -x printenv maildrop ...
Re: How to log output from whatever pipe runs ?
chaouche yacine: > maildrop: Delivery complete. > root@messagerie[10.10.10.20] ~ # > > > What could be the reason to have two different outputs for the same command ? One obvious diference is that Postfix does not run the maildrop program as user ROOT. Have to tried to run it by hand as user VMAIL, just like you configured in master.cf? Wietse
OT: mirror update contact e-mail
Hello. I run a mirror for Postfix and I need to update the URL. I have e-mailed Wietse several times in the past few years, and every time the e-mail is being ignored. What is the proper subject to use to contact Wietse to update my mirror details? Thanks
Re: How to log output from whatever pipe runs ?
On Thursday, March 31, 2016 3:55 PM, Bennett Todd wrote:
>How about running a logging wrapper script, instead.
Good idea. When maildrop is invoked from the command line, it works. Each mail
is delivered to the correct Maildir. Here's what it outputs :
root@messagerie[10.10.10.20] ~ # echo "envoi vers a.chaouche" |
/home/vmail/maildropwrapper -V9 -d a.chaou...@algerian-radio.dz -w 80
root@messagerie[10.10.10.20] ~ # cat /tmp/maildrop
calling maildrop with arguments -V9 -d a.chaou...@algerian-radio.dz -w 80
maildrop: authlib: groupid=120
maildrop: authlib: userid=113
maildrop: authlib: logname=a.chaou...@algerian-radio.dz, home=/var/vmail/,
mail=algerian-radio.dz/a.chaouche/
maildrop: Changing to /var/vmail/
Message envelope sender=MAILER-DAEMON
maildrop: Attempting .mailfilter
WARN: quota string '1073741824' not parseable
maildrop: Delivery complete.
root@messagerie[10.10.10.20] ~ #
When invoked from postfix, mail for any recipient is invariably delivered to
/var/vmail/Maildir, which is nobody's Maildir by the way. Here's what it logs
(I have prefixed diffrences with +):
root@messagerie[10.10.10.20] ~ # cat /tmp/maildrop
calling maildrop with arguments -V9 -d a.chaou...@algerian-radio.dz -w 80
maildrop: authlib: groupid=120
maildrop: authlib: userid=113
maildrop: authlib: logname=a.chaou...@algerian-radio.dz, home=/var/vmail/,
mail=algerian-radio.dz/a.chaouche/
maildrop: Changing to /var/vmail/
Message envelope sender=r...@messagerie.algerian-radio.dz
maildrop: Attempting .mailfilter
( missing line WARN: quota string '1073741824' not parseable )
+maildrop: Delivering to ./Maildir
+maildrop: Flock()ing ./Maildir.
+maildrop: Appending to ./Maildir.
maildrop: Delivery complete.
root@messagerie[10.10.10.20] ~ #
What could be the reason to have two different outputs for the same command ?
Here's master.cf
maildrop unix - n n - - pipe
# flags=DRhu user=vmail argv=/usr/bin/maildrop -V9 -d ${recipient} -w 80 >>
tmp/maildrop 2>&1
flags=DRhu user=vmail argv=/home/vmail/maildropwrapper -V9 -d ${recipient} -w 80
Postscreen setup
I am trying to setup postscreen,.
I have read the documentation and it would appear that I don't need to
do very much to get postscreen working. Which makes me think I have got
it wrong.
So I have some questions:
1) I have to change smtp ... smtpd to smtp ... postscreen. As my
master.cf seems to be somewhat different, is that "all" I need to do in
master?
As I expect local user to use submission for sending (as a result
mynetworks is 127.0.0.1 & ::1/128) do I need specify postscreen_access_list?
As postscreen does dnsbl lookups do I still need the reject_rbl_client
entries in smtpd_recipient_restrictions? Do the latter entries do more
than the dnsbl entries?
My postscreen setup would be something like:
# postscreen_access_list = permit_mynetworks do I need this
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = drop
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3
bl.spameatingmonkey.net*2
bl.ipv6.spameatingmonkey.net*2
dnsbl.ahbl.org*2
bl.spamcop.net
dnsbl.sorbs.net
swl.spamhaus.org*-4
postscreen_greet_action = enforce
postscreen_helo_required = yes
|postscreen_disable_vrfy_command = $disable_vrfy_command|
|postscreen_enforce_tls = $smtpd_enforce_tls
postscreen_use_tls = $smtpd_use_tls|
|What have I got wrong, how can I improve on it|
|=== Main.cf ===|
|alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_size_limit = 65536
compatibility_level = 2
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 20
delay_warning_time = 12h
disable_vrfy_command = yes
header_size_limit = 32768
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_protocols = ipv4, ipv6
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 32768000
mime_header_checks = pcre:/etc/postfix/maps/mime_header_checks.pcre
mydestination = localhost, localhost.localdomain, localdomain
mydomain = klam.ca
myhostname = smtp.$mydomain
mynetworks = 127.0.0.0/8, [::1]/128
myorigin = $mydomain
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relocated_maps = hash:/etc/postfix/maps/relocated
smtp_dns_support_level = dnssec
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = DES, MD5, RC2, RC4, RC5, IDEA, SRP, PSK, aDSS,
kECDhe, kECDhr, kDHd, kDHr, SEED, LOW, EXPORT
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions =
smtpd_data_restrictions = reject_multi_recipient_bounce,
reject_unauth_pipelining
smtpd_error_sleep_time = 5s
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_recipient_limit = 128
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain, reject_unknown_recipient_domain,
reject_unauth_destination, reject_unknown_reverse_client_hostname,
check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre,
check_recipient_access hash:/etc/postfix/maps/recipient_checks,
check_helo_access pcre:/etc/postfix/maps/helo_checks.pcre,
check_sender_access hash:/etc/postfix/maps/sender_checks,
check_policy_service inet:127.0.0.1:10023, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net
smtpd_relay_restrictions = reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sender_restrictions =
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /root/ssl/certs/$mydomain.mail.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
smtpd_tls_key_file = /root/ssl/private/$mydomain.mail.key
smtpd_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
smtpd_tls_protocols = $smtp_tls_protocols
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport
virtual_alias_maps = proxy:pgsql:/etc/postfix/sql/virtual_alias_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_map.sql
virtual_mailbox_domains =
proxy:pgsql:/etc/postfix/sql/virtual_domain_map.sql
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/sql/virtual_mailbox_map.sql,
proxy:pgsql:/etc/postfix/sql/virtual_alias_domain_mailbox_map.sql
virtual_transport = lmtp:unix:private/dovecot-lmtp
|
|===Master.cf ==|
|smtp inet n - n - - smtpd
-o cleanup_service_name=pre-cleanup
pickup fifo n - n 60 1 pickup
-o cleanup_service_name=pre-cleanup
submission inet n - n - 30 smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10026
-o syslog_name=postfix/submission
-o smtpd_tls_securit
Re: Postscreen setup
> On Mar 31, 2016, at 1:32 PM, John Allen wrote: > > I have read the documentation and it would appear that I don't need to do > very much to get postscreen working. Which makes me think I have got it > wrong. > > So I have some questions: > > 1) I have to change smtp ... smtpd to smtp ... postscreen. As my master.cf > seems to be somewhat different, is that "all" I need to do in master? No. Read again. You have to *add* an "smtp inet ... postscreen" service, and *change* the "smtp inet" entry to "smtpd pass". As shown in the minimal commented out lines in the stock master.cf file: #smtp inet n - n - 1 postscreen #smtpd pass - - n - - smtpd -- Viktor.
Re: OT: mirror update contact e-mail
Matthew McGehrin: > Hello. > > I run a mirror for Postfix and I need to update the URL. I have e-mailed > Wietse several times in the past few years, and every time the e-mail is > being ignored. What is the proper subject to use to contact Wietse to > update my mirror details? Sorry about that. I see no "McGehrin" email in my unanswered mail folders (usin "grep"). Maybe I already did the update and forgot to reply? Wietse
Re: Postscreen setup
John Allen: > As postscreen does dnsbl lookups do I still need the reject_rbl_client > entries in smtpd_recipient_restrictions? Do the latter entries do more > than the dnsbl entries? It does not hurt. The DNS reply is cached in the DNS server. > My postscreen setup would be something like: > > # postscreen_access_list = permit_mynetworks do I need this That is the default setting. It avoids problems with non-standard SMTP implementations (tests, appliances, etc.). > postscreen_bare_newline_enable = yes I would not recommend the bare_newline, non_smtp, or pipelining tests unless you are willing to accept delays similar to greylisting. Wietse
Re: Postscreen setup
On Mar 31, 2016, at 1:32 PM, John Allen wrote: I have read the documentation and it would appear that I don't need to do very much to get postscreen working. Which makes me think I have got it wrong. So I have some questions: 1) I have to change smtp ... smtpd to smtp ... postscreen. As my master.cf seems to be somewhat different, is that "all" I need to do in master? No. Read again. You have to *add* an "smtp inet ... postscreen" service, and *change* the "smtp inet" entry to "smtpd pass". As shown in the minimal commented out lines in the stock master.cf file: #smtp inet n - n - 1 postscreen #smtpd pass - - n - - smtpd From everything I had read I expected the smtp entry in master to be smtp inet n - n - 1postscreen -o cleanup_service_name=pre-cleanup But you are saying it should be smtp inet n - n - 1postscreen smtpdpass --n- 1smtpd -o cleanup_service_name=pre-cleanup
Re: send to ESP with broken STARTTLS
On Thu, Mar 31, 2016 at 04:47:10PM +0200, A. Schulze wrote: > I hit an MX-Server with weak DH: > > # SLES-Host > # posttls-finger iutax.de > posttls-finger: Connected to > iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25 Yes, this server has a 768-bit DH key. > posttls-finger: < 220 gmy2-mh901.smtproutes.com kath-5.0.3 ESMTP Ready > posttls-finger: > EHLO idvmailout03.datev.de > posttls-finger: < 250-gmy2-mh901.smtproutes.com says Hello [193.27.49.129] > posttls-finger: < 250-8BITMIME > posttls-finger: < 250-STARTTLS > posttls-finger: < 250-ENHANCEDSTATUSCODES > posttls-finger: < 250 OK > posttls-finger: > STARTTLS > posttls-finger: < 220 Ready to start TLS > posttls-finger: SSL_connect error to > iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: -1 > posttls-finger: warning: TLS library problem: error:14082174:SSL > routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338: The minimum DH strengh has increased to 1024 bits in recent versions of OpenSSL. The only way to use TLS with this server is to disable Diffie-Hellman key exchange. The below master.cf entry creates an smtp(8) transport called "nodh" in which finite-field Diffie-Hellman key exchange is disabled: master.cf: nodh unix - - - - - smtp -o tls_high_cipherlist=!kDHE:!kEDH:aNULL:-aNULL:HIGH:@STRENGTH -o tls_medium_cipherlist=!kDHE:!kEDH:aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH -o smtp_tls_ciphers=medium The 1024-bit lower limit is enforced internally by the OpenSSL library and cannot be reduced. To test: $ opt=$(postconf -d tls_medium_cipherlist):'!kDHE:!kEDH' $ posttls-finger -o "$opt" -c -lencrypt -Lsummary iutax.de posttls-finger: Untrusted TLS connection established to iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: TLSv1.2 with cipher AES256-SHA (256/256 bits) You can then add transport table entries: transport: iutax.denodh ... > I guess first I should know why same postfix version behave different on > SLES and Debian OS > -> which settings should I check to find potential different configurations? The systems have different OpenSSL libraries, and in particular at least one of them has not deployed all of the most recent OpenSSL security updates. -- Viktor.
Re: Postscreen setup
On Thu, Mar 31, 2016 at 02:01:57PM -0400, John Allen wrote: > From everything I had read I expected the smtp entry in master to be > > smtp inet n - n - 1postscreen > -o cleanup_service_name=pre-cleanup > > But you are saying it should be > > smtp inet n - n - 1postscreen > smtpdpass --n- 1smtpd > -o cleanup_service_name=pre-cleanup Yes, that's exactly what I am saying. The option in question is an smtpd(8) option, not a TCP protocol option. And more generally all your previous smtpd(8) service option overrides stay with the smtpd(8) service and don't move to the postscreen(8) service which takes over the TCP protocol, and then passes the connection to smtpd(8). -- Viktor.
Re: block all mail from mta's with a FQDN match?
I am not sure what I did here, but I seem to have taken over /dev/rob0's thread, not my intention. My apologies to everyone and in particular to /dev/rob0 John A
Re: send to ESP with broken STARTTLS
Viktor Dukhovni: iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25 Yes, this server has a 768-bit DH key. a larger email service provider :-/ see https://www.robtex.com/en/advisory/ip/94/186/192/102/ The 1024-bit lower limit is enforced internally by the OpenSSL library and cannot be reduced. thanks for clarification The systems have different OpenSSL libraries, and in particular at least one of them has not deployed all of the most recent OpenSSL security updates. looks like Debian Jessie (stable) still accept weak DH keys As mentioned we see numerous domains with the same broken MX. I have to list them one by one in the transport table or did I forgot a cool configuration to catch any destination domain with this specific MX? Andreas
understanding postscreen cache?
I'd like to understand postscreen's cache behavior a bit better than I do. Looking at my logs for one example Mar 29 18:25:28 mail01 postfix/postscreen[24234]: CONNECT from [79.13.92.233]:64564 to [192.0.2.24]:25 Mar 29 18:25:28 mail01 postfix/dnsblog[24238]: addr 79.13.92.233 listed by domain zen.spamhaus.org as 127.0.0.10 Mar 29 18:25:28 mail01 postfix/dnsblog[24240]: addr 79.13.92.233 listed by domain dnsbl.sorbs.net as 127.0.0.10 Mar 29 18:25:34 mail01 postfix/postscreen[24234]: DNSBL rank 10 for [79.13.92.233]:64564 Mar 29 18:25:34 mail01 postfix/postscreen[24234]: NOQUEUE: reject: RCPT from [79.13.92.233]:64564: 550 5.7.1 Service unavailable; client [79.13.92.233] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo=<[79.13.92.233]> Mar 29 18:25:35 mail01 postfix/postscreen[24234]: HANGUP after 0.79 from [79.13.92.233]:64564 in tests after SMTP handshake Mar 29 18:25:35 mail01 postfix/postscreen[24234]: DISCONNECT [79.13.92.233]:64564 Mar 29 18:26:02 mail01 postfix/postscreen[24234]: CONNECT from [79.13.92.233]:57377 to [192.0.2.24]:25 Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed by domain zen.spamhaus.org as 127.0.0.10 Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed by domain dnsbl.sorbs.net as 127.0.0.10 Mar 29 18:26:08 mail01 postfix/postscreen[24234]: DNSBL rank 10 for [79.13.92.233]:57377 Mar 29 18:26:08 mail01 postfix/postscreen[24234]: NOQUEUE: reject: RCPT from [79.13.92.233]:57377: 550 5.7.1 Service unavailable; client [79.13.92.233] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo=<[79.13.92.233]> Mar 29 18:26:08 mail01 postfix/postscreen[24234]: HANGUP after 0.75 from [79.13.92.233]:57377 in tests after SMTP handshake Mar 29 18:26:08 mail01 postfix/postscreen[24234]: DISCONNECT [79.13.92.233]:57377 That looks to me like the dnsblog checks, to zen.spamhaus.org and dnsbl.sorbs.net, are run twice. My understanding was that postscreen, once it catches a bad actor, it caches the result so subsequent attempts get a response from the cache. Is what I'm seeing here, the 2nd set of dnsblog results, actually from the postscreen cache? Or am I actually seeing the check run (unnecessarily) twice? If it's the former, how can I better detect & indicate in logs that it's a cached result? If it's the second, what can I do to prevent the 2nd unncessary check? Thanks. Jason
Re: understanding postscreen cache?
On 3/31/2016 3:30 PM, jaso...@mail-central.com wrote: > I'd like to understand postscreen's cache behavior a bit better than I do. > > Looking at my logs for one example > > Mar 29 18:25:28 mail01 postfix/postscreen[24234]: CONNECT from > [79.13.92.233]:64564 to [192.0.2.24]:25 > Mar 29 18:25:28 mail01 postfix/dnsblog[24238]: addr 79.13.92.233 listed > by domain zen.spamhaus.org as 127.0.0.10 > Mar 29 18:25:28 mail01 postfix/dnsblog[24240]: addr 79.13.92.233 listed > by domain dnsbl.sorbs.net as 127.0.0.10 > Mar 29 18:25:34 mail01 postfix/postscreen[24234]: DNSBL rank 10 for > [79.13.92.233]:64564 > Mar 29 18:25:34 mail01 postfix/postscreen[24234]: NOQUEUE: reject: RCPT > from [79.13.92.233]:64564: 550 5.7.1 Service unavailable; client > [79.13.92.233] blocked using zen.spamhaus.org; from=, > to=, proto=ESMTP, helo=<[79.13.92.233]> > Mar 29 18:25:35 mail01 postfix/postscreen[24234]: HANGUP after 0.79 > from [79.13.92.233]:64564 in tests after SMTP handshake > Mar 29 18:25:35 mail01 postfix/postscreen[24234]: DISCONNECT > [79.13.92.233]:64564 > Mar 29 18:26:02 mail01 postfix/postscreen[24234]: CONNECT from > [79.13.92.233]:57377 to [192.0.2.24]:25 > Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed > by domain zen.spamhaus.org as 127.0.0.10 > Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed > by domain dnsbl.sorbs.net as 127.0.0.10 > Mar 29 18:26:08 mail01 postfix/postscreen[24234]: DNSBL rank 10 for > [79.13.92.233]:57377 > Mar 29 18:26:08 mail01 postfix/postscreen[24234]: NOQUEUE: reject: RCPT > from [79.13.92.233]:57377: 550 5.7.1 Service unavailable; client > [79.13.92.233] blocked using zen.spamhaus.org; from=, > to=, proto=ESMTP, helo=<[79.13.92.233]> > Mar 29 18:26:08 mail01 postfix/postscreen[24234]: HANGUP after 0.75 > from [79.13.92.233]:57377 in tests after SMTP handshake > Mar 29 18:26:08 mail01 postfix/postscreen[24234]: DISCONNECT > [79.13.92.233]:57377 > > That looks to me like the dnsblog checks, to zen.spamhaus.org and > dnsbl.sorbs.net, are run twice. The dnsblog results are cached both locally in the dnsblog service, and on your local DNS server ** subject to the TTL set by the DNSBL operator **. > > My understanding was that postscreen, once it catches a bad actor, it caches > the result so subsequent attempts get a response from the cache. IIRC postscreen caches PASS results only. > > Is what I'm seeing here, the 2nd set of dnsblog results, actually from the > postscreen cache? Or am I actually seeing the check run (unnecessarily) > twice? The dnsblog results are from the cache if they exist. > > If it's the former, how can I better detect & indicate in logs that it's a > cached result? > > If it's the second, what can I do to prevent the 2nd unncessary check? Why do you care? If the prior results are still in the cache, they're used. If not, another lookup is made. Not much you can do about it either way, other than blacklist repeat offenders in the postscreen_access_list. Postfix 3.1 introduced postscreen_dnsbl_min_ttl (and postscreen_dnsbl_max_ttl) to reduce repeated DNS lookups in a short period of time for DNSBL sites that use a very short timeout. -- Noel Jones
Re: Postscreen setup
BTW, regarding the apology, thanks. It wasn't my thread, but indeed all of us who use threaded mail readers are affected by "thread hijacking." Now a few comments about your config, one of which is a serious problem ... On Thu, Mar 31, 2016 at 01:32:02PM -0400, John Allen wrote: > As I expect local user to use submission for sending (as a result > mynetworks is 127.0.0.1 & ::1/128) do I need specify > postscreen_access_list? I use that to whitelist one site (affiliated with us) and to block certain undesirable ESP services. > As postscreen does dnsbl lookups do I still need the > reject_rbl_client entries in smtpd_recipient_restrictions? Do the > latter entries do more than the dnsbl entries? Postscreen is a scoring system; reject_rbl_client is outright rejection for a DNSBL hit. It does not hurt to leave them in if you're sure you don't want any mail from any host on that list. I keep a "reject_rbl_client zen.spamhaus.org" in my restrictions, and then I have an insanely complex mess of restriction classes which might call other DNSBLs based on recipient domain. > My postscreen setup would be something like: > > # postscreen_access_list = permit_mynetworks do I need this I have a cidr: lookup there. > postscreen_bare_newline_action = enforce > postscreen_bare_newline_enable = yes Wietse covered this also: maybe premature on enabling this? > postscreen_blacklist_action = drop > postscreen_dnsbl_threshold = 3 > postscreen_dnsbl_action = enforce > postscreen_dnsbl_sites = zen.spamhaus.org*3 > bl.spameatingmonkey.net*2 > bl.ipv6.spameatingmonkey.net*2 > dnsbl.ahbl.org*2 B! No! Absolutely not!! AHBL is closed and now lists the entire IPv4 Internet space. BTW I updated my HOWTO, but you seem to be using the old version. New version is here: http://rob0.nodns4.us/postscreen.html "... Last updated: 2016-01-16 Last changes: updated for Postfix 2.11+, removed AHBL. The previous version of this document, which did NOT require Postfix 2.11+, can be seen here: postscreen-old.html, with AHBL left intact! (Let this serve as a lesson to those who follow online howto documents without reading and understanding them.) " > bl.spamcop.net > dnsbl.sorbs.net > swl.spamhaus.org*-4 Spamhaus SWL does not list very many hosts. I really do recommend DNSWL.org (and use it for bypassing the after-220 tests with "postscreen_dnsbl_whitelist_threshold=-1". > smtpd_recipient_restrictions = reject_invalid_hostname, > reject_non_fqdn_hostname, reject_non_fqdn_sender, The first two are deprecated syntax, *_helo_hostname > reject_non_fqdn_recipient, > reject_unknown_sender_domain, reject_unknown_recipient_domain, > reject_unauth_destination, reject_unknown_reverse_client_hostname, > check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre, > check_recipient_access hash:/etc/postfix/maps/recipient_checks, > check_helo_access pcre:/etc/postfix/maps/helo_checks.pcre, > check_sender_access hash:/etc/postfix/maps/sender_checks, > check_policy_service inet:127.0.0.1:10023, reject_rbl_client > zen.spamhaus.org, reject_rbl_client bl.spamcop.net I wouldn't reject on Spamcop. It's an automated list, and the Spamcop folks will tell you it's best when used in a scoring system. Your mail, so it's up to you, of course. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: send to ESP with broken STARTTLS
On Thu, Mar 31, 2016 at 10:21:00PM +0200, A. Schulze wrote: > As mentioned we see numerous domains with the same broken MX. > I have to list them one by one in the transport table > or did I forgot a cool configuration to catch any destination domain with > this specific MX? There is no such cool configuration. If you have Postfix 3.0.4 or 3.1.0, and you're willing to "downgrade" TLS to suppress forward-secrecy when ECDHE is not available for all mail that fails first delivery, you could configure a second Postfix instance as an "smtp_fallback_relay", and disable kDHE/kEDH only in the fallback relay instance. This is a bit tricky to set up, and only works with 3.0.4 and later. (Supposed to work with 3.0.0, but there's a bug fixed in 3.0.4 that makes it avoid transport throttling). -- Viktor.
Issues with postscreen and barracuda spam firewall
Hi, We have customers testing our next Zimbra release, which includes support for postscreen. By default, postscreen is not set to take any actions. However, one tester found that even with this being the case, connections from their Barracuda Spam Firewall are being rejected thusly: Mar 11 11:15:09 webmail postfix/postscreen[5234]: CONNECT from [X.X.X.X]:38752 to [Y.Y.Y.Y]:25 Mar 11 11:15:09 webmail postfix/postscreen[5234]: PREGREET 36 after 0 from [X.X.X.X]:38752: EHLO cabernet.example.com\r\n Mar 11 11:15:10 webmail postfix/smtpd[5235]: connect from cabernet.example.com[X.X.X.X] Mar 11 11:15:10 webmail postfix/smtpd[5235]: lost connection after EHLO from cabernet.example.com[X.X.X.X] Mar 11 11:15:10 webmail postfix/smtpd[5235]: disconnect from cabernet.example.com[X.X.X.X] ehlo=1 commands=1 Is this a known issue with Barracuda? Anyone have an idea how to work around this? Clearly having their spam appliance be non-functional isn't a great start. ;) Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Re: Issues with postscreen and barracuda spam firewall
On Thu, Mar 31, 2016 at 03:15:11PM -0700, Quanah Gibson-Mount wrote: > We have customers testing our next Zimbra release, which includes > support for postscreen. Very nice! Congratulations. > By default, postscreen is not set to take any actions. > However, one tester found that even with this being the case, connections > from their Barracuda Spam Firewall are being rejected thusly: > > Mar 11 11:15:09 webmail postfix/postscreen[5234]: CONNECT from > [X.X.X.X]:38752 to [Y.Y.Y.Y]:25 > Mar 11 11:15:09 webmail postfix/postscreen[5234]: PREGREET 36 after > 0 from [X.X.X.X]:38752: EHLO cabernet.example.com\r\n Yikes. > Mar 11 11:15:10 webmail postfix/smtpd[5235]: connect from > cabernet.example.com[X.X.X.X] > Mar 11 11:15:10 webmail postfix/smtpd[5235]: lost connection after > EHLO from cabernet.example.com[X.X.X.X] "Lost connection", the client hung up on postscreen or the TCP connection was otherwise disrupted. Causality is unknown unless logged on the client side. > Mar 11 11:15:10 webmail postfix/smtpd[5235]: disconnect from > cabernet.example.com[X.X.X.X] ehlo=1 commands=1 > > Is this a known issue with Barracuda? No idea, but yikes, PREGREET? > Anyone have an idea how to work around this? Try adding the client to postscreen_access_list? > Clearly having their spam appliance be non-functional isn't a > great start. ;) I think I'd choose Barracuda OR postscreen, not sure how both of them together could be useful? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Issues with postscreen and barracuda spam firewall
--On Thursday, March 31, 2016 6:57 PM -0500 "/dev/rob0" wrote: Anyone have an idea how to work around this? Try adding the client to postscreen_access_list? I asked them if it was in mynetworks, but they haven't responded yet. I'll ask again. ;) Clearly having their spam appliance be non-functional isn't a great start. ;) I think I'd choose Barracuda OR postscreen, not sure how both of them together could be useful? Dunno. :) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Re: understanding postscreen cache?
> > Mar 29 18:25:28 mail01 postfix/dnsblog[24238]: addr 79.13.92.233 listed > > by domain zen.spamhaus.org as 127.0.0.10 > > Mar 29 18:25:28 mail01 postfix/dnsblog[24240]: addr 79.13.92.233 listed > > by domain dnsbl.sorbs.net as 127.0.0.10 ... > > Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed > > by domain zen.spamhaus.org as 127.0.0.10 > > Mar 29 18:26:02 mail01 postfix/dnsblog[24237]: addr 79.13.92.233 listed > > by domain dnsbl.sorbs.net as 127.0.0.10 That is two DNS lookups, each lookup having two results. > > That looks to me like the dnsblog checks, to zen.spamhaus.org and > > dnsbl.sorbs.net, are run twice. Not really. Your local DNS resolver caches DNS replies (whatever is in /etc/resolv.conf or equivalent). However the dnsblog client is stateless; it relies on caching in your local DNS resolver. > > My understanding was that postscreen, once it catches a bad actor, it > > caches the result so subsequent attempts get a response from the cache. > > IIRC postscreen caches PASS results only. Correct. Postscreen remembers tests that a client has passed. But the client must pass all tests before postscreen will log a "PASS". Wietse
Re: Issues with postscreen and barracuda spam firewall
Quanah Gibson-Mount: > Hi, > > We have customers testing our next Zimbra release, which includes support > for postscreen. By default, postscreen is not set to take any actions. > However, one tester found that even with this being the case, connections > from their Barracuda Spam Firewall are being rejected thusly: > > Mar 11 11:15:09 webmail postfix/postscreen[5234]: CONNECT from > [X.X.X.X]:38752 to [Y.Y.Y.Y]:25 > Mar 11 11:15:09 webmail postfix/postscreen[5234]: PREGREET 36 after 0 from > [X.X.X.X]:38752: EHLO cabernet.example.com\r\n > Mar 11 11:15:10 webmail postfix/smtpd[5235]: connect from > cabernet.example.com[X.X.X.X] > Mar 11 11:15:10 webmail postfix/smtpd[5235]: lost connection after EHLO > from cabernet.example.com[X.X.X.X] > Mar 11 11:15:10 webmail postfix/smtpd[5235]: disconnect from > cabernet.example.com[X.X.X.X] ehlo=1 commands=1 > > Is this a known issue with Barracuda? Anyone have an idea how to work > around this? Clearly having their spam appliance be non-functional isn't a > great start. ;) Running Postscreen after a spam appliance is pointless. It is a spambot detector (in more sophisticated words, it implements IP address-based reputation). Wietse
Re: Postscreen setup
On 31/03/2016 5:34 PM, /dev/rob0 wrote: BTW, regarding the apology, thanks. It wasn't my thread, but indeed all of us who use threaded mail readers are affected by "thread hijacking." Now a few comments about your config, one of which is a serious problem ... On Thu, Mar 31, 2016 at 01:32:02PM -0400, John Allen wrote: As I expect local user to use submission for sending (as a result mynetworks is 127.0.0.1 & ::1/128) do I need specify postscreen_access_list? I use that to whitelist one site (affiliated with us) and to block certain undesirable ESP services. As postscreen does dnsbl lookups do I still need the reject_rbl_client entries in smtpd_recipient_restrictions? Do the latter entries do more than the dnsbl entries? Postscreen is a scoring system; reject_rbl_client is outright rejection for a DNSBL hit. It does not hurt to leave them in if you're sure you don't want any mail from any host on that list. I keep a "reject_rbl_client zen.spamhaus.org" in my restrictions, and then I have an insanely complex mess of restriction classes which might call other DNSBLs based on recipient domain. My postscreen setup would be something like: # postscreen_access_list = permit_mynetworks do I need this I have a cidr: lookup there. postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes Wietse covered this also: maybe premature on enabling this? postscreen_blacklist_action = drop postscreen_dnsbl_threshold = 3 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spameatingmonkey.net*2 bl.ipv6.spameatingmonkey.net*2 dnsbl.ahbl.org*2 B! No! Absolutely not!! AHBL is closed and now lists the entire IPv4 Internet space. BTW I updated my HOWTO, but you seem to be using the old version. New version is here: http://rob0.nodns4.us/postscreen.html "... Last updated: 2016-01-16 Last changes: updated for Postfix 2.11+, removed AHBL. The previous version of this document, which did NOT require Postfix 2.11+, can be seen here: postscreen-old.html, with AHBL left intact! (Let this serve as a lesson to those who follow online howto documents without reading and understanding them.) " bl.spamcop.net dnsbl.sorbs.net swl.spamhaus.org*-4 Spamhaus SWL does not list very many hosts. I really do recommend DNSWL.org (and use it for bypassing the after-220 tests with "postscreen_dnsbl_whitelist_threshold=-1". smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, The first two are deprecated syntax, *_helo_hostname reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_unknown_reverse_client_hostname, check_recipient_access pcre:/etc/postfix/maps/recipient_checks.pcre, check_recipient_access hash:/etc/postfix/maps/recipient_checks, check_helo_access pcre:/etc/postfix/maps/helo_checks.pcre, check_sender_access hash:/etc/postfix/maps/sender_checks, check_policy_service inet:127.0.0.1:10023, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net I wouldn't reject on Spamcop. It's an automated list, and the Spamcop folks will tell you it's best when used in a scoring system. Your mail, so it's up to you, of course. Thanks for the heads up on /dnsbl.ahbl.org/. I don't remember reading your "how to", had I done so it would probably have saved me some time and head scratching. The list I had proposed was an amalgam of many of the articles I had read. What I arrived at is: b.barracudacentral.org=127.0.0.2*7 dnsbl.inps.de=127.0.0.2*7 zen.spamhaus.org=127.0.0.10*8 zen.spamhaus.org=127.0.0.11*8 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*4 zen.spamhaus.org=127.0.0.2*3 list.dnswl.org=127.0.[0..255].0*-2 list.dnswl.org=127.0.[0..255].1*-3 list.dnswl.org=127.0.[0..255].2*-4 list.dnswl.org=127.0.[0..255].3*-5 bl.mailspike.net=127.0.0.2*5 bl.mailspike.net=127.0.0.10*4 bl.mailspike.net=127.0.0.11*4 bl.mailspike.net=127.0.0.12*4 wl.mailspike.net=127.0.0.18*-2 wl.mailspike.net=127.0.0.19*-2 wl.mailspike.net=127.0.0.20*-2 dnsbl.sorbs.net=127.0.0.10*8 dnsbl.sorbs.net=127.0.0.5*6 dnsbl.sorbs.net=127.0.0.7*3 dnsbl.sorbs.net=127.0.0.8*2 dnsbl.sorbs.net=127.0.0.6*2 dnsbl.sorbs.net=127.0.0.9*2 But as I did not understand it or its syntax i decided to use the list that L.P.H van Belle used in his February posting. I will at some future date take a closer look at it. new main.cf alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_size_limit = 65536 compatibility_level = 2 content_filter = smtp-amavis:[127.0.0.1]:10024 default_process_limit = 20 delay_warning_time = 12h disable_vrfy_command = yes header_size_limit = 32768 home_mailbox = Maildir/ html_directory = /usr/share/doc/postfix/html inet_protocols = ipv4, ipv6 mailbox_transport = lmtp:unix:private/dovecot-lmtp message_size_limit = 32768
