Postscreen - max parallel incoming connections
Hi, I'm running a stress test against Postfix, running smtp-source command with 1.000 parallel connections from one source IP. When postscreen is active, at about 400-460 connections I get "421 4.3.2 All server ports are busy". For 1-2 days I tried to find a solution in the postscreen documentation and change various parameters such as those below, but no luck so far and I'm out of ideas. smtpd_client_connection_rate_limit = 0 smtpd_client_connection_count_limit = 0 (also tried with 1.000+) smtpd_client_message_rate_limit = 0 smtpd_client_recipient_rate_limit = 0 smtpd_client_new_tls_session_rate_limit = 0 default_process_limit=2500 and few others (smtpd/smtp related) in master.cf. If I deactivate postscreen or run the test on port 587 everything goes as expected. I would like to have postcreen in place too, in order to be able to manage limits when will be needed. Any tip would be helpful. Thank you. Regards, Marius Gologan.
Re: Postscreen - max parallel incoming connections
Marius Gologan: > I'm running a stress test against Postfix, running smtp-source command with > 1.000 parallel connections from one source IP. > When postscreen is active, at about 400-460 connections I get "421 4.3.2 All > server ports are busy". Please do not blame the messenger of the bad news. POSTSCREEN tries to hand off of connections to SMTPD. You are running into the condition where all SMTPD ports are busy. No amount of POSTSCREEN tweaking will prevent that. Wietse
Re: Postscreen - max parallel incoming connections
Wietse Venema: > Marius Gologan: > > I'm running a stress test against Postfix, running smtp-source command with > > 1.000 parallel connections from one source IP. > > When postscreen is active, at about 400-460 connections I get "421 4.3.2 All > > server ports are busy". > > Please do not blame the messenger of the bad news. > > POSTSCREEN tries to hand off of connections to SMTPD. You are running > into the condition where all SMTPD ports are busy. > > No amount of POSTSCREEN tweaking will prevent that. Additionally, "421 4.3.2 All screening ports are busy" means that too many clients are waiting for DNSBL/WL lookups, "greet wait" test, or other tests. A client needs to repeat a test when its result has expired. But that is not the problem that you report. Wietse
RE: Postscreen - max parallel incoming connections
Thank you. Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, August 26, 2014 2:43 PM To: Postfix users Subject: Re: Postscreen - max parallel incoming connections Wietse Venema: > Marius Gologan: > > I'm running a stress test against Postfix, running smtp-source command with > > 1.000 parallel connections from one source IP. > > When postscreen is active, at about 400-460 connections I get "421 4.3.2 All > > server ports are busy". > > Please do not blame the messenger of the bad news. > > POSTSCREEN tries to hand off of connections to SMTPD. You are running > into the condition where all SMTPD ports are busy. > > No amount of POSTSCREEN tweaking will prevent that. Additionally, "421 4.3.2 All screening ports are busy" means that too many clients are waiting for DNSBL/WL lookups, "greet wait" test, or other tests. A client needs to repeat a test when its result has expired. But that is not the problem that you report. Wietse
RE: TLS library problem - handshake failure
Hi again, Here is the output of postconf -n for this interface: alias_database = hash:/etc/postfix-internal/aliases alias_maps = hash:/etc/postfix-internal/aliases allow_percent_hack = no alternate_config_directories = /etc/postfix-internal, /etc/postfix-external body_checks = pcre:/etc/postfix-internal/b2b_encrypted.body_check.pcre bounce_queue_lifetime = 1d command_directory = /opt/PFXpostfix/postfix/usr/sbin/ config_directory = /etc/postfix-internal daemon_directory = /opt/PFXpostfix/postfix/usr/libexec/postfix data_directory = /var/lib/postfix-internal default_database_type = hash default_destination_concurrency_limit = 25 default_process_limit = 350 disable_vrfy_command = yes header_checks = pcre:/etc/postfix-internal/headers_mimetypes.pcre, pcre:/etc/postfix-internal/headers_compliance.pcre, pcre:/etc/postfix-internal/b2b_encrypted.header_check.pcre html_directory = no mail_owner = postfix mailbox_size_limit = 6000 mailq_path = /usr/bin/mailq manpage_directory = /opt/PFXpostfix/postfix/usr/local/man maximal_backoff_time = 5h maximal_queue_lifetime = 1d message_size_limit = 5250 mime_header_checks = pcre:/etc/postfix-internal/b2b_encrypted.header_check.pcre mydestination = $myhostname, ssng0016xmh.sng.swissbank.com, dmz-vsgate4.sng.swissbank.com, dmz-vsgate4.sng, localhost.$mydomain, localhost mydomain = ubs.com myhostname = dmz-vsgate4.sng.ibb.ubs.com mynetworks = /etc/postfix-internal/mynetworks myorigin = $mydomain nested_header_checks = newaliases_path = /usr/bin/newaliases parent_domain_matches_subdomains = queue_directory = /var/spool/postfix-internal queue_minfree = 10240 readme_directory = no sample_directory = /etc/postfix sendmail_path = /usr/lib/sendmail setgid_group = postdrop smtp_bind_address = 0.0.0.0 smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/etc/postfix-internal/ssl/smtp_session_cache smtpd_banner = $myhostname ESMTP Internal smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_block.map, check_sender_access hash:/etc/postfix/glamsenders.map, check_recipient_access, pcre:/etc/postfix-internal/smtpd_bang_reject.pcre, permit_mynetworks, reject smtpd_restriction_classes = glam smtpd_sender_restrictions = check_sender_access hash:/etc/postfix-internal/blocked_senders.map,hash:/etc/postfix-internal/domains_ok.map,reject smtpd_tls_cert_file = /etc/postfix-external/ssl2014/dmz-vsgate4.sng.pem smtpd_tls_key_file = /etc/postfix-external/ssl2014/dmz-vsgate4.sng.key swap_bangpath = no syslog_name = postfix-internal tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix-internal/transport.map unknown_local_recipient_reject_code = 550 virtual_mailbox_limit = 6000 Regards, Robin From: Wakefield, Robin Sent: 23 August 2014 00:24 To: postfix-users@postfix.org Subject: TLS library problem - handshake failure Hi, We recently upgraded from Postfix 2.5.5 to 2.8.17 and OpenSSL 0.9.8k to 1.0.1h (both compiled from source). A number of domains that we normally send to are now not working. The log is showing the following typical entries: Aug 22 23:51:37 ssng0016xmh postfix-internal/smtp[6284]: [ID 197553 mail.info] SSL_connect error to ssc-dc2-mx02.chainiq.com[193.169.186.213]:25: -1 Aug 22 23:51:37 ssng0016xmh postfix-internal/smtp[6284]: [ID 947731 mail.warning] warning: TLS library problem: error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762: Aug 22 23:51:37 ssng0016xmh postfix-internal/smtp[6284]: [ID 197553 mail.info] CE20F1099F: Cannot start TLS: handshake failure Aug 22 23:51:38 ssng0016xmh postfix-internal/smtp[6284]: [ID 197553 mail.info] SSL_connect error to ssc-dc1-mx02.chainiq.com[193.169.186.212]:25: -1 Aug 22 23:51:38 ssng0016xmh postfix-internal/smtp[6284]: [ID 947731 mail.warning] warning: TLS library problem: error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762: Aug 22 23:51:38 ssng0016xmh postfix-internal/smtp[6284]: [ID 197553 mail.info] CE20F1099F: to=mailto:a...@chainiq.com>>, relay=ssc-dc1-mx02.chainiq.com[193.169.186.212]:25, delay=3, delays=0.01/0.03/3/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) I have tried restricting smtp_tls_protocols to sslv3, and excluding tlsv1.1 and tlsv1.2, but am seeing the same result. If I try and test the connection using: openssl s_client -connect ssc-dc1-mx02.chainiq.com:25 -starttls smtp I see no error, and I get presented with the 250 STARTTLS prompt. Any thoughts on next steps without having to contact the target domains? I have read about disabling TLSEXT_TYPE_PADDING when compiling OpenSSL - would this be my next step, or was this somehow fixed in the releases we are using? Any other way I could simulate this problem, as we have had to regress the versions until this is resolved? Any help would be appreciated. Regards, Robin
Re: client hostname resolution
> On 08/26/2014 12:56 AM, Viktor Dukhovni wrote: >> Are there any reasons against using chrooted smtp ? > > Chroot jails require an expert administrator, able to trouble-shoot > problems with plugins or system libraries that depend on resources > that may not exist in the jail. > > Debian made the mistake of enabling chroot on machines operated by > relatively inexperienced users, and failing to fully automate all > the requisite chroot-jail care and feeding. I have found the problem: I had /var mounted with nosuid,nodev,noexec options. When I remount it with nosuid,dev,exec then the hostname resolving works (even when chrooted) May I ask list members an opinion? Now when chroot works, is it recommended to use it? Does it provide an extra layer of security? thanks, Martin
Re: TLS library problem - handshake failure
> Any thoughts on next steps without having to contact the target > domains? I have read about disabling TLSEXT_TYPE_PADDING when > compiling OpenSSL - would this be my next step, or was this somehow > fixed in the releases we are using? Any other way I could simulate > this problem, as we have had to regress the versions until this > is resolved? http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html "The only way to work-around this with Postfix linked to OpenSSL 1.0.1g and continue to encrypt traffic to the destinations in question is to force the use of SSLv3 only. This requires a compatible Postfix version: * >= 2.6.15 if 2.6.x * >= 2.7.9 if 2.7.x * >= 2.8.10 if 2.8.x * >= 2.9.2 if 2.9.x * 2.10.0 and up tls_policy: example.com may protocols=SSLv3 example.org encrypt protocols=SSLv3 example.org fingerprint protocols=SSLv3 match=... example.org secure protocols=SSLv3 " Wietse
Re: client hostname resolution
Martin Vegter: > > On 08/26/2014 12:56 AM, Viktor Dukhovni wrote: > >> Are there any reasons against using chrooted smtp ? > > > > Chroot jails require an expert administrator, able to trouble-shoot > > problems with plugins or system libraries that depend on resources > > that may not exist in the jail. > > > > Debian made the mistake of enabling chroot on machines operated by > > relatively inexperienced users, and failing to fully automate all > > the requisite chroot-jail care and feeding. > > I have found the problem: > > I had /var mounted with nosuid,nodev,noexec options. When I remount it > with nosuid,dev,exec then the hostname resolving works (even when chrooted) > > May I ask list members an opinion? > Now when chroot works, is it recommended to use it? Does it provide an > extra layer of security? That depends on what else is running in your system. Besides a small unprivileged Postfix network daemon inside a chroot jail, do you have other network daemons running that are large, that have full access to the file system, and that run with high privilege level? Wietse
Re: client hostname resolution
> On 08/26/2014 03:13 PM, Wietse Venema wrote: > Martin Vegter: >>> On 08/26/2014 12:56 AM, Viktor Dukhovni wrote: Are there any reasons against using chrooted smtp ? >>> >>> Chroot jails require an expert administrator, able to trouble-shoot >>> problems with plugins or system libraries that depend on resources >>> that may not exist in the jail. >>> >>> Debian made the mistake of enabling chroot on machines operated by >>> relatively inexperienced users, and failing to fully automate all >>> the requisite chroot-jail care and feeding. >> >> I have found the problem: >> >> I had /var mounted with nosuid,nodev,noexec options. When I remount it >> with nosuid,dev,exec then the hostname resolving works (even when chrooted) >> >> May I ask list members an opinion? >> Now when chroot works, is it recommended to use it? Does it provide an >> extra layer of security? > > That depends on what else is running in your system. Besides a small > unprivileged Postfix network daemon inside a chroot jail, do you > have other network daemons running that are large, that have full > access to the file system, and that run with high privilege level? I am running only Postfix and openssh-server
Re: Postscreen - max parallel incoming connections (fwd)
- Forwarded message from Stephen Satchell - > Marius Gologan: >> I'm running a stress test against Postfix, running smtp-source command with >> 1.000 parallel connections from one source IP. >> When postscreen is active, at about 400-460 connections I get "421 4.3.2 All >> server ports are busy". > > Please do not blame the messenger of the bad news. > > POSTSCREEN tries to hand off of connections to SMTPD. You are running > into the condition where all SMTPD ports are busy. > > No amount of POSTSCREEN tweaking will prevent that. Also, the problem may not be in PostFix. You may need to tune your underlying host to handle high connection loads. If you look for how to tune a server to accept massive WWW loads, the same techniques can be used to increase the number of open sockets and ephemeral port numbers available. I won't repeat what dozens of HOWTO pages would tell you. - End of forwarded message from Stephen Satchell -
Re: client hostname resolution
Martin Vegter: > >> May I ask list members an opinion? > >> Now when chroot works, is it recommended to use it? Does it provide an > >> extra layer of security? > > > > That depends on what else is running in your system. Besides a small > > unprivileged Postfix network daemon inside a chroot jail, do you > > have other network daemons running that are large, that have full > > access to the file system, and that run with high privilege level? > > I am running only Postfix and openssh-server Then, openssh-server is a more likely target. Measures that one can take are not allowing password logins, and not allowing logins from the entire Internet. That has probably a bigger security impact than running smtpd chrooted. Wietse
Postfix and multipolicy setup
Hi everybody,
I'm doing an installation of our university main mail gateway. Assume,
that with one postfix instance I want to receive mail mx-1.domain.tld
(inbound policy) and provide mail services to our employees with
smtp.domain.tld (outbound policy). My postfix instance should listen on
mx-1.domain.tld:25. There I will put postscreen in front. For outbound
mail the same instance should listen on smtp.domain.tld:{25,465.587}.
Can I get rid of configuring master.cf? If it is possible, how? If not,
what is better: put mx or smtp listeners in master.cf?
In production there will be 3 postfix instances with 2 domains being
served as mx and smtp, 1 for system itself, over 16 IP adresses (both v4
and v6) and a cluster on top of that. I need as much simple
configuration as it could be.
Thanks for any advice.
--
Pagarbiai,
Nerijus Kislauskas
KTU ITD, Litnet valdymo centras
Studentu g. 48a - 101, Kaunas
tel.: (8~37) 30 06 45
mob. tel.: 8-614-93889
e-mail.: nerijus.kislaus...@ktu.lt
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Postfix and multipolicy setup
On Tue, Aug 26, 2014 at 05:17:08PM +0300, Nerijus Kislauskas wrote:
> I'm doing an installation of our university main mail gateway. Assume,
> that with one postfix instance I want to receive mail mx-1.domain.tld
> (inbound policy)
The MX hostname is irrelevant, some machine name or other will
appear in your MX records.
> and provide mail services to our employees with
> smtp.domain.tld (outbound policy).
This submission hostname will appear in the mail client settings
of the users. Use port 587 with TLS for submission.
> My postfix instance should listen on mx-1.domain.tld:25.
That's the MX host service.
> There I will put postscreen in front. For outbound
> mail the same instance should listen on smtp.domain.tld:{25,465.587}.
For a new installation, DO NOT implement port 25 submission. Make
it only 587 and only if unavoidable 465.
> Can I get rid of configuring master.cf?
No, because the stock master.cf has the port 587 (and 465) submission
services commented out.
> If it is possible, how? If not,
> what is better: put mx or smtp listeners in master.cf?
All SMTP listener end-points go into master.cf. The postscreen
for port 25, and the submission services, plus the "smtpd pass"
service for postscreen handoff.
You can do this with a single Postfix instance, or a separate
submission instance (probably better in the long run, maybe
even on a separate machine or VM).
> In production there will be 3 postfix instances with 2 domains being
> served as mx and smtp, 1 for system itself, over 16 IP adresses (both v4
> and v6) and a cluster on top of that. I need as much simple
> configuration as it could be.
Simple is in the eye of the beholder. Read:
http://www.postfix.org/MULTI_INSTANCE_README.html
Do you prefer multiple single-purpose individually simpler
configurations, or a monolithic configuration that is more complex
internally, but centralizes all the logic? Your call.
As the author of MULTI_INSTANCE_README, I can't give an impartial
opinion.
If you have sufficiently complex requirements for submission
(different content filtering, different rewriting logic, ...)
you're better off with a separate instance most likely.
If your submission processing sufficiently closely resembles
your inbound processing, a single instance may suffice.
--
Viktor.
Is there any document about debian+postfix+dovecot+mysql?
Hi, everybody: How do you do ? I want to setup a mail server in Debian, and want to use postfix+dovecot+mysql. Is there any documents can i used? Best Regard! Leon Wei E-mail: leon...@mail.kingdest.com
Re: Is there any document about debian+postfix+dovecot+mysql?
Am 26.08.2014 um 18:21 schrieb leonwei: Hi, everybody: How do you do ? I want to setup a mail server in Debian, and want to use postfix+dovecot+mysql. Is there any documents can i used? Best Regard! Leon Wei E-mail: leon...@mail.kingdest.com Well written and comprehensive guide to start off with: https://workaround.org/ispmail/wheezy -- Alex JOST
sasl with postfix on aix
Hi I need some help getting cyrus-sasl-2.1.26 working on postfix-2.10.3 on AIX 6.1. I want to use it only for upstream authentication, that is I am not running it as a daemon on the machine, I only want postfix to use authentication when it contacts it upstream mailrelay. It appears that it does not even try to authenticate. SASL is compiled into postfix, or at least that's what 'nm /usr/libexec/postfix/smtp' shows, fx # nm /usr/libexec/postfix/smtp|grep ^smtp_sasl smtp_sasl_activate:F-1 -2548 smtp_sasl_auth_cache d 536891376 4 smtp_sasl_auth_cache.c - 2763092 smtp_sasl_auth_cache.c - 2763104 smtp_sasl_auth_cache.c - 2763134 smtp_sasl_auth_cache.c - 2763206 smtp_sasl_auth_cache.c - 2763254 smtp_sasl_auth_cache.c - 2763254 smtp_sasl_auth_cache.c - 2763290 smtp_sasl_auth_cache.c - 2763302 smtp_sasl_auth_cache.c - 2763320 smtp_sasl_auth_cache.c - 2763350 smtp_sasl_auth_cache.c f - smtp_sasl_auth_cache:S1748=*1742 - 0 smtp_sasl_auth_cache_find:F-1 - 540 smtp_sasl_auth_cache_init:F1713=*1710 - 180 smtp_sasl_auth_cache_make_pass:f74 - 0 smtp_sasl_auth_cache_store:F-11 -1216 smtp_sasl_authenticate:F-1 -1252 smtp_sasl_cleanup:F-11 -2212 smtp_sasl_connect:F-11 - 932 smtp_sasl_glue.c f - smtp_sasl_helo_auth:F-11 - 0 smtp_sasl_helo_login:F-1 - 724 smtp_sasl_impl d 536890756 4 smtp_sasl_impl:S1747=*649 - 4 smtp_sasl_initialize:F-11 - 600 smtp_sasl_mechs B 536924364 4 smtp_sasl_mechs d 536891348 4 smtp_sasl_mechs:G1749=*557 -3616 smtp_sasl_passivate:F-11 -2492 smtp_sasl_passwd_lookup:F-1 - 0 smtp_sasl_passwd_map d 536890644 4 smtp_sasl_passwd_map:S734 - 8 smtp_sasl_proto.c- 2761304 smtp_sasl_proto.c- 2761406 smtp_sasl_proto.cf - smtp_sasl_start:F-11 -1008 # ldd shows: # ldd /usr/libexec/postfix/smtp /usr/libexec/postfix/smtp needs: /usr/lib/libc.a(shr.o) /usr/lib/libdb.a(libdb.so) /usr/lib/libcrypto.a(libcrypto.so.1.0.0) /usr/lib/libssl.a(libssl.so.1.0.0) /unix /usr/lib/libcrypt.a(shr.o) /usr/lib/libpthread.a(shr_xpg5.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libpthreads.a(shr_comm.o) # # postconf -A cyrus # postconf -a cyrus dovecot # # postconf -n|grep sasl smtp_sasl_auth_enable = yes smtp_sasl_password_maps = btree:/etc/postfix/sasl/sasl_pw smtp_sasl_security_options = noanonymous, noplaintext smtp_sasl_tls_security_options = noanonymous smtpd_sasl_auth_enable = no # # cat sasl_pw [upstreamrelay]:25 user01:xxx /etc/postfix/sasl # ls -al total 40 drwx--2 root system 256 Aug 20 13:38 . drwxr-xr-x4 root system 4096 Aug 21 14:54 .. -rw---1 root system 120 Aug 20 14:03 sasl_pw -rw---1 root system 8192 Aug 21 14:56 sasl_pw.db Aug 26 13:46:49 mail:info postfix/smtpd[20250712]: connect from loopback[127.0.0.1] Aug 26 13:47:10 mail:info postfix/smtpd[20250712]: 76B8B1002F: client=loopback[127.0.0.1] Aug 26 13:47:12 mail:info postfix/cleanup[10682504]: 76B8B1002F: message-id=<20140826114710.76B8B1002F@xxx.localdomain> Aug 26 13:47:12 mail:info postfix/qmgr[23396402]: 76B8B1002F: from=, size=325, nrcpt=1 (queue active) Aug 26 13:47:12 mail:info postfix/smtp[10813452]: Verified TLS connection established to upstreamrelay[xx.xx.xx.xx]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Aug 26 13:47:13 mail:info postfix/smtpd[20250712]: disconnect from loopback[127.0.0.1] Aug 26 13:47:24 mail:info postfix/smtp[10813452]: 76B8B1002F: to=, relay=upstreamrelay[xx.xx.xx.xx]:25, delay=19, delays=6.8/0.02/0.34/12, dsn=5.7 .1, status=bounced (host [xxx.xxx.xxx.xx] said: 554 5.7.1 : Relay access denied (in reply to RCPT TO command)) Aug 26 13:47:24 x mail:info postfix/cleanup[10682504]: D8CEA10036: message-id=<20140826114724.D8CEA10036@xxx.localdomain> Aug 26 13:47:24 x mail:info postfix/bounce[25362678]: 76B8B1002F: sender non-delivery notification: D8CEA10036 Aug 26 13:47:24 x mail:info postfix/qmgr[23396402]: D8CEA10036: from=<>, size=2362, nrcpt=1 (queue active) Aug 26 13:47:24 xx mail:info postfix/qmgr[23396402]: 76B8B1002F: removed It does not say the password in sasl_pw is wrong, it just says I am not allowed to relay. In the logfile on the upstream relay it says "client dropped", again like I am not even attempting to authenticate. Can I get postfix to show more about what it actually happening? Thanks in advance, Ole M Denmark
Re: Apply a redirect before checking other restrictions
On 8/22/2014 4:17 AM, Wietse Venema wrote: Darren Pilgrim: Postfix doesn't appear to do alias resolution on the REDIRECT'ed address. Do I need to add something to a setting that controls lookups on redirects? REDIRECT addresses are currently not subject to "before queue" address rewriting. There exists no code do do that. This is a real problem that means redirect addresses can't be everything a normal envelope recipient can be. In my case, the redirected address is a role. It must be resolved to real recipients for delivery. Would it be a lot of effort to not treat redirect addresses differently in this regard?
Re: sasl with postfix on aix
On Tue, Aug 26, 2014 at 08:33:22PM +0200, Ole Heiberg Michaelsen wrote: > # cat sasl_pw > [upstreamrelay]:25 user01:xxx Is the nexthop relay (relayhost in main.cf or transport nexthop) specified as: 1. upstreamrelay 2. [upstreamrelay] 3. upstreamrelay:25 4. [upstreamrelay]:25 Anything other than "4" will not match the sasl_pw table. > Aug 26 13:47:12 mail:info postfix/smtp[10813452]: Verified TLS > connection established to upstreamrelay[xx.xx.xx.xx]:25: TLSv1 with cipher > DHE-RSA-AES256-SHA (256/256 bits) > Aug 26 13:47:24 mail:info postfix/smtp[10813452]: 76B8B1002F: > to=, relay=upstreamrelay[xx.xx.xx.xx]:25, delay=19, > delays=6.8/0.02/0.34/12, dsn=5.7 .1, status=bounced (host > [xxx.xxx.xxx.xx] said: 554 5.7.1 : Relay > access denied (in reply to RCPT TO command)) Sure looks no attempt to authenticate. Almost certainly because the nexthop is not *verbatim* what is in the sasl_pw table. -- Viktor.
Re: Apply a redirect before checking other restrictions
Darren Pilgrim: > On 8/22/2014 4:17 AM, Wietse Venema wrote: > > Darren Pilgrim: > >> Postfix doesn't appear to do alias resolution on the REDIRECT'ed > >> address. Do I need to add something to a setting that controls > >> lookups on redirects? > > > > REDIRECT addresses are currently not subject to "before queue" > > address rewriting. There exists no code do do that. > > This is a real problem that means redirect addresses can't be everything > a normal envelope recipient can be. In my case, the redirected address > is a role. It must be resolved to real recipients for delivery. > > Would it be a lot of effort to not treat redirect addresses differently > in this regard? That would require major surgery. Since you are willing to replace your Postfix installation, I suggest that you replace it with a version that supports smtp_command_filter. That feature can replace the entire RCPT TO command as outlined in my earlier response. Wietse
Re: Apply a redirect before checking other restrictions
On 8/26/2014 12:12 PM, Wietse Venema wrote: Darren Pilgrim: On 8/22/2014 4:17 AM, Wietse Venema wrote: Darren Pilgrim: Postfix doesn't appear to do alias resolution on the REDIRECT'ed address. Do I need to add something to a setting that controls lookups on redirects? REDIRECT addresses are currently not subject to "before queue" address rewriting. There exists no code do do that. This is a real problem that means redirect addresses can't be everything a normal envelope recipient can be. In my case, the redirected address is a role. It must be resolved to real recipients for delivery. Would it be a lot of effort to not treat redirect addresses differently in this regard? That would require major surgery. Ok. Since you are willing to replace your Postfix installation, I suggest that you replace it with a version that supports smtp_command_filter. That feature can replace the entire RCPT TO command as outlined in my earlier response. I'm already running 2.11. As for smtp_command_filter, I couldn't find it. I did find smtpd_command_filter, though. If I don't follow-up this thread, it worked (or I failed a beer truck test).
Some people sending to us getting 451 4.3.5 Server configuration rejections
Our mail server is still getting a nice steady supply of email, so I didn't
realize anything was wrong. The a freind said that emails from her office
address were getting rejected. I checked the logs and noticed that she
wasn't the only one getting the message.
Before the line below, my friend's emails pass spf successfully. This is
what's showing up in the logs:
Aug 25 05:24:27 carson postfix/smtpd[27028]: NOQUEUE: reject: RCPT from
mail-ig0-f175.google.com[209.85.213.175]: 451 4.3.5 Server configuration
problem; from= to= proto=ESMTP
helo=
I don't want to go tinkering too much in my .cf files before I see if you
guys see any red flags. Again, vast number of emails getting through but
there are enough being rejected from various sources (some known to me as
business contacts/friends) that I better check this out.
I appreciate any help.
Here's the result of postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = ipv4
mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m
"${EXTENSION}"
mailbox_size_limit = 0
myhostname = carson.example.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
policy-spf_time_limit = 3600s
readme_directory = no
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = carson.example.com ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions =
reject_invalid_hostname,reject_non_fqdn_hostname,reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,check_policy_service
unix:private/policy-spf,reject_rbl_client zen.spamhaus.org,reject_rbl_client
bl.spamcop.net,reject_rbl_client cbl.abuseat.org,check_policy_service inet:
127.0.0.1:10023
smtpd_relay_restrictions =
permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = check_sender_access
hash:/etc/postfix/valid_senders, reject_unknown_sender_domain
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/private/ssl-chain-mail-example.pem
smtpd_tls_ciphers = high
smtpd_tls_key_file = /etc/ssl/private/ssl-key-decrypted-mail-example.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
virtual_gid_maps = static:5000
virtual_mailbox_base = /home/vmail
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 1000
virtual_uid_maps = static:5000
Thanks.
Re: Some people sending to us getting 451 4.3.5 Server configuration rejections
Ian Evans: > Our mail server is still getting a nice steady supply of email, so I didn't > realize anything was wrong. The a freind said that emails from her office > address were getting rejected. I checked the logs and noticed that she > wasn't the only one getting the message. > > Before the line below, my friend's emails pass spf successfully. This is > what's showing up in the logs: > > > Aug 25 05:24:27 carson postfix/smtpd[27028]: NOQUEUE: reject: RCPT from > mail-ig0-f175.google.com[209.85.213.175]: 451 4.3.5 Server configuration > problem; from= to= proto=ESMTP > helo= Postfix also logged a warning with details of the problem. http://www.postfix.org/DEBUG_README.html#logging Wietse
Re: Some people sending to us getting 451 4.3.5 Server configuration rejections
On Tue, Aug 26, 2014 at 7:21 PM, Wietse Venema wrote: > Ian Evans: > > Our mail server is still getting a nice steady supply of email, so I > didn't > > realize anything was wrong. The a freind said that emails from her office > > address were getting rejected. I checked the logs and noticed that she > > wasn't the only one getting the message. > > > > Before the line below, my friend's emails pass spf successfully. This is > > what's showing up in the logs: > > > > > > Aug 25 05:24:27 carson postfix/smtpd[27028]: NOQUEUE: reject: RCPT from > > mail-ig0-f175.google.com[209.85.213.175]: 451 4.3.5 Server configuration > > problem; from= to= proto=ESMTP > > helo= > Have very tired eyes today (up all night doing Emmy coverage) but there seems to be some issue with: Aug 26 08:34:05 carson postfix/smtpd[16374]: warning: problem talking to server private/policy-spf: Connection timed out Checking further I'm seeing: Aug 26 08:34:58 carson policyd-spf[16383]: Traceback (most recent call last): Aug 26 08:34:58 carson policyd-spf[16383]: File "/usr/bin/policyd-spf", line 690, in Aug 26 08:34:58 carson policyd-spf[16383]: sys.stdout.flush() Aug 26 08:34:58 carson policyd-spf[16383]: BrokenPipeError: [Errno 32] Broken pipe Aug 26 08:34:58 carson postfix/spawn[16382]: warning: command /usr/bin/policyd-spf exit status 1 So if emails get checked for spf, why would the vast majority get through and others cause this? Thanks.
Re: Some people sending to us getting 451 4.3.5 Server configuration rejections
Ian Evans: > Aug 26 08:34:05 carson postfix/smtpd[16374]: warning: problem talking to > server private/policy-spf: Connection timed out This Postfix SMTP server time limit is specified with the smtpd_policy_service_timeout parameter (default: 100s). Your SPF script should reply in 10 seconds at most. It should not wait indefinitely for a DNS reply. Once the Postfix SMTP server gives up, it closes the connection to the policy daemon. Then the Python script has an error while sending the (too late) result. > Aug 26 08:34:58 carson policyd-spf[16383]: Traceback (most recent call > last): > Aug 26 08:34:58 carson policyd-spf[16383]: File "/usr/bin/policyd-spf", > line 690, in > Aug 26 08:34:58 carson policyd-spf[16383]: sys.stdout.flush() > Aug 26 08:34:58 carson policyd-spf[16383]: BrokenPipeError: [Errno 32] > Broken pipe > Aug 26 08:34:58 carson postfix/spawn[16382]: warning: command > /usr/bin/policyd-spf exit status 1 > > So if emails get checked for spf, why would the vast majority get through > and others cause this? First. the script should limit the time for DNS lookups. Second, the script should not die after BrokenPipeError exceptions. try: sys.stdout.flush() except BrokenPipeError: pass Wietse
Re: Some people sending to us getting 451 4.3.5 Server configuration rejections
On Tue, Aug 26, 2014 at 8:21 PM, Wietse Venema wrote: > Ian Evans: > > Aug 26 08:34:05 carson postfix/smtpd[16374]: warning: problem talking to > server private/policy-spf: Connection timed out > > This Postfix SMTP server time limit is specified with the > smtpd_policy_service_timeout parameter (default: 100s). > > Your SPF script should reply in 10 seconds at most. It should not > wait indefinitely for a DNS reply. > > Once the Postfix SMTP server gives up, it closes the connection to > the policy daemon. Then the Python script has an error while sending > the (too late) result. > > > Aug 26 08:34:58 carson policyd-spf[16383]: Traceback (most recent call > > last): > > Aug 26 08:34:58 carson policyd-spf[16383]: File "/usr/bin/policyd-spf", > > line 690, in > > Aug 26 08:34:58 carson policyd-spf[16383]: sys.stdout.flush() > > Aug 26 08:34:58 carson policyd-spf[16383]: BrokenPipeError: [Errno 32] > > Broken pipe > > Aug 26 08:34:58 carson postfix/spawn[16382]: warning: command > > /usr/bin/policyd-spf exit status 1 > > > > So if emails get checked for spf, why would the vast majority get through > > and others cause this? > > First. the script should limit the time for DNS lookups. > > Second, the script should not die after BrokenPipeError exceptions. > > try: sys.stdout.flush() > except BrokenPipeError: pass > > > Again, since I'm tired, I just want to be sure I understand...are you suggesting I edit /usr/bin/policyd-spf and add that? If so, isn't that a pretty standard add-on and if so, wouldn't a lot of others be seeing this? I just want to make sure this is actually the issue since some of the emails rejected are from business contacts. Thanks so much for your help.
Re: Some people sending to us getting 451 4.3.5 Server configuration rejections
On Tue, Aug 26, 2014 at 8:21 PM, Wietse Venema wrote: > Ian Evans: > > Aug 26 08:34:05 carson postfix/smtpd[16374]: warning: problem talking to > server private/policy-spf: Connection timed out > > This Postfix SMTP server time limit is specified with the > smtpd_policy_service_timeout parameter (default: 100s). > > Your SPF script should reply in 10 seconds at most. It should not > wait indefinitely for a DNS reply. > > Once the Postfix SMTP server gives up, it closes the connection to > the policy daemon. Then the Python script has an error while sending > the (too late) result. > > > Aug 26 08:34:58 carson policyd-spf[16383]: Traceback (most recent call > > last): > > Aug 26 08:34:58 carson policyd-spf[16383]: File "/usr/bin/policyd-spf", > > line 690, in > > Aug 26 08:34:58 carson policyd-spf[16383]: sys.stdout.flush() > > Aug 26 08:34:58 carson policyd-spf[16383]: BrokenPipeError: [Errno 32] > > Broken pipe > > Aug 26 08:34:58 carson postfix/spawn[16382]: warning: command > > /usr/bin/policyd-spf exit status 1 > > > > So if emails get checked for spf, why would the vast majority get through > > and others cause this? > > First. the script should limit the time for DNS lookups. > > Second, the script should not die after BrokenPipeError exceptions. > > try: sys.stdout.flush() > except BrokenPipeError: pass > > > > Making this change gave me: Aug 26 22:37:03 carson postfix/spawn[24709]: warning: command /usr/bin/policyd-spf exit status 1 Aug 26 22:37:03 carson postfix/smtpd[24704]: warning: premature end-of-input on private/policy-spf while reading input attribute name Aug 26 22:37:04 carson postfix/smtpd[24704]: warning: premature end-of-input on private/policy-spf while reading input attribute name Aug 26 22:37:04 carson postfix/smtpd[24704]: warning: problem talking to server private/policy-spf: Connection reset by peer
