found a "bug" on postfix 2.9.1
OS:Gentoo latest built with kernel 3.2.1 with hardened profile POSTFIX: v 2.9.1 when i'm configuring on master.cf some listening to port on ip address that doesn't exist on any interface such as for communicating with amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 ) postfix will try to bind the port\ip and will not run or log useful information to understand whats wrong extactly. then you can't find any process of postfix using ps top or any other tool but postfix will say that it is still running and the only way i managed to make postfix work is to fix the master.cf and rebooting the machine\os. Thanks, Eliezer
Re: postfix-users@postfix.org: difference between "verify" and "secure"
On 05.03.2012 19:39, Wietse Venema wrote: >> 366AE26E2B: to=, relay=s2.mydomain.de[192.168.1.1]:25, >> ..., dsn=4.7.5, status=deferred (Server certificate not verified) >> == >> >> So my understanding of the difference between "verify" and "secure" >> seems to be wrong. Could someone please explain this? > Both "verify" and "secure" fail when the certificate signature can't > be verified. Sorry, I'm still lost: /etc/postfix/transport: test1.prv smtp:[s2.mydomain.de] /etc/postfix/tls_policy: [s2.mydomain.de]verify == s2.mydomain.de[192.168.1.1]:25: Trusted subject_CN=s1.mydomain.de, issuer_CN=Thawte DV SSL CA Trusted TLS connection established to s2.mydomain.de[192.168.1.1]:25: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA 6F68526E2E: to=, relay=s2.mydomain.de[170.1.1.1]:25, ..., dsn=4.7.5, status=deferred (Server certificate not verified) == And now: /etc/postfix/tls_policy: [s2.mydomain.de] verify match=s1.mydomain.de (nothing changed on the server side) == s2.mydomain.de[192.168.1.1]:25: Matched subject_CN=s1.mydomain.de, issuer_CN=Thawte DV SSL CA Verified TLS connection established to s2.mydomain.de[192.168.1.1]:25: TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA 6F68526E2E: to=, relay=s2.mydomain.de[170.1.1.1]:25, ..., dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5CF654330) == So: it looks to me like I got a server certificate which can be verified. It's just that its CN does not match the server name, but that should be ok when using "verify" (and not when using "secure"). Instead, "verify" and "secure" are behaving in the same way: they only work when the "match" clause is configured. Regards, Robert
LDAP aliases
Hello I have a small problem with LDAP aliases at 2.9.1 but cannot find what I missed ... in main.cf I have the following alias_maps = hash:/etc/mail/aliases, ldap:/usr/local/etc/postfix/ldap-aliases.cf in ldap-aliases.cf I have the following server_host = my.ldap.server search_base = ou=Users,dc=xxx,dc=xx query_filter = mail=%s result_attribute = uid version = 3 the LDAP lookup is OK, bonj is the uid and jean.bon is the LDAP alias postmap -q "jean@xxx.xx" ldap:/usr/local/etc/postfix/ldap-aliases.cf bonj But when I send an email to jean@xxx.xx Postfix return a "jean.bon unknown user" error. What did I forgot in configuration to make the reverse mapping ALIAS --> UID working ? Thanks
Re: found a "bug" on postfix 2.9.1
Eliezer Croitoru: > OS:Gentoo latest built with kernel 3.2.1 with hardened profile > POSTFIX: v 2.9.1 > when i'm configuring on master.cf some listening to port on ip address > that doesn't exist on any interface such as for communicating with > amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 ) > postfix will try to bind the port\ip and will not run or log useful > information to understand whats wrong extactly. > then you can't find any process of postfix using ps top or any other > tool but postfix will say that it is still running and the only way i > managed to make postfix work is to fix the master.cf and rebooting the > machine\os. To report a problem, please follow instructions in the mailing list welcome message. Instead of an eye witness report, provide concrete evidence from the configuration and logfiles. Like this: /etc/postfix/master.cf: 1.2.3.4:25 inet n - n - 1 whatever # postfix stop # postfix start # tail -3 /var/log/maillog Mar 6 06:53:25 tail postfix/master[60082]: terminating on signal 15 Mar 6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix mail system Mar 6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: Can't assign requested address Wietse
Re: found a "bug" on postfix 2.9.1
Wietse Venema: > Eliezer Croitoru: > > OS:Gentoo latest built with kernel 3.2.1 with hardened profile > > POSTFIX: v 2.9.1 > > when i'm configuring on master.cf some listening to port on ip address > > that doesn't exist on any interface such as for communicating with > > amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 ) > > postfix will try to bind the port\ip and will not run or log useful > > information to understand whats wrong extactly. > > then you can't find any process of postfix using ps top or any other > > tool but postfix will say that it is still running and the only way i > > managed to make postfix work is to fix the master.cf and rebooting the > > machine\os. > > To report a problem, please follow instructions in the mailing > list welcome message. Instead of an eye witness report, provide > concrete evidence from the configuration and logfiles. > > Like this: > > /etc/postfix/master.cf: > 1.2.3.4:25 inet n - n - 1 whatever > > # postfix stop > # postfix start > # tail -3 /var/log/maillog > Mar 6 06:53:25 tail postfix/master[60082]: terminating on signal 15 > Mar 6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix mail > system > Mar 6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: Can't > assign requested address Also: # postfix status postfix/postfix-script: the Postfix mail system is not running If you can post your evidence, then we can look for differences. Wietse
Re: LDAP aliases
On Tue, Mar 6, 2012 at 8:36 AM, Frank Bonnet wrote: > > in main.cf I have the following > > alias_maps = hash:/etc/mail/aliases, > ldap:/usr/local/etc/postfix/ldap-aliases.cf > > in ldap-aliases.cf I have the following > > server_host = my.ldap.server > search_base = ou=Users,dc=xxx,dc=xx > query_filter = mail=%s > result_attribute = uid > version = 3 > > the LDAP lookup is OK, bonj is the uid and jean.bon is the LDAP alias > > postmap -q "jean@xxx.xx" ldap:/usr/local/etc/postfix/ldap-aliases.cf > bonj > > But when I send an email to jean@xxx.xx Postfix return > a "jean.bon unknown user" error. > > What did I forgot in configuration to make the reverse mapping > ALIAS --> UID working ? > Alas maps query don't have domain part. You need test: postmap -q "jean.bon" ldap:/usr/local/etc/postfix/ldap-aliases.cf -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net "While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)
Re: found a "bug" on postfix 2.9.1
On Tue, 06 Mar 2012 12:37:02 +0200 Eliezer Croitoru articulated: > OS:Gentoo latest built with kernel 3.2.1 with hardened profile > POSTFIX: v 2.9.1 > when i'm configuring on master.cf some listening to port on ip > address that doesn't exist on any interface such as for communicating > with amavis (as if my ip is 192.168.0.20 and i will put > 192.168.0.21:25 ) postfix will try to bind the port\ip and will not > run or log useful information to understand whats wrong extactly. > then you can't find any process of postfix using ps top or any other > tool but postfix will say that it is still running and the only way i > managed to make postfix work is to fix the master.cf and rebooting > the machine\os. You need to provide the proper information to debug a possible bug. Start here: http://www.postfix.com/DEBUG_README.html Be sure to read this part thoroughly: http://www.postfix.com/DEBUG_README.html#mail Report back with the requested information and then someone can possibly assist you. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: Relay access denied problem
On Mar 5, 2012, at 8:41 PM, David Renstrom wrote: > Hi, > > I've set up a mail server with Postfix and Dovecot using virtual mailboxes. > I'm now trying to get mailman to work together with Postfix which has turned > out to be harder than I thought. :( ... > I think I have entered everything correctly in main.cf but I'm not sure. The > file /etc/postfix/transport (used for transport_maps) directs incoming list > emails to the local delivery agent. See further down for the current > configuration. THis part is more appropriate to the Mailman list but why are you sending list mail to the local delivery agent? Standard Mailman practice is to use aliases to pipe list mail to Mailman. That you're doing it via a transport map suggests that you're not following Mailman documentation and that there may be other things you have done non-standard which may be related to your relay denied problem. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 07:03:04AM -0500, Wietse Venema wrote: > > /etc/postfix/master.cf: > > 1.2.3.4:25 inet n - n - 1 whatever > > > > # postfix stop > > # postfix start > > # tail -3 /var/log/maillog > > Mar 6 06:53:25 tail postfix/master[60082]: terminating on signal 15 > > Mar 6 06:53:28 tail postfix/postfix-script[4760]: starting the Postfix > > mail system > > Mar 6 06:53:28 tail postfix/master[4761]: fatal: bind 1.2.3.4 port 25: > > Can't assign requested address > > Also: > > # postfix status > postfix/postfix-script: the Postfix mail system is not running # grep 1.2.3.4 /etc/postfix/master.cf 1.2.3.4:25 inet n - n - - smtpd # postfix start postfix/postfix-script: starting the Postfix mail system # echo $? 0 # tail -n2 /var/log/everything/current Mar 06 14:31:45 [postfix/postfix-script] starting the Postfix mail system Mar 06 14:31:45 [postfix/master] fatal: bind 1.2.3.4 port 25: Cannot assign requested address The return code of zero from postfix start trips the init script. OP should run "/etc/init.d/postfix zap" to return postfix to stopped state, correct master.cf and start postfix again. This is arguably no different from any number of configuration errors resulting in a non working setup. In any case, bugs.gentoo.org or a gentoo mailing list is probably the correct place for this discussion. -- Eray Aslan
Re: LDAP aliases
On 03/06/2012 01:09 PM, Reinaldo de Carvalho wrote: On Tue, Mar 6, 2012 at 8:36 AM, Frank Bonnet wrote: in main.cf I have the following alias_maps = hash:/etc/mail/aliases, ldap:/usr/local/etc/postfix/ldap-aliases.cf in ldap-aliases.cf I have the following server_host = my.ldap.server search_base = ou=Users,dc=xxx,dc=xx query_filter = mail=%s result_attribute = uid version = 3 the LDAP lookup is OK, bonj is the uid and jean.bon is the LDAP alias postmap -q "jean@xxx.xx" ldap:/usr/local/etc/postfix/ldap-aliases.cf bonj But when I send an email to jean@xxx.xx Postfix return a "jean.bon unknown user" error. What did I forgot in configuration to make the reverse mapping ALIAS --> UID working ? Alas maps query don't have domain part. You need test: postmap -q "jean.bon" ldap:/usr/local/etc/postfix/ldap-aliases.cf OK corrected , thank you .
Re: found a "bug" on postfix 2.9.1
Eray Aslan: > # postfix start > postfix/postfix-script: starting the Postfix mail system > # echo $? > 0 As documented in the Postfix manpage: start Start the Postfix mail system. This also runs the configuration check described above. status Indicate if the Postfix mail system is currently running. Init/upstart/systemd/launchpad/whatever scripts are OS-specific. They are not part of Postfix. They are the responsibility of the OS-specific port maintainer. I would also like to reiterate that the "postfix" command is the sole supported interface for starting and stopping Postfix. All support of Postfix is canceled when start/stop/status are managed by direct manipulation of the Postfix master daemon. Wietse
Re: complex policy -- how best to implement in Postfix?
On Mon, Mar 05, 2012 at 08:05:54PM -0500, Wietse Venema wrote: > Ben Rosengart: > > On Mon, Mar 05, 2012 at 02:30:16PM -0500, Wietse Venema wrote: > > > Ben Rosengart: > > > > > then use smtp_generic_maps, to convert from the Postfix-canonical > > > > > form to that specific external form. > > > > > > > > So use transport(5)? If I want to rewrite to form x, use transport x > > > > and > > > > x_generic_maps, and then transport y and y_generic_maps for form y, etc? > > > > > > Yes. I did context-dependent output rewriting in Sendmail many years > > > before I got involved with Postfix. > > > > Alright. I have an ldap_table(5)-based map which, I have verified, > > returns "sometransport:" when the input key corresponds to one type of > > LDAP object, and "" otherwise. This is good, I think. > > > > However, the input key needs to be the sender address -- so should I > > be using sender_dependent_default_transport_maps? transport(5) is not, > > as far as I can tell, going to do it for me. > > You need to rewrite (sender and non-sender) addresses based on the sender? Just sender addresses. -- Ben Rosengart "Like all those possessing a library, Sendmail, Inc. Aurelian was aware that he was guilty of +1 718 431 3822 not knowing his in its entirety [...]" -- Jorge Luis Borges NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote: >start Start the Postfix mail system. This also runs the configuration > check described above. > >status Indicate if the Postfix mail system is currently running. This does introduce a non-negligible delay in startup for everyone but yes, it is better. Thanks. > I would also like to reiterate that the "postfix" command is the > sole supported interface for starting and stopping Postfix. Aye, noted. -- Eray Aslan
Re: postfix-users@postfix.org: difference between "verify" and "secure"
On Tue, Mar 06, 2012 at 11:52:54AM +0100, Robert Dahlem wrote: > /etc/postfix/transport: > test1.prv smtp:[s2.mydomain.de] > /etc/postfix/tls_policy: > [s2.mydomain.de]verify > == > s2.mydomain.de[192.168.1.1]:25: Trusted subject_CN=s1.mydomain.de, > issuer_CN=Thawte DV SSL CA > Trusted TLS connection established to s2.mydomain.de[192.168.1.1]:25: > TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA > 6F68526E2E: to=, relay=s2.mydomain.de[170.1.1.1]:25, > ..., dsn=4.7.5, status=deferred (Server certificate not verified) > == The trust chain is valid but the name does not match, so the verification fails. > /etc/postfix/tls_policy: > [s2.mydomain.de] verify match=s1.mydomain.de > == > s2.mydomain.de[192.168.1.1]:25: Matched subject_CN=s1.mydomain.de, > issuer_CN=Thawte DV SSL CA > Verified TLS connection established to s2.mydomain.de[192.168.1.1]:25: > TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA > 6F68526E2E: to=, relay=s2.mydomain.de[170.1.1.1]:25, > ..., dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5CF654330) > == The trust chain is still valid, but now the name matches so verification succeeds. > So: it looks to me like I got a server certificate which can be > verified. No, it is a certificate whose trust chain is valid and anchored at a trusted root, but this is meaningless, anyone can get a certificate with a valid trust chain, just verifying the trust chain is silly. > It's just that its CN does not match the server name, but that > should be ok when using "verify" (and not when using "secure"). Considering that Postfix documentation does not say this, and clearly states the opposite, you're just overloading your wishful interpretation of these words with total disregard for the documentation. > Instead, "verify" and "secure" are behaving in the same way: they only > work when the "match" clause is configured. Exactly as documented. They differ only in the matching strategy. Yes, I have in the past observed, though perhaps in offlist conversation, that there should perhaps not have been separate "verify" and "secure" levels, rather just "verify" could have been enough with a default matching strategy that is the same as the current "secure", and anyone who wanted (less secure MX) "hostname" matching could just tweak the matching rules. So "secure" is perhaps a minor design error, but on the other hand it serves to emphasize that "hostname" matching is rather different from "nexthop" matching, and the former is not MITM resistant, which after all is the entire purpose of all the X.509 baggage. If you are bothering with certs, you may as well get your money's worth. Otherwise, just do anonymous TLS, or install self-signed certs, you get passive-eavesdropping resistance from that with much less fuss and no tax paid to the usual cabal of public CAs. -- Viktor.
Re: found a "bug" on postfix 2.9.1
Eray Aslan: > On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote: > >start Start the Postfix mail system. This also runs the configuration > > check described above. > > > >status Indicate if the Postfix mail system is currently running. > > This does introduce a non-negligible delay in startup for everyone but > yes, it is better. Thanks. I think that making everyone wait would be another example of well-meaning people doing things that give Postfix a bad reputation. Examples of common maintainer-induced damage: - Turning on IPv6 by default. SUSE does this, making remote destinations unreachable that have five or more IPv6 addresses. Postfix 2.9 has a defense for such brain damage. - Turning on chroot by default. Many Debian etc. users get into trouble when they make an innocuous configuration change to the SMTP daemon. Postfix has no defense for this brain damage. Wietse
Re: [SPAM] Re: found a "bug" on postfix 2.9.1
Le 06/03/2012 17:48, Wietse Venema a écrit : Eray Aslan: On Tue, Mar 06, 2012 at 08:40:16AM -0500, Wietse Venema wrote: start Start the Postfix mail system. This also runs the configuration check described above. status Indicate if the Postfix mail system is currently running. This does introduce a non-negligible delay in startup for everyone but yes, it is better. Thanks. I think that making everyone wait would be another example of well-meaning people doing things that give Postfix a bad reputation. Examples of common maintainer-induced damage: I thought that every packet maintainer would contact you before hand to have a "procedure" ? I am so naif sometimes Stéphane - Turning on IPv6 by default. SUSE does this, making remote destinations unreachable that have five or more IPv6 addresses. Postfix 2.9 has a defense for such brain damage. - Turning on chroot by default. Many Debian etc. users get into trouble when they make an innocuous configuration change to the SMTP daemon. Postfix has no defense for this brain damage. Wietse
submission users still rejected by zen
Hi,
I have a postfix-2.8.7 system with amavisd on fedora15 and am having
some problems with users being rejected by zen even when connecting to
the server using the submission port. I believe this has to do with my
smtpd_client_restrictions being incorrect. Because of the way in which
I have the ordering, I've had to duplicate the check_client_access and
check_sender_access because my original location wasn't effective. I'm
just confused.
Probably unrelated, but another issue I'm having is the always_bcc
user mail is being duplicated. I've found references to "-o
smtp_send_xforward_command=yes" being used to prevent duplicated mail
for always_bcc, but I must be doing something wrong here too.
I've just noticed I'm using reject_rbl_client and have postscreen
using the RBLs as well. I'll remove the ones from the
smtpd_client_restrictions, but could this possibly be causing mail to
be rejected even when connecting via the submission port?
Mar 6 05:29:28 portal postfix/smtpd[21316]: NOQUEUE: reject: RCPT
from cpe-76-181-55-14.columbus.res.rr.com[76.XXX.YYY.14]: 554 5.7.1
Service unavailable; Client host [76.XXX.YYY.14] blocked using
zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=76.XXX.YYY.14;
from= to= proto=ESMTP
helo=
Any ideas greatly appreciated.
--System Parameters--
mail_version = 2.8.7
hostname = portal.example.com
uname = Linux portal.example.com 2.6.41.10-3.fc15.x86_64 #1 SMP Mon
Jan 23 15:46:37 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
--Packaging information--
looks like this postfix comes from RPM package: postfix-2.8.7-1.fc15.x86_64
--main.cf non-default parameters--
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_mail_to_files = alias,forward
always_bcc = bcc-user
biff = no
body_checks = regexp:/etc/postfix/body_checks.pcre
bounce_queue_lifetime = 2d
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 140
delay_warning_time = 4h
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
initial_destination_concurrency = 20
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 82120
manpage_directory = /usr/share/man
maximal_queue_lifetime = 2d
message_size_limit = 5024
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = $myhostname, localhost.$mydomain
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 68.XXX.YYY.40/29,
64.XXX.YYY.0/27, 66.XXX.YYY.96/28, 204.XXX.YYY.0/24
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1
b.barracudacentral.org*1
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
readme_directory = /usr/share/doc/postfix-2.8.7/README_FILES
relay_domains = $mydestination, $transport_maps
sample_directory = /usr/share/doc/postfix-2.8.7/samples
smtpd_authorized_xforward_hosts = $mynetworks
smtpd_client_restrictions = check_client_access
cidr:/etc/postfix/sinokorea.cidr, check_client_access
cidr:/etc/postfix/asian-ip5.txt
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
check_client_access hash:/etc/postfix/client_checks_special,
check_sender_access hash:/etc/postfix/sender_checks_special,
reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination, reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_helo_hostname, check_recipient_access
pcre:/etc/postfix/relay_recips_ecartis, check_client_access
hash:/etc/postfix/client_checks, check_sender_access
hash:/etc/postfix/sender_checks, check_recipient_access
pcre:/etc/postfix/relay_recips_access, reject_rbl_client
zen.spamhaus.org, reject_rbl_client psbl.surriel.com, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/newcert/example-startssl-cert.pem
smtpd_tls_key_file = /etc/postfix/newcert/example-startssl.key
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
smtp_send_xforward_command = yes
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
--master.cf--
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
dovecot unix - n n - - pipe
Re: postfix-users@postfix.org: difference between "verify" and "secure"
On 06.03.2012 16:57, Viktor Dukhovni wrote: >> It's just that its CN does not match the server name, but that >> should be ok when using "verify" (and not when using "secure"). > Considering that Postfix documentation does not say this, and > clearly states the opposite, you're just overloading your wishful > interpretation of these words with total disregard for the > documentation. Ouch. I may have deserved that. :-) After reading a bit more about smtp_tls_verify_cert_match and smtp_tls_secure_cert_match let's see if I understand better now: Default strategy for "verify": ask DNS about MX, then check if the servers CN matches. Check if the trust chain is valid. Default strategy for "secure": accept any CN presented by the server if that is the domain or a subdomain of the recipient address or the canonized hostname from the transport table. Do not add MX names looked up in DNS to the list of feasible CNs. Check if the trust chain is valid. Both can be overridden in tls_policy with the match attribute. Real world example: two organizations agree upon mandatory TLS. A list of domains requiring TLS and a list of MX hosts are transmitted. Each side configures: /etc/postfix/tls_policy: first-otherdomain XXX match=mx1:mx2 .first-otherdomain XXX match=mx1:mx2 second-otherdomain XXX match=mx1:mx2 .second-otherdomain XXX match=mx1:mx2 XXX may be "verify" or "secure", it is overridden by "match" anyway. Regards, Robert
How to delete a key via postconf
With the newer postfix releases (such as 2.9.x), some keys only exist when a feature is enabled. For example: policy_time_limit If I set policy_time_limit and then later disable using a policy, I can't find a way to get it deleted from main.cf with postconf. If I set it to an empty value, it still exists, and postconf will throw an error about it being an unused key: /opt/zimbra/postfix/sbin/postconf: warning: /opt/zimbra/postfix-2.9.0.2z/conf/main.cf: unused parameter: policy_time_limit= I stumbled across the -# option to postconf, but this is undesirable, because it can lead to multiple lines in a main.cf file, like: smtp_sasl_auth_enable = no #policy_time_limit = mailbox_size_limit = 0 disable_dns_lookups = no smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031 policy_time_limit = 3600 if you choose to later re-enable it using a policy. Is there some command or option I'm missing that would allow me to permanently remove a key/value pair using postconf from main.cf? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: How to delete a key via postconf
Quanah Gibson-Mount: > With the newer postfix releases (such as 2.9.x), some keys only exist when > a feature is enabled. For example: policy_time_limit Correct. > If I set policy_time_limit and then later disable using a policy, I can't > find a way to get it deleted from main.cf with postconf. If I set it to an > empty value, it still exists, and postconf will throw an error about it > being an unused key: > > /opt/zimbra/postfix/sbin/postconf: warning: > /opt/zimbra/postfix-2.9.0.2z/conf/main.cf: unused parameter: > policy_time_limit= Specifying an empty value does not make the parameter go away. Many parameters can heva an empty value. Some even have it as the default. To remove all instances of a parameter: Before: /etc/postfix/main.cf: policy_time_limit = foo policy_time_limit = bar Command: # postconf -# policy_time_limit After: /etc/postfix/main.cf: #policy_time_limit = foo #policy_time_limit = bar Wietse
Re: How to delete a key via postconf
--On Tuesday, March 06, 2012 1:11 PM -0500 Wietse Venema wrote: Hi Wietse, I noted in my initial email why this is not desirable solution. # postconf -# policy_time_limit After: /etc/postfix/main.cf: #policy_time_limit = foo #policy_time_limit = bar The problem with this approach is that if you later re-enable the policy, it will not remove the #'d out entries. Over time, you could theoretically end up with numerous #'d entries for the parameter. I would generally put this out as a feature request -- Can an option be added to postfix to make it so we can fully delete a key via postconf? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: > I think that making everyone wait would be another example of > well-meaning people doing things that give Postfix a bad reputation. postfix start exits successfully but postfix doesn't work, resulting in a WTF moment for the user. I am not sure if this is a recommended way to start a daemon. It surprises them - hence the original email. -- Eray Aslan
Re: found a "bug" on postfix 2.9.1
On 3/6/2012 10:48 AM, Wietse Venema wrote: > - Turning on chroot by default. Many Debian etc. users get into > trouble when they make an innocuous configuration change to the > SMTP daemon. Postfix has no defense for this brain damage. Is this the syslog socket issue Wietse or another issue? Debian added a syslog socket quite a while back. IIRC it was not long after you helped me troubleshoot my logging problem caused by lack of the socket. -- Stan
Re: How to delete a key via postconf
Quanah Gibson-Mount: > --On Tuesday, March 06, 2012 1:11 PM -0500 Wietse Venema > wrote: > > Hi Wietse, > > I noted in my initial email why this is not desirable solution. I ignored your objection, because it made no sense to me. I have learned that is it better to ignore things that make no sense to me, than to fight them in a debate. > ># postconf -# policy_time_limit > > > > After: > > > > /etc/postfix/main.cf: > > #policy_time_limit = foo > > #policy_time_limit = bar > > The problem with this approach is that if you later re-enable the policy, > it will not remove the #'d out entries. Over time, you could theoretically > end up with numerous #'d entries for the parameter. Sorry, feature requests based on theoretical scenarios do not convince me. Wietse
Re: found a "bug" on postfix 2.9.1
Eray Aslan: > On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: > > I think that making everyone wait would be another example of > > well-meaning people doing things that give Postfix a bad reputation. > > postfix start exits successfully but postfix doesn't work, resulting in a > WTF moment for the user. I am not sure if this is a recommended way to > start a daemon. It surprises them - hence the original email. According to the original complaint, no error was logged, and the system claimed that the mail system was running. If they had looked in the right logfile, and if they had used the "postfix status" command, all this WTF would have been unnecessary. They also claimed they had to to reboot their system to clear up the problem. All this indicates that they have no clue. Going for the lowest common denominator is not sufficient moditivation to make changes that cause everyone else to suffer. Wietse
Re: submission users still rejected by zen
On 3/6/2012 11:03 AM, Alex wrote: > I've just noticed I'm using reject_rbl_client and have postscreen > using the RBLs as well. I'll remove the ones from the > smtpd_client_restrictions, but could this possibly be causing mail to > be rejected even when connecting via the submission port? > Any ideas greatly appreciated. > postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 > b.barracudacentral.org*1 > smtpd_recipient_restrictions = [...] > reject_rbl_client zen.spamhaus.org, reject_rbl_client psbl.surriel.com, permit > [...] On 2/23/2012 1:50 PM, Alex wrote: > I've removed the zen and psbl queries from smtpd and moved psbl to > postscreen. You claimed to have made this change a couple of weeks ago per my advice, and confirmed said change to Wietse. Did you change it back? If so why? -- Stan
Re: submission users still rejected by zen
Sorry for the long post, but I am leaving in the entire quoted
message.
On Tue, Mar 06, 2012 at 12:03:23PM -0500, Alex wrote:
> I have a postfix-2.8.7 system with amavisd on fedora15 and am
> having some problems with users being rejected by zen even when
> connecting to the server using the submission port. I believe this
> has to do with my smtpd_client_restrictions being incorrect.
> Because of the way in which I have the ordering, I've had to
> duplicate the check_client_access and check_sender_access because
> my original location wasn't effective. I'm just confused.
>
> Probably unrelated, but another issue I'm having is the always_bcc
> user mail is being duplicated. I've found references to "-o
> smtp_send_xforward_command=yes" being used to prevent duplicated mail
> for always_bcc, but I must be doing something wrong here too.
>
> I've just noticed I'm using reject_rbl_client and have postscreen
> using the RBLs as well. I'll remove the ones from the
> smtpd_client_restrictions, but could this possibly be causing mail to
> be rejected even when connecting via the submission port?
My two cents on that: when implementing postscreen, leave your
smtpd_*_restrictions alone. They were working before, so keep them in
reserve. For example, when under stress, it is possible that DNSBL
queries will not return before the 2-second timeout period. In the
time it takes to pass the connection to smtpd and for smtpd to do
checks, those queries may have returned and been cached. It's very
cheap to do a DNS query from your local cache.
> Mar 6 05:29:28 portal postfix/smtpd[21316]: NOQUEUE: reject: RCPT
> from cpe-76-181-55-14.columbus.res.rr.com[76.XXX.YYY.14]: 554 5.7.1
> Service unavailable; Client host [76.XXX.YYY.14] blocked using
> zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=76.XXX.YYY.14;
> from= to= proto=ESMTP
> helo=
>
> Any ideas greatly appreciated.
>
> --System Parameters--
> mail_version = 2.8.7
> hostname = portal.example.com
> uname = Linux portal.example.com 2.6.41.10-3.fc15.x86_64 #1 SMP Mon
> Jan 23 15:46:37 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> --Packaging information--
> looks like this postfix comes from RPM package: postfix-2.8.7-1.fc15.x86_64
>
> --main.cf non-default parameters--
> alias_database = hash:/etc/postfix/aliases
> alias_maps = hash:/etc/postfix/aliases
> allow_mail_to_files = alias,forward
> always_bcc = bcc-user
> biff = no
> body_checks = regexp:/etc/postfix/body_checks.pcre
> bounce_queue_lifetime = 2d
> content_filter = smtp-amavis:[127.0.0.1]:10024
> default_process_limit = 140
> delay_warning_time = 4h
> disable_vrfy_command = yes
> header_checks = pcre:/etc/postfix/header_checks
> initial_destination_concurrency = 20
> mailbox_command = /usr/bin/procmail
> mailbox_size_limit = 82120
> manpage_directory = /usr/share/man
> maximal_queue_lifetime = 2d
> message_size_limit = 5024
> mime_header_checks = pcre:/etc/postfix/mime_header_checks
> mydestination = $myhostname, localhost.$mydomain
> mynetworks = 127.0.0.0/8, 192.168.1.0/24, 68.XXX.YYY.40/29,
> 64.XXX.YYY.0/27, 66.XXX.YYY.96/28, 204.XXX.YYY.0/24
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_access.cidr
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1
> b.barracudacentral.org*1
> postscreen_dnsbl_threshold = 2
> postscreen_greet_action = enforce
> rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
> readme_directory = /usr/share/doc/postfix-2.8.7/README_FILES
> relay_domains = $mydestination, $transport_maps
$mydestination in relay_domains was a backward compatibility measure.
Being listed in $mydestination overrides relay_domains, so you do not
need that.
Listing $transport_maps here can become very dangerous if you later
decide to use transport_maps for other purposes. A popular idea is to
use a special throttled transport for Yahoo ... oops, yahoo.com
becomes one of your relay_domains.
relay_domains without relay_recipient_maps can cause backscatter. You
need either per-address ONLY transport_maps or recipient address
verification. We can't see into your transport_maps, and there is no
evidence of verification being done.
> sample_directory = /usr/share/doc/postfix-2.8.7/samples
> smtpd_authorized_xforward_hosts = $mynetworks
> smtpd_client_restrictions = check_client_access
> cidr:/etc/postfix/sinokorea.cidr, check_client_access
> cidr:/etc/postfix/asian-ip5.txt
No DNSBL lookups here.
> smtpd_recipient_restrictions = reject_non_fqdn_recipient,
> check_client_access hash:/etc/postfix/client_checks_special,
> check_sender_access hash:/etc/postfix/sender_checks_special,
These access(5) lookups MUST NOT return a permit result. If they do,
you are allowing relay.
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
> reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination, reject_unkno
Re: submission users still rejected by zen
On 3/6/2012 11:03 AM, Alex wrote: > --master.cf-- > submission inet n - n - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions= -o smtpd_sender_restrictions= -o smtpd_helo_restrictions= > -o milter_macro_daemon_name=ORIGINATING BTW, adding the above lines will fix your current problem. They tell your submission smtpd to ignore those 3 restriction classes defined in main.cf. You already told it to override smptd_client_restrictions with new settings, but you didn't override the others, which is the cause of the problem. -- Stan
[OT] Re: found a "bug" on postfix 2.9.1
On 03/06/12 14:10, Wietse Venema wrote: > Eray Aslan: >> On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: >>> I think that making everyone wait would be another example of >>> well-meaning people doing things that give Postfix a bad reputation. >> >> postfix start exits successfully but postfix doesn't work, resulting in a >> WTF moment for the user. I am not sure if this is a recommended way to >> start a daemon. It surprises them - hence the original email. > > According to the original complaint, no error was logged, and the > system claimed that the mail system was running. > > If they had looked in the right logfile, and if they had used the > "postfix status" command, all this WTF would have been unnecessary. > > They also claimed they had to to reboot their system to clear up > the problem. > > All this indicates that they have no clue. Going for the lowest > common denominator is not sufficient moditivation to make changes > that cause everyone else to suffer. It's not really his fault. This is what the startup message looks like: backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If postfix has failed to actually start, you get the same message. Moreover, backup2 ~ # killall -9 /usr/lib64/postfix/master backup2 ~ # /etc/init.d/postfix start * WARNING: postfix has already been started backup2 ~ # /etc/init.d/postfix status * status: started This is not ideal, but I wouldn't say it should necessarily be fixed, either. Right now the problem is easy to understand: half of the time on Gentoo, the startup "OK" is meaningless. Everyone knows this, and figures out how to deal with it quickly: backup2 ~ # /etc/init.d/postfix stop * Stopping postfix (/etc/postfix)... [ !! ] * ERROR: postfix failed to stop backup2 ~ # /etc/init.d/postfix zap * Manually resetting postfix to stopped state backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If we try to fix it with magic (e.g. wrapping 'postfix status'), a) We require more developer time b) Some easy failure modes get nicer c) Many tricky failures get worse So the benefit is not clear-cut.
Re: [OT] Re: found a "bug" on postfix 2.9.1
Michael Orlitzky: > backup2 ~ # killall -9 /usr/lib64/postfix/master > backup2 ~ # /etc/init.d/postfix start >* WARNING: postfix has already been started That is a bug in an init script, and is the responsibility of the OS-specific maintainer. Postfix does not provide init/upstart/systemd/launchpad/whatever scripts. Wietse
Re: submission users still rejected by zen
On 3/6/2012 1:23 PM, /dev/rob0 wrote: > My two cents on that: when implementing postscreen, leave your > smtpd_*_restrictions alone. They were working before, so keep them in > reserve. For example, when under stress, it is possible that DNSBL > queries will not return before the 2-second timeout period. In the > time it takes to pass the connection to smtpd and for smtpd to do > checks, those queries may have returned and been cached. It's very > cheap to do a DNS query from your local cache. Rob, see the recent thread titled "Delay before initial 220 greeting". There's more in play in this OP's case WRT dnsbl queries. In his case it might be better to increase the 2s timeout (if possible) to prevent additional smtpds from spawning. -- Stan
Re: complex policy -- how best to implement in Postfix?
On Tue, Mar 06, 2012 at 10:44:02AM -0500, Ben Rosengart wrote: > On Mon, Mar 05, 2012 at 08:05:54PM -0500, Wietse Venema wrote: > > > > You need to rewrite (sender and non-sender) addresses based on the sender? > > Just sender addresses. Lost interest, Wietse? :-) Am I going in the right direction, looking at sender dependent transport maps? A bit of a conflict here, I'm also using transports to selectively disable DSN to work around an Exchange bug, but I'll work that out ... -- Ben Rosengart "Like all those possessing a library, Sendmail, Inc. Aurelian was aware that he was guilty of +1 718 431 3822 not knowing his in its entirety [...]" -- Jorge Luis Borges NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Re: [OT] Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote: > either. Right now the problem is easy to understand: half of the time on > Gentoo, the startup "OK" is meaningless. Everyone knows this, and > figures out how to deal with it quickly: > > backup2 ~ # /etc/init.d/postfix stop >* Stopping postfix (/etc/postfix)... [ !! ] >* ERROR: postfix failed to stop You get this error because your system thinks postfix is running because the init script exited successfully because postfix start exited successfully (but postfix bailed out with wrong configuration). With postfix status check added, the init script, hence your system, would work as expected and you won't be getting the above or similar errors, i.e. there would be no need for the zap & start workaround. Downside: It would take ~1sec more to start up postfix *for everyone* - one has to wait a bit before running postfix status after postfix start. So, yes it is not a clear cut decision but for different reasons. This is getting really off topic. -- Eray Aslan
Re: complex policy -- how best to implement in Postfix?
Ben Rosengart: > On Tue, Mar 06, 2012 at 10:44:02AM -0500, Ben Rosengart wrote: > > On Mon, Mar 05, 2012 at 08:05:54PM -0500, Wietse Venema wrote: > > > > > > You need to rewrite (sender and non-sender) addresses based on the sender? > > > > Just sender addresses. > > Lost interest, Wietse? :-) No. Given the short reply, I have to re-read the whole damned thread to figure out what the context is. That will have to wait. Wietse
Re: submission users still rejected by zen
On Tue, Mar 06, 2012 at 01:30:59PM -0600, Stan Hoeppner wrote: > On 3/6/2012 11:03 AM, Alex wrote: > > > --master.cf-- > > submission inet n - n - - smtpd > > -o smtpd_tls_security_level=encrypt > > -o smtpd_sasl_auth_enable=yes > > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > -o smtpd_recipient_restrictions= This will not work; smtpd_recipient_restrictions is required. See my earlier post for a workable solution. http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions > -o smtpd_sender_restrictions= > -o smtpd_helo_restrictions= > > > -o milter_macro_daemon_name=ORIGINATING > > BTW, adding the above lines will fix your current problem. They Not if/when the client fails to authenticate, which given the evidence presented, is the only conclusion I can see. (Another possibility: incomplete or inaccurate evidence was presented.) > tell your submission smtpd to ignore those 3 restriction classes > defined in main.cf. You already told it to override > smptd_client_restrictions with new settings, but you didn't > override the others, which is the cause of the problem. On Tue, Mar 06, 2012 at 01:55:10PM -0600, Stan Hoeppner wrote: > On 3/6/2012 1:23 PM, /dev/rob0 wrote: > > > My two cents on that: when implementing postscreen, leave your > > smtpd_*_restrictions alone. They were working before, so keep > > them in reserve. For example, when under stress, it is possible > > that DNSBL queries will not return before the 2-second timeout > > period. In the time it takes to pass the connection to smtpd and > > for smtpd to do checks, those queries may have returned and been > > cached. It's very cheap to do a DNS query from your local cache. > > Rob, see the recent thread titled "Delay before initial 220 > greeting". There's more in play in this OP's case WRT dnsbl > queries. In his case it might be better to increase the 2s timeout > (if possible) to prevent additional smtpds from spawning. I saw that thread, but didn't have time to comment on it. I still believe that the relatively minor cost of a redundant DNSBL lookup is worthwhile. It's not going to cause any additional smtpd, and in the vast majority of cases, it will take very little extra time or CPU. In the event of DNS SERVFAIL responses or timeouts, it can add some more time and stress, but that suggests a problem with the resolver and/or the DNSBL. I take the risk anyway. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: submission users still rejected by zen
Hi, >> I've just noticed I'm using reject_rbl_client and have postscreen >> using the RBLs as well. I'll remove the ones from the >> smtpd_client_restrictions, but could this possibly be causing mail to >> be rejected even when connecting via the submission port? > >> Any ideas greatly appreciated. > >> postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 >> b.barracudacentral.org*1 > >> smtpd_recipient_restrictions = [...] >> reject_rbl_client zen.spamhaus.org, reject_rbl_client psbl.surriel.com, >> permit >> [...] > > > On 2/23/2012 1:50 PM, Alex wrote: > >> I've removed the zen and psbl queries from smtpd and moved psbl to >> postscreen. > > You claimed to have made this change a couple of weeks ago per my > advice, and confirmed said change to Wietse. Did you change it back? > If so why? My apologies; this is for a similar, but different system. It looks like I've made the same mistake on multiple systems. I'm very appreciative that you remembered my similar issue from weeks ago :-) I read through the other responses briefly, and will read through them more thoroughly now. I can add that the info is accurate to the best of my ability, and I don't believe I've left anything out. Since we're referencing the other system, I've lowered the default_process_limit to 100 from 300 and it remains responsive, now that I've removed the reject_rbl_client from smtpd_recipient_restrictions (although I suppose that could be coincident). Perhaps this is a discussion for after the current issue is resolved. Thanks, Alex
Re: [OT] Re: found a "bug" on postfix 2.9.1
Eray Aslan: > On Tue, Mar 06, 2012 at 02:30:59PM -0500, Michael Orlitzky wrote: > > either. Right now the problem is easy to understand: half of the time on > > Gentoo, the startup "OK" is meaningless. Everyone knows this, and > > figures out how to deal with it quickly: > > > > backup2 ~ # /etc/init.d/postfix stop > >* Stopping postfix (/etc/postfix)... [ !! ] > >* ERROR: postfix failed to stop > > You get this error because your system thinks postfix is running because > the init script exited successfully because postfix start exited > successfully (but postfix bailed out with wrong configuration). With > postfix status check added, the init script, hence your system, would > work as expected and you won't be getting the above or similar errors, > i.e. there would be no need for the zap & start workaround. > > Downside: > It would take ~1sec more to start up postfix *for everyone* - one has to > wait a bit before running postfix status after postfix start. So you need a way for "postfix start" that returns status 0 if the master(8) daemon initalizes successfully, and non-zero otherwise. I think this can be done by starting the master as a foreground process. The foreground master forks a child process that will become the master daemon that runs as a background process. The foreground master process waits for the "all is OK" signal from the child process. When that happens, the foreground process terminates with a 0 status, causing "postfix start" to return a 0 status. This will normally take a fraction of a second. In case of problems (no response from child, child terminates) the foreground process terminates with non-zero status, and "postfix start" reports an error, and returns a non-zero exit status. Will that work? Wietse
Re: [OT] Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote: > So you need a way for "postfix start" that returns status 0 if the > master(8) daemon initalizes successfully, and non-zero otherwise. Correct. > I think this can be done by starting the master as a foreground > process. The foreground master forks a child process that will > become the master daemon that runs as a background process. > > The foreground master process waits for the "all is OK" signal from > the child process. When that happens, the foreground process > terminates with a 0 status, causing "postfix start" to return a 0 > status. This will normally take a fraction of a second. > > In case of problems (no response from child, child terminates) the > foreground process terminates with non-zero status, and "postfix > start" reports an error, and returns a non-zero exit status. > > Will that work? Yes, that will work. Thank you. -- Eray Aslan
Re: complex policy -- how best to implement in Postfix?
On Tue, Mar 06, 2012 at 03:20:30PM -0500, Wietse Venema wrote: > Ben Rosengart: > > On Tue, Mar 06, 2012 at 10:44:02AM -0500, Ben Rosengart wrote: > > > On Mon, Mar 05, 2012 at 08:05:54PM -0500, Wietse Venema wrote: > > > > > > > > You need to rewrite (sender and non-sender) addresses based on the > > > > sender? > > > > > > Just sender addresses. > > > > Lost interest, Wietse? :-) > > No. Given the short reply, I have to re-read the whole damned thread > to figure out what the context is. That will have to wait. Apologies. I'm thinking parts of this over and if I reanimate the thread, I will be sure to provide full context. Thanks, -- Ben Rosengart "Like all those possessing a library, Sendmail, Inc. Aurelian was aware that he was guilty of +1 718 431 3822 not knowing his in its entirety [...]" -- Jorge Luis Borges NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Re: submission users still rejected by zen
On 3/6/2012 2:25 PM, /dev/rob0 wrote: > On Tue, Mar 06, 2012 at 01:30:59PM -0600, Stan Hoeppner wrote: >> On 3/6/2012 11:03 AM, Alex wrote: >> >>> --master.cf-- >>> submission inet n - n - - smtpd >>> -o smtpd_tls_security_level=encrypt >>> -o smtpd_sasl_auth_enable=yes >>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> >> -o smtpd_recipient_restrictions= > > This will not work; smtpd_recipient_restrictions is required. See my > earlier post for a workable solution. Yeah, I forgot you have to specify at least one. Should have checked my own config. I was responding to your earlier post--I wouldn't think it should require anything that complex in main.cf just to set recipient restrictions for the submission daemon. I don't recall seeing such a setup mentioned here before anyway. FWIW I don't use auth for submission, but do have a submission service for internal users (external access is via webmail). 10125 inet n - - - - smtpd -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o receive_override_options=no_unknown_recipient_checks,\ no_address_mappings,no_header_body_checks > http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions > >> -o smtpd_sender_restrictions= >> -o smtpd_helo_restrictions= >> >>> -o milter_macro_daemon_name=ORIGINATING >> >> BTW, adding the above lines will fix your current problem. They > > Not if/when the client fails to authenticate, which given the > evidence presented, is the only conclusion I can see. (Another > possibility: incomplete or inaccurate evidence was presented.) Ahh good point. If auth occurred then the dnsbl check shouldn't have triggered. I made the mistake of taking the OP's report at face value and assumed the problem was the dnsbl check in the submission service. >> Rob, see the recent thread titled "Delay before initial 220 >> greeting". There's more in play in this OP's case WRT dnsbl >> queries. In his case it might be better to increase the 2s timeout >> (if possible) to prevent additional smtpds from spawning. > > I saw that thread, but didn't have time to comment on it. I still > believe that the relatively minor cost of a redundant DNSBL lookup is > worthwhile. It's not going to cause any additional smtpd, and in the > vast majority of cases, it will take very little extra time or CPU. He had to increase default_process_limit to 300 so clients wouldn't delay. 300 smtpds is excessive, and expensive. His pushing all dnsbl checks into Postscreen apparently substantially decreased the number of smtpds he needed--exactly what it's supposed to do. If dns times out during postscreen and the response comes in before the smtpd dnsbl check, he's still got excessive smtpd processes spawning only to kill connections, which is counter intuitive here. Your "layered" defense is sound for most systems. In this case it would be better to increase the 2s timeout so postscreen is able to do its job rather than to spawn more smtpds to accomplish the same. > In the event of DNS SERVFAIL responses or timeouts, it can add some > more time and stress, but that suggests a problem with the resolver > and/or the DNSBL. I take the risk anyway. In the OP's case it's none of the above. It was apparently simply a connection load issue and using dnsbl checks within smtpd. -- Stan
Re: submission users still rejected by zen
On 3/6/2012 2:46 PM, Alex wrote: >> On 2/23/2012 1:50 PM, Alex wrote: >> >>> I've removed the zen and psbl queries from smtpd and moved psbl to >>> postscreen. >> >> You claimed to have made this change a couple of weeks ago per my >> advice, and confirmed said change to Wietse. Did you change it back? >> If so why? > > My apologies; this is for a similar, but different system. It looks > like I've made the same mistake on multiple systems. I'm very Ahh, ok, that would explain the discrepancy. > appreciative that you remembered my similar issue from weeks ago :-) After helping you with that, and attempting to help you with the Constant Contact clogging your queue issue, it's hard to forget you Alex. ;) BTW, please be sure to respond to Tara, even if you've since solved that issue. I went out of my may to get you in touch with her. Be courteous and drop her a line, if only to say you already fixed it. > I read through the other responses briefly, and will read through them > more thoroughly now. I can add that the info is accurate to the best > of my ability, and I don't believe I've left anything out. > > Since we're referencing the other system, I've lowered the > default_process_limit to 100 from 300 and it remains responsive, now > that I've removed the reject_rbl_client from > smtpd_recipient_restrictions (although I suppose that could be > coincident). It's not coincidence. That's exactly what should have happened. Which is why I recommended it. > Perhaps this is a discussion for after the current issue > is resolved. Yes, it's better to keep different issues in different threads. -- Stan
Re: submission users still rejected by zen
On Tue, Mar 06, 2012 at 04:44:26PM -0600, Stan Hoeppner wrote: > On 3/6/2012 2:25 PM, /dev/rob0 wrote: > > On Tue, Mar 06, 2012 at 01:30:59PM -0600, Stan Hoeppner wrote: > >> On 3/6/2012 11:03 AM, Alex wrote: > >> > >>> --master.cf-- > >>> submission inet n - n - - smtpd > >>> -o smtpd_tls_security_level=encrypt > >>> -o smtpd_sasl_auth_enable=yes > >>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > >> > >> -o smtpd_recipient_restrictions= > > > > This will not work; smtpd_recipient_restrictions is required. See > > my earlier post for a workable solution. > > Yeah, I forgot you have to specify at least one. Should have > checked my own config. I was responding to your earlier post--I > wouldn't think it should require anything that complex in main.cf > just to set recipient restrictions for the submission daemon. No, not required, but it's more convenient IMO to put complexity in main.cf rather than master.cf. Some sites might want restrictions before accepting submission mail, such as for unknown domains, unlisted senders or sender mismatch. > I don't recall seeing such a > setup mentioned here before anyway. Oh yes, IIRC I originally saw the idea from Victor. It's even better now with 2.9's postconf(1) improvements; "postconf custom_setting" shows any such custom setting as defined. > FWIW I don't use auth for > submission, but do have a submission service for internal users > (external access is via webmail). > > 10125 inet n - - - - smtpd > -o smtpd_client_restrictions= > -o smtpd_helo_restrictions= > -o smtpd_sender_restrictions= You might also want to put in that -o syslog_name :) > -o smtpd_recipient_restrictions=permit_mynetworks,reject > -o receive_override_options=no_unknown_recipient_checks,\ >no_address_mappings,no_header_body_checks This is a perfect example of why you'd want to list that in main.cf: submission_overrides = no_unknown_recipient_checks, no_address_mappings, no_header_body_checks and then: -o receive_override_options=$submission_overrides Keeps it all nice and neat on one readable line in master.cf. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
changing return-path
I'm looking to change the return-path of email so all email coming out
of our servers comes back to a common mailbox. My master.cf i have
added
filter unix - n n - - pipe
flags=Rq user=filter argv=/etc/postfix/filter -f ${sender} -- ${recipient}
My filter looks like
#!/bin/sh
# change these if needed
INSPECT_DIR=/var/spool/filter
SENDMAIL=/usr/sbin/sendmail
# Exit codes from
EX_TEMPFAIL=75
EX_UNAVAILABLE=69
# Clean up when done or when aborting.
#trap "rm -f in.$$" 0 1 2 3 15
# Start processing.
cd $INSPECT_DIR || { echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
cat >in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
/usr/bin/alter_email.py -f in.$$ || \
{ echo Message content rejected; exit $EX_UNAVAILABLE; }
# Send the email on as per the Postfix stack
$SENDMAIL "$@" \" --alter-mode=replace" %
(options.email_file, email_id)
p = Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=STDOUT,
close_fds=True)
So if i leave the trap commented out in my filter file the email is
saved there and the /var/spool/filter/in.* files are correct.. but
when I get the email the return-path is never changed.
Anything I am missing?
thanks!
Re: changing return-path
On Tue, Mar 06, 2012 at 03:56:50PM -0800, Mike Zupan wrote: > I'm looking to change the return-path of email so all email > coming out of our servers comes back to a common mailbox. So that *bounces* go to a common mailbox? If this is for bulk mail, simply change the software that is sending the mail to use that address as sender. If this is for anything else, your idea sounds very bad indeed. snip > So if i leave the trap commented out in my filter file the email > is saved there and the /var/spool/filter/in.* files are correct.. > but when I get the email the return-path is never changed. > > Anything I am missing? Return-Path: is added upon delivery, set by the receiving MTA to display the envelope sender address. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: changing return-path
Mike Zupan: > I'm looking to change the return-path of email so all email coming out > of our servers comes back to a common mailbox. My master.cf i have > added As documented in the Internet mail RFCs, the return-path header is prepended upon final delivery. Editing the header in transit is pointless. Wietse
Re: found a "bug" on postfix 2.9.1
On 06/03/2012 21:10, Wietse Venema wrote: Eray Aslan: On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: I think that making everyone wait would be another example of well-meaning people doing things that give Postfix a bad reputation. postfix start exits successfully but postfix doesn't work, resulting in a WTF moment for the user. I am not sure if this is a recommended way to start a daemon. It surprises them - hence the original email. According to the original complaint, no error was logged, and the system claimed that the mail system was running. sorry for the delay i was working the whole day on the mail system (that works perfect for the last 4 plus years based on postfix..it's that good) i indeed found this log entry but it was difficult cause of the huge amount of mail.log by other mail service. so i have used postfix start (not script)to start postfix and i got the error on log but it shows only once and then every time it saying something that i cant remember right now (side of effect of working on crisis mode for the last couple of weeks). anyway postfix check command didnt showed any information about this problem. Thanks Eliezer If they had looked in the right logfile, and if they had used the "postfix status" command, all this WTF would have been unnecessary. They also claimed they had to to reboot their system to clear up the problem. All this indicates that they have no clue. Going for the lowest common denominator is not sufficient moditivation to make changes that cause everyone else to suffer. Wietse
Re: [OT] Re: found a "bug" on postfix 2.9.1
On 06/03/2012 21:30, Michael Orlitzky wrote: On 03/06/12 14:10, Wietse Venema wrote: Eray Aslan: On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote: I think that making everyone wait would be another example of well-meaning people doing things that give Postfix a bad reputation. postfix start exits successfully but postfix doesn't work, resulting in a WTF moment for the user. I am not sure if this is a recommended way to start a daemon. It surprises them - hence the original email. According to the original complaint, no error was logged, and the system claimed that the mail system was running. If they had looked in the right logfile, and if they had used the "postfix status" command, all this WTF would have been unnecessary. They also claimed they had to to reboot their system to clear up the problem. All this indicates that they have no clue. Going for the lowest common denominator is not sufficient moditivation to make changes that cause everyone else to suffer. It's not really his fault. This is what the startup message looks like: backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If postfix has failed to actually start, you get the same message. Moreover, backup2 ~ # killall -9 /usr/lib64/postfix/master backup2 ~ # /etc/init.d/postfix start * WARNING: postfix has already been started backup2 ~ # /etc/init.d/postfix status * status: started This is not ideal, but I wouldn't say it should necessarily be fixed, either. Right now the problem is easy to understand: half of the time on Gentoo, the startup "OK" is meaningless. Everyone knows this, and figures out how to deal with it quickly: backup2 ~ # /etc/init.d/postfix stop * Stopping postfix (/etc/postfix)... [ !! ] * ERROR: postfix failed to stop backup2 ~ # /etc/init.d/postfix zap * Manually resetting postfix to stopped state backup2 ~ # /etc/init.d/postfix start * Starting postfix (/etc/postfix)... [ ok ] If we try to fix it with magic (e.g. wrapping 'postfix status'), a) We require more developer time b) Some easy failure modes get nicer c) Many tricky failures get worse i dont care about any init scripts on whatever else then when there is this specific problem of mismatching binding an ip that dosnt exist to be checked using the "postfix check" method on terminal and not only on log. by writing the bug i do hope this simple guy that will look for the problem will understand what could he missed. Thanks, Eliezer So the benefit is not clear-cut.
Re: [OT] Re: found a "bug" on postfix 2.9.1
Eliezer Croitoru: > i dont care about any init scripts on whatever else then when there is > this specific problem of mismatching binding an ip that dosnt exist to > be checked using the "postfix check" method on terminal and not only on log. Sorry, only the master daemon knows that it can't access the IP address. To find out if Postfix runs, use "postfix status". Don't use the crap scripts from Linux maintainers. To find out why Postfix does not run , read the logfile. Wietse
Re: found a "bug" on postfix 2.9.1
On 06/03/2012 14:17, Jerry wrote: On Tue, 06 Mar 2012 12:37:02 +0200 Eliezer Croitoru articulated: OS:Gentoo latest built with kernel 3.2.1 with hardened profile POSTFIX: v 2.9.1 when i'm configuring on master.cf some listening to port on ip address that doesn't exist on any interface such as for communicating with amavis (as if my ip is 192.168.0.20 and i will put 192.168.0.21:25 ) postfix will try to bind the port\ip and will not run or log useful information to understand whats wrong extactly. then you can't find any process of postfix using ps top or any other tool but postfix will say that it is still running and the only way i managed to make postfix work is to fix the master.cf and rebooting the machine\os. You need to provide the proper information to debug a possible bug. Start here: http://www.postfix.com/DEBUG_README.html will do. i will try to be more accurate next time. because of two servers migration i had sometime of understanding this better and will try to debug it with more accuracy. Eliezer Be sure to read this part thoroughly: http://www.postfix.com/DEBUG_README.html#mail Report back with the requested information and then someone can possibly assist you.
PATCH: "postfix start" master initialization status
I have uploaded a feature patch that changes "postfix start" so that it returns after the master daemon has initialized. This works around a problem on some Linux systems. These don't use "postfix status" to find out if the mail system still runs. Instead they just make up something and claim that Postfix runs even when the master has aborted. Even worse, they refuse to start Postfix when the problem is fixed, claiming that Postfix is still running! The feature patch addresses only the start-up side of the issue. Location on the source code mirrors: postfix-release/experimental/feature-patches/20120206-master-monitor-patch postfix-release/experimental/feature-patches/20120206-master-monitor-patch.sig It is up to Linux maintainers to use "postfix status" properly so that the user receives correct information about whether or not Postfix is running, instead of providing bogus status information, and refusing to start a mail system that is down. Wietse
Re: submission users still rejected by zen
Hi, >> My apologies; this is for a similar, but different system. It looks >> like I've made the same mistake on multiple systems. I'm very > > Ahh, ok, that would explain the discrepancy. > >> appreciative that you remembered my similar issue from weeks ago :-) > > After helping you with that, and attempting to help you with the > Constant Contact clogging your queue issue, it's hard to forget you > Alex. ;) BTW, please be sure to respond to Tara, even if you've since > solved that issue. I went out of my may to get you in touch with her. > Be courteous and drop her a line, if only to say you already fixed it. I don't recall seeing an email from you with that information. Can I ask you to resend, and I'll follow up with her? While I think it might be helpful to contact CC, this is just one example where the server is overloaded. I'd really like a more far-reaching solution. I've used tc and cbq for QoS a long time in the past, but not sure I could now figure out how to use it to throttle SMTP traffic now. >> Since we're referencing the other system, I've lowered the >> default_process_limit to 100 from 300 and it remains responsive, now >> that I've removed the reject_rbl_client from >> smtpd_recipient_restrictions (although I suppose that could be >> coincident). > > It's not coincidence. That's exactly what should have happened. Which > is why I recommended it. As it turns out, before I could hardly notice, the server was hit with a large amount of connections from everbridge.net, resulting in a few thousand messages being deferred: Mar 6 18:05:34 mail01 postfix/error[13144]: 59C26156326F: to=<01...@example.com>, relay=none, delay=557, delays=439/118/0/0.11, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greetin g) I'm pretty sure it was related to that, as I haven't had these types of messages in quite a while. I had to increase the default_process_limit back to 200 and forcibly restart amavisd, after which it delivered all the messages without further issues. Thanks, Alex
Re: submission users still rejected by zen
Hi, >> I've just noticed I'm using reject_rbl_client and have postscreen >> using the RBLs as well. I'll remove the ones from the >> smtpd_client_restrictions, but could this possibly be causing mail to >> be rejected even when connecting via the submission port? > > My two cents on that: when implementing postscreen, leave your > smtpd_*_restrictions alone. They were working before, so keep them in > reserve. For example, when under stress, it is possible that DNSBL > queries will not return before the 2-second timeout period. In the > time it takes to pass the connection to smtpd and for smtpd to do > checks, those queries may have returned and been cached. It's very > cheap to do a DNS query from your local cache. Is it not the case that having it in both smtpd_*_restrictions and postscreen consumes process resources? It also means that I must create exceptions in two different places, should it ever be necessary. > Listing $transport_maps here can become very dangerous if you later > decide to use transport_maps for other purposes. A popular idea is to > use a special throttled transport for Yahoo ... oops, yahoo.com > becomes one of your relay_domains. I have the following in my transport map: example.com local: .example.com local: This was done a long time ago when this system used to be a dual-instance postfix scenario and I couldn't figure out how to do it without this. > relay_domains without relay_recipient_maps can cause backscatter. You > need either per-address ONLY transport_maps or recipient address > verification. We can't see into your transport_maps, and there is no > evidence of verification being done. Is this why I have the following in the logs? Mar 6 07:17:23 portal postfix/trivial-rewrite[4328]: warning: do not list domain example.com in BOTH virtual_alias_domains and relay_domains In /etc/postfix/virtual I have the following: example.com VIRTUALDOMAIN am...@example.com farroua l...@example.comcolonl j...@example.com hannahj ci...@example.com barkerc I thought removing it from relay_domains was the right thing to do, but I believe it broke something when I did it last, and since it's working, I've left it alone. Obviously would like to fix it. >> smtpd_recipient_restrictions = reject_non_fqdn_recipient, >> check_client_access hash:/etc/postfix/client_checks_special, >> check_sender_access hash:/etc/postfix/sender_checks_special, > > These access(5) lookups MUST NOT return a permit result. If they do, > you are allowing relay. > > http://www.postfix.org/SMTPD_ACCESS_README.html#danger I have entries like this in my client_checks files: 192.168.1.100 OK 192.168 554 Take a hike! southmarketing.com.br OK .southmarketing.com.br OK In sender_checks I have similar: someu...@example3.tld OK 173.245.204.0/23REJECT >> reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated, >> reject_unauth_destination, reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_invalid_helo_hostname, check_recipient_access >> pcre:/etc/postfix/relay_recips_ecartis, check_client_access >> hash:/etc/postfix/client_checks, check_sender_access >> hash:/etc/postfix/sender_checks, check_recipient_access >> pcre:/etc/postfix/relay_recips_access, reject_rbl_client >> zen.spamhaus.org, reject_rbl_client psbl.surriel.com, permit > > But there it is, long after permit_sasl_authenticated, so an > authenticated client is not affected. We can only guess that > PattyTHINK above failed to authenticate. Would this be represented in the logs in some way, or only after adding the "-o syslog=postfix/submission" to master.cf and its lack of presence? >> --master.cf-- >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > You might also want to override your smtpd_recipient_restrictions > here. You can define a variable in main.cf, for example: > > submission_recipient_restrictions = [ stuff that you want applied > against submission users ], permit_sasl_authenticated, reject > > And then use it here: > -o smtpd_recipient_restrictions=$submission_recipient_restrictions I'm not sure I understand why I would want to do this? >> -o milter_macro_daemon_name=ORIGINATING > > This also needs " -o syslog_name=postfix/submission", which is a > recently-added default. Thus we can see for sure that we're on > submission and not smtp. Okay, I've added it. Should it then look like this after adding? Mar 6 21:33:17 portal postfix/submission/smtpd[15023]: connect from rrcs-204-210-162-21.central.biz.rr.com[204.XXX.YYY.21] Thanks, Alex
Re: submission users still rejected by zen
Hi, --master.cf-- submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>> >>> -o smtpd_recipient_restrictions= >> >> This will not work; smtpd_recipient_restrictions is required. See my >> earlier post for a workable solution. > > Yeah, I forgot you have to specify at least one. Should have checked my > own config. I was responding to your earlier post--I wouldn't think it > should require anything that complex in main.cf just to set recipient > restrictions for the submission daemon. I don't recall seeing such a > setup mentioned here before anyway. FWIW I don't use auth for > submission, but do have a submission service for internal users > (external access is via webmail). > > 10125 inet n - - - - smtpd > -o smtpd_client_restrictions= > -o smtpd_helo_restrictions= > -o smtpd_sender_restrictions= > -o smtpd_recipient_restrictions=permit_mynetworks,reject > -o receive_override_options=no_unknown_recipient_checks,\ > no_address_mappings,no_header_body_checks Isn't this effectively what I already have? I must be missing differences somewhere? submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix/submission 127.0.0.1:10025 inet n- n - - smtpd -o content_filter= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o local_header_rewrite_clients= Just to be clear, I'm missing no_address_mappings in the receive_override_options in order to prevent the duplicated always_bcc mail, correct? >>> -o smtpd_sender_restrictions= >>> -o smtpd_helo_restrictions= >>> -o milter_macro_daemon_name=ORIGINATING >>> >>> BTW, adding the above lines will fix your current problem. They >> >> Not if/when the client fails to authenticate, which given the >> evidence presented, is the only conclusion I can see. (Another >> possibility: incomplete or inaccurate evidence was presented.) > > Ahh good point. If auth occurred then the dnsbl check shouldn't have > triggered. I made the mistake of taking the OP's report at face value > and assumed the problem was the dnsbl check in the submission service. You're saying here that the reject_rbl_client at the end of the smtpd_recipient_restrictions would be skipped because it would be auth'd by permit_sasl_authenticated, correct? >> In the event of DNS SERVFAIL responses or timeouts, it can add some >> more time and stress, but that suggests a problem with the resolver >> and/or the DNSBL. I take the risk anyway. > > In the OP's case it's none of the above. It was apparently simply a > connection load issue and using dnsbl checks within smtpd. I think I'm still going to have to do more research on finding that right default_process value. Thanks, Alex
Re: submission users still rejected by zen
On 3/6/2012 8:01 PM, Alex wrote: > I don't recall seeing an email from you with that information. Can I > ask you to resend, and I'll follow up with her? It was delivered to your Gmail mailbox yesterday: /var/log/mail.log:Mar 5 16:37:55 greer postfix/smtp[25300]: CB3636C052: to=, relay=gmail-smtp-in.l.google.com[74.125.65.26]:25, delay=1.5, delays=0.01/0.06/0.77/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK 1330987075 e42si17985261yhh.147) And she replied to both of us this morning: /var/log/mail.log:Mar 6 08:57:18 greer postfix/qmgr[1241]: 1D3D86C052: from=, size=2711, nrcpt=1 (queue active) > While I think it might be helpful to contact CC, this is just one > example where the server is overloaded. I'd really like a more What you fail to realize is that Tara can give you valuable insight into how ALL bulk mailers tend to behave, not just CC specific stuff. She's got a lot of experience in the bulk mail business. > far-reaching solution. I've used tc and cbq for QoS a long time in the > past, but not sure I could now figure out how to use it to throttle > SMTP traffic now. If you want a global solution to the parallel client connection problem, this is it: smtpd_client_connection_count_limit=1 This limits the number of parallel connections a client is allowed to open to Postfix. This 'might' unduly slow delivery from legit non bulk senders as well so you may need to play with different values until you achieve the desired results. If this technique turns out to not be suitable... Simply add CC's and other bulk sender IP addresses and/or subnets to the table we discussed earlier in the thread, in the context of the postfwd policy daemon or iptables rules. > As it turns out, before I could hardly notice, the server was hit with > a large amount of connections from everbridge.net, resulting in a few > thousand messages being deferred: Please be technically specific: were all of these connections from a single IP address at everbridge.net or multiple IP addresses? If a single IP, the method I described above should fix this instantly. If multiple IPs this solution will help some, but may not fully solve the connection load problem. I.e. they hit you from dozens of IPs. > Mar 6 18:05:34 mail01 postfix/error[13144]: 59C26156326F: > to=<01...@example.com>, relay=none, delay=557, delays=439/118/0/0.11, > dsn=4.4.2, status=deferred (delivery temporarily suspended: lost > connection with 127.0.0.1[127.0.0.1] while receiving the initial > server greeting) So amavis is failing. The above should fix this. > I'm pretty sure it was related to that, as I haven't had these types > of messages in quite a while. I had to increase the > default_process_limit back to 200 and forcibly restart amavisd, after > which it delivered all the messages without further issues. Please note that increasing default_process_limit also increases smtpd_client_connection_count_limit to half that value, if you haven't manually specified a value for the latter. I.e. 200 processes equals 100 connections per client IP. Lucky for you bulk senders don't configure their outbounds with unlimited parallel connections, or increasing process limit wouldn't help you, but could make things worse. How many Postfix servers are in your MX farm? When you make changes to one host slowing down client delivery, smart bulk senders will simply avoid your slow MX and hammer the others in the MX pool. When you make a change to one that slows clients down you need to make the same change to all of them. Try setting smtpd_client_connection_count_limit=1 on all your postfix MX hosts and see how that works for a day or two. If legit non-bulk clients are seeing too much delay, bump the value up in increments of 1 until you get legit clients moving as they should while still preventing bulk-mailers from bogging you down. -- Stan
Re: postfix-users@postfix.org: difference between "verify" and "secure"
On Tue, Mar 06, 2012 at 06:19:59PM +0100, Robert Dahlem wrote: > Default strategy for "verify": ask DNS about MX, then check if the > servers CN matches. Check if the trust chain is valid. Yes, though there is no promise of whether the name or the trust chain is checked first. Both need to be acceptable. > Default strategy for "secure": accept any CN presented by the server if > that is the domain or a subdomain of the recipient address or the > canonized hostname from the transport table. Do not add MX names looked > up in DNS to the list of feasible CNs. Check if the trust chain is valid. If the transport table specifies a nexthop, then, if I recall correctly, it is used verbatim, I don't believe it is canonicalized (nor canonized by the Catholic Church). As before the order of the checks is implementation specific. > Both can be overridden in tls_policy with the match attribute. Once explicit match criteria are specified, the two levels become indistinguishable, they apply the match criteria to the peer certificate whose trust chain is verified in the same way at either level. -- Viktor.
Re: submission users still rejected by zen
On 3/6/2012 8:49 PM, Alex wrote: >>-o smtpd_recipient_restrictions=permit_mynetworks,reject > Isn't this effectively what I already have? I must be missing > differences somewhere? You're missing a recipient_restrictions override. Without one, your submission connections are subject to dnsbl checks when auth fails. This is why you saw that ZEN rejection. You should _never_ check submission connections against dnsbls. ZEN contains the PBL, which contains consumer dynamic IP ranges. This is where clients typically connect from. Using the above override prevents the dnsbl checks you have configured in main.cf. In your case it won't reject a client connection because of your restriction ORDER, but it will cause those ZEN errors in the log, which can be very confusing, as you already discovered. It made you think the problem was in a place it did not exist. > submission inet n - n - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING > -o syslog_name=postfix/submission > Just to be clear, I'm missing no_address_mappings in the > receive_override_options in order to prevent the duplicated always_bcc > mail, correct? I'm not sure on that one. Someone else will need to chime in. > You're saying here that the reject_rbl_client at the end of the > smtpd_recipient_restrictions would be skipped because it would be > auth'd by permit_sasl_authenticated, correct? Yes. At least, that's what we're assuming based on restriction ORDER in your Postfinger output. > I think I'm still going to have to do more research on finding that > right default_process value. There is a problem here. You have found a knob you can turn and get something like the result you want. But, this is not the right knob to be turning to address your load problem because it simply masks the real problem. And it can cause larger problems later when your connection load continues to increase. You increased the process limit on one machine from 100 to 300, and on another machine from 100 to 200. The peak connection load on each actually increased as well, but not enough to overwhelm the new process limit. When you get hit by enough bulk mailers concurrently, a process limit of 500 may not be enough to mask the problem any longer, and you're back where you started. Thus, the permanent solution is to dramatically slow down the bulk mailers. I've given you one method in the previous email that should do exactly that, instantly, while keeping default_process_limit=100. -- Stan
Re: [OT] Re: found a "bug" on postfix 2.9.1
On 07/03/2012 02:33, Wietse Venema wrote: Eliezer Croitoru: i dont care about any init scripts on whatever else then when there is this specific problem of mismatching binding an ip that dosnt exist to be checked using the "postfix check" method on terminal and not only on log. Sorry, only the master daemon knows that it can't access the IP address. ok but it wont stop using "postfix stop" Eliezer To find out if Postfix runs, use "postfix status". Don't use the crap scripts from Linux maintainers. To find out why Postfix does not run , read the logfile. Wietse
Re: [OT] Re: found a "bug" on postfix 2.9.1
On Tue, Mar 06, 2012 at 04:01:47PM -0500, Wietse Venema wrote: > So you need a way for "postfix start" that returns status 0 if the > master(8) daemon initalizes successfully, and non-zero otherwise. > > I think this can be done by starting the master as a foreground > process. The foreground master forks a child process that will > become the master daemon that runs as a background process. > > The foreground master process waits for the "all is OK" signal from > the child process. When that happens, the foreground process > terminates with a 0 status, causing "postfix start" to return a 0 > status. This will normally take a fraction of a second. > > In case of problems (no response from child, child terminates) the > foreground process terminates with non-zero status, and "postfix > start" reports an error, and returns a non-zero exit status. > > Will that work? It'll could be an inconvenience for the folks at Apple, who start master(8) directly via launchd. However, since they've made no attempt to have their patches adopted, ... it is hard to take their interests into account. Probably provided "master -d" continues to run in the foreground, their stuff will not break in new ways. :-) -- Viktor.
