Illegal address syntax
Hi! Is it possible to make Postfix Reject instead of warn for "Illegal address syntax"? Thanks! P.
Re: probably bug in postfix3-3.4
On Wed, May 06, 2020 at 09:07:45AM -0400, Wietse Venema wrote: > You need to collect logs over at least 5 minutes. I was sitting this one out, but perhaps should make a few comments: 1. Postfix does not have bugs of the sort conjectured by the OP. The problem is entirely a result of configuration and workload. 2. I don't recall seeing the OP's configuration (verbatim, without refolding of lines, "postconf -nf" and "postconf -Mf" output) posted to the list. 3. Frequent routine "postfix reload" is a bad idea. On queue manager restart moves all active messages back into the deferred queue for reprocessing, this is disruptive. Don't do that. 4. The queue manager suspends requesting delivery of new mail when all the transport delivery agents are still busy attempting to deliver previously scheduled deliveries. 5. The queue manager also suspends delivery to a transport when the delivery reports fatal errors. 6. The queue manager suspends delivery to a particular nexthop destination when enough back to back deliveries to that destination fail (not just invalid recipients but failure to complete the mail transaction). 7. The most likely reason for queue manager congestion is excessive bounces to invalid sender addreses, that clog the smtp delivery agent output queue, and take a long time to time out. This could be caused missing input recipient validation, or by misconfiguration that creates an excessive load bounces. Mail routing loops can also contribute. Of course misconfiguration that causes delivery agent failure or lots of traffic to a non-working destination also "help". 8. To understand what's in your quuee, see "QSHAPE_README". Look at both "qshape" and "qshape -s" (the latter is grouped by sender domain). http://www.postfix.org/QSHAPE_README.html If that does not immediately make the problem clear, post the output and come back and ask for help to interpret it. 9. As mentioned by others the OP will actually need to show some logs that involve delivery agents succeeding and failing. Restart Postfix if necessary, but capture enough logging to show processing by one of: smtp unix - - n - - smtp relay unix - - n - - smtp error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp which write logs tagged as "postfix/", where is the last column above. Note that's "smtp" not "smtpd". -- Viktor.
Re: explicit shlib_directory in main.cf
Maxim Nikulin: > Hi, > > I have noticed than postfix-install script explicitly adds > shlib_directory to the main.cf file e.g. during non-interactive install. Postfix records all installation settings in main.cf even if they are at their built-in defaults. That is because defaults change over time, and I don't want things to break when people upgrade to a newer release. Thank you for not blowing away existing config files. You're expected to run "postfix upgrade-configuration" instead. As for shlib_dir in main.cf: shlib_dir not only specifies at BUILD time the location for libpostfix-*, information that the runtime linker needs to use to start a Postfix program, before any Postfix program can look up settings in main.cf. shlib_dir also specifies at RUN time the location of dynamically-loaded database clients (ldap, mysql, pgsql, etc.). Postfix programs look up this setting from main.cf, and therefore this location may be changed after Postfix is built. You mention the PORTING document. It likely needs updating, as it was last updated in 2004, about 10 years before I adopted support for dynamic linking in Postfix 3.0. Wietse
Re: probably bug in postfix3-3.4
natan maciej milaszewski: Thenx for replay: May? 5 06:00:51 smtp1 postfix/smtpd[5939]: warning: Illegal address syntax from unknown[217.153.30.34] in RCPT command: <> ... May? 5 06:00:54 smtp1 postfix/smtpd[6444]: warning: unknown[111.72.195.23]: SASL LOGIN authentication failed: authentication failure May? 5 06:00:54 smtp1 postfix/submission/smtpd[6464]: warning: hostname zg-0428c-286.stretchoid.com does not resolve to address 162.243.138.183: Name or service not known nothing else On 06.05.20 09:07, Wietse Venema wrote: That is FOUR SECONDS of Postfix logging. That us even less than the Postfix timeout for delivering mail over SMTP. You need to collect logs over at least 5 minutes. ideally, check logs between reload and when you notice postfix not running. mail that enters queue active and qmgr that fints is there is expected. the question is why nothing happened to the mail later. see one some of queue ids in logs: May 6 14:14:45 server postfix/smtpd[10544]: connect from XXX[10.x.x.x] May 6 14:14:45 server postfix/smtpd[10544]: 56BD5280282: client=XXX[10.x.x.x] May 6 14:14:45 server postfix/cleanup[10678]: 56BD5280282: message-id=<1588767287@xxx.sk> May 6 14:14:45 server postfix/qmgr[2545]: 56BD5280282: from=, size=1035, nrcpt=2 (queue active) May 6 14:14:45 server postfix/smtpd[10544]: disconnect from XXX[10.x.x.x] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 May 6 14:14:45 server postfix/smtp[10680]: 56BD5280282: to=, relay=YYY[y.y.y.y]:25, delay=0.14, delays=0.07/0/0.06/0.01, dsn=2.0.0, status=sent (250 2.0.0 046CEjeo032470-046CEjeq032470 Message accepted for delivery) May 6 14:14:45 server postfix/qmgr[2545]: 56BD5280282: removed -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges.
Re: probably bug in postfix3-3.4
natan maciej milaszewski: > Thenx for replay: > > May? 5 06:00:51 smtp1 postfix/smtpd[5939]: warning: Illegal address > syntax from unknown[217.153.30.34] in RCPT command: <> ... > May? 5 06:00:54 smtp1 postfix/smtpd[6444]: warning: > unknown[111.72.195.23]: SASL LOGIN authentication failed: authentication > failure > May? 5 06:00:54 smtp1 postfix/submission/smtpd[6464]: warning: hostname > zg-0428c-286.stretchoid.com does not resolve to address 162.243.138.183: > Name or service not known > > nothing else That is FOUR SECONDS of Postfix logging. That us even less than the Postfix timeout for delivering mail over SMTP. You need to collect logs over at least 5 minutes. Wietse
explicit shlib_directory in main.cf
Hi, I have noticed than postfix-install script explicitly adds shlib_directory to the main.cf file e.g. during non-interactive install. Is there any reason why such approach is better than relying on compiled-in default value? PACKAGE_README.html suggests to provide small main.cf file. My concern is that main.cf is marked as config files e.g. in RPM packages, so if administrator touched it than file content is preserved during package upgrade. If an alternative package is built without support of shared libraries or with different value, it requires a dedicated action to configure proper directory in post-install scripts. Am I wrong that everything should just work if shlib_directory is mentioned neither in original package nor in its update? I expected something like if [ "$shlib_directory" = "`bin/postconf -c conf -d -hx shlib_directory`" ]; then bin/postconf -c $CONFIG_DIRECTORY -# "shlib_directory" || exit 1 else bin/postconf -c $CONFIG_DIRECTORY -e "shlib_directory = $shlib_directory" || exit 1 fi Sorry, if I missed discussion of this point. Thanks
Re: probably bug in postfix3-3.4
On 5/05/20 5:04 pm, natan maciej milaszewski wrote: Hi I have a centos 7 and postfix3-3.4.7-1.gf.el7.x86_64 I reload postfix via: postfix reload May 5 06:00:52 smtp1 postfix/master[22162]: reload -- version 3.4.7, configuration /etc/postfix And new mail was only added to queue active They did not want to leave and the queue was growing May 5 06:00:52 smtp1 postfix/qmgr[6439]: 49GQwf3mj4z4D6T: from=, size=80199, nrcpt=2 (queue active) May 5 06:00:52 smtp1 postfix/qmgr[6439]: 49GQx260b4z4D8d: from=, size=835317, nrcpt=1 (queue active) May 5 06:00:52 smtp1 postfix/qmgr[6439]: 49GQwh3Cxjz4D7f: from=, size=80307, nrcpt=2 (queue active) May 5 06:00:52 smtp1 postfix/qmgr[6439]: 49GQxP2LwLz4D9N: from=, size=27942, nrcpt=1 (queue active) May 5 06:00:52 smtp1 postfix/qmgr[6439]: 49GQwf6SQPz4D6d: from=, size=80210, nrcpt=2 (queue active) Problem was fixed after restart postfix I tested reload ~4 times and the problem happened again For second test i relod postfix via systemd (service postfix reload) - works fine I do find this strange because all that systemd does on reload is call this command: /usr/sbin/postfix reload ...which is basically the same command that you're running. Try explicitly running /usr/sbin/postfix reload, though, just in case there's another script getting in the way for you, or an alias or function. It might also pay to look into your environment, certain environment variables and settings will differ between the environment that systemd has when it issues the reload and the one in your shell. You can also try: bash --noprofile --norc -c '/usr/sbin/postfix reload' Can you check to make sure you're root when you issue postfix reload? try temporarily turning off selinux with: setenforce 0 ...don't forget to turn it back on: setenforce 1 ...double check /var/log/maillog in the latest version of postfix, make sure to record any log entries that show up at the exact time you run "postfix reload". There should at least be some log entry that shows postfix reloading: May 6 20:23:04 CentOS7 postfix/postfix-script[1789]: refreshing the Postfix mail system May 6 20:23:04 CentOS7 postfix/master[1618]: reload -- version 3.5.0, configuration /etc/postfix Compare your output to what you get with service postfix reload and see if there's any difference. You may also be able to see the logs with: service postfix status Is the problem still in the latest version of postfix if you enable the gf-testing repo and update? yum --enablerepo=gf-testing update postfix3\* Also double check that the postfix install itself has not been corrupted: rpm -V postfix3 ...if you get no output, or only output that reflects changes to config files, then the install is fine. Wietse already pointed you at the DEBUG_README. In addition to the section that he pointed you to, have a look through the rest to see what you can do. Specifically the sections titled "Manually tracing a Postfix daemon process" and below that. Do the traces with both reload commands and compare the output between them. Let me know what you find so I can fix the packages from Ghettoforge in case it has something to do with the package builds. Also if all of the above doesn't reveal the issue I can provide you with RPMs that don't have the usual set of CentOS patches applied for you to try, then we can troubleshoot from there. Good luck and let me know how you get on. Peter
