[pfx] Re: warning: table lmdb key malformed value

thanks, Even had it my notes, I skipped two releases of OS and some changes to binaries made me anxious a bit, unnecessarily. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: warning: table lmdb key malformed value

lejeczek via Postfix-users: > May 06 12:31:20 brama.mine.priv > postfix/submission/smtpd[80067]: warning: table > lmdb:/etc/postfix/snis.map: key mail.kupa.xyz: malformed > BASE64 value: /etc/letsencrypt/live/mail.lem You need to follow the instructions (use "postnap -F") for populating the SNI

Re: warning: unexpected protocol delivery_request_protocol from private/bounce socket (expected: delivery_status_protocol)

I am seeing the subjected error for a small percentage of messages, and then those message stay in the deferred queue. from the log: postfix/local[1124]: warning: unexpected protocol delivery_request_protocol from private/bounce socket (expected: delivery_status_protocol) On 1/1/23 19:01, Wiet

Re: warning: unexpected protocol delivery_request_protocol from private/bounce socket (expected: delivery_status_protocol)

On 1/1/23 19:01, Wietse Venema wrote: > trading fours: >> I am seeing the subjected error for a small percentage of messages, and >> then those message stay in the deferred queue. >> >> from the log: >> postfix/local[1124]: warning: unexpected protocol delivery_request_protocol >> from private/boun

Re: warning: unexpected protocol delivery_request_protocol from private/bounce socket (expected: delivery_status_protocol)

trading fours: > I am seeing the subjected error for a small percentage of messages, and > then those message stay in the deferred queue. > > from the log: > postfix/local[1124]: warning: unexpected protocol delivery_request_protocol > from private/bounce socket (expected: delivery_status_protocol

Re: warning: disabling connection caching

Demi Marie Obenour: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. > On 12/20/22 06:13, Wietse Venema wrote: > > Fourhundred Thecat: > >> Hello, > >> > >> I had this in my logs: > >> > >>postfix/master: warning: process /usr/lib/postfix/sbin/scache pid > >> 1215 k

Re: warning: disabling connection caching

On 12/20/22 06:13, Wietse Venema wrote: > Fourhundred Thecat: >> Hello, >> >> I had this in my logs: >> >>postfix/master: warning: process /usr/lib/postfix/sbin/scache pid >> 1215 killed by signal 11 >>postfix/master: warning: /usr/lib/postfix/sbin/scache: bad command >> startup -- thrott

Re: warning: disabling connection caching

On Tue, Dec 20, 2022 at 06:28:21AM +0100, Fourhundred Thecat wrote: > I had this in my logs: > >postfix/master: warning: process /usr/lib/postfix/sbin/scache pid 1215 > killed by signal 11 This is the problem, not lack of connection caching. Perhaps you've replaced the OpenSSL or other sh

Re: warning: disabling connection caching

On 20.12.22 06:28, Fourhundred Thecat wrote: postfix/master: warning: process /usr/lib/postfix/sbin/scache pid 1215 killed by signal 11 is this HW machine? Signal 11 indicates HW (usually memory) problems if it repeats. Maybe corrupt filesystem data. -- Matus UHLAR - fantomas, uh...@fantom

Re: warning: disabling connection caching

On December 20, 2022 11:40:02 AM UTC, Fourhundred Thecat <400the...@gmx.ch> wrote: >> On 2022-12-20 12:13, Wietse Venema wrote: >> Fourhundred Thecat: >> >>> Also, if I wanted to test scache, how can I trigger it? >>> >>> If I send one email to multiple email addresses on same domain, will >>

Re: warning: disabling connection caching

> On 2022-12-20 12:13, Wietse Venema wrote: Fourhundred Thecat: Also, if I wanted to test scache, how can I trigger it? If I send one email to multiple email addresses on same domain, will this trigger scache? (ie, deliver multiple emails in one connection to the server?) Did you build Postf

Re: warning: disabling connection caching

Fourhundred Thecat: > Hello, > > I had this in my logs: > >postfix/master: warning: process /usr/lib/postfix/sbin/scache pid > 1215 killed by signal 11 >postfix/master: warning: /usr/lib/postfix/sbin/scache: bad command > startup -- throttling >postfix/smtp: warning: problem ta

Re: warning: cannot connect to service private/smtpd

Brad Chandler: > VMware. Is there anything that can be done on the VMware side to prevent this? If a platform causes Postfix watchdog timeouts, then it is not supported. There are tons of web search hits for VMware lost interrupts, and for VMware time keeping. This is for Linux guests: https://k

Re: warning: cannot connect to service private/smtpd

VMware. Is there anything that can be done on the VMware side to prevent this? --- Original Message --- On Thursday, August 25th, 2022 at 6:32 AM, Wietse Venema wrote: > > > Brad Chandler: > > > Aug 15 18:51:24 mx03 postfix/smtpd[13552]: fatal: watchdog timeout > > Aug 15 18:51:2

Re: warning: cannot connect to service private/smtpd

Brad Chandler: > Aug 15 18:51:24 mx03 postfix/smtpd[13552]: fatal: watchdog timeout > Aug 15 18:51:25 mx03 postfix/master[1553]: warning: process > /usr/libexec/postfix/smtpd pid 13552 exit status 1 Wietse: > That is a Postfix safety mechanism for rare infrastructure bugs > that mess up Postfix e

Re: warning: cannot connect to service private/smtpd

Yes, these are virtual machines. The OS is Red Hat Enterprise Linux 7.9. --- Original Message --- On Thursday, August 25th, 2022 at 2:52 AM, Wietse Venema wrote: > > > Brad Chandler: > > > Aug 15 18:51:24 mx03 postfix/smtpd[13552]: fatal: watchdog timeout > > Aug 15 18:51:25 mx03

Re: warning: cannot connect to service private/smtpd

Brad Chandler: > Aug 15 18:51:24 mx03 postfix/smtpd[13552]: fatal: watchdog timeout > Aug 15 18:51:25 mx03 postfix/master[1553]: warning: process > /usr/libexec/postfix/smtpd pid 13552 exit status 1 That is a Postfix safety mechanism for a rare infrastructure bugs that mess up Postfix event handl

Re: warning: unknown[137.xxx.xxx.253]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

Jim Garrison: > On 6/6/2022 3:13 AM, Jaroslaw Rafa wrote: > > Dnia 5.06.2022 o godz. 23:29:05 julio covolato pisze: > >> > >> I would like to know why these messages appear in the mail.log, > >> I know that "UGFzc3dvcmQ6" is base64 encoded for "Password:". > >> Is this some misconfigured internet

Re: warning: unknown[137.xxx.xxx.253]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

On 6/6/2022 3:13 AM, Jaroslaw Rafa wrote: Dnia 5.06.2022 o godz. 23:29:05 julio covolato pisze: I would like to know why these messages appear in the mail.log, I know that "UGFzc3dvcmQ6" is base64 encoded for "Password:". Is this some misconfigured internet mail server system (Windows)? Rath

Re: warning: unknown[137.xxx.xxx.253]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

Dnia 5.06.2022 o godz. 23:29:05 julio covolato pisze: > > I would like to know why these messages appear in the mail.log, > I know that "UGFzc3dvcmQ6" is base64 encoded for "Password:". > Is this some misconfigured internet mail server system (Windows)? Rather not a misconfigured server, but som

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

John Fawcett wrote: > On 20/04/2022 22:20, Michael Grimm wrote: >> this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD >> 13.1-STABLE. > > is this problem happening on one of the RC versions of FreeBSD 13.1? > > On the FreeBSD site at the moment, unless I'm misreading it, I

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On 20/04/2022 22:20, Michael Grimm wrote: Hi, this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD 13.1-STABLE. Michael is this problem happening on one of the RC versions of FreeBSD 13.1? On the FreeBSD site at the moment, unless I'm misreading it, I see the latest 13.1

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Wietse Venema wrote: > > Michael Grimm: > > > >> FTR: I am using poudriere for the compilation of every FreeBSD > >> port, and I do upgrade 13.1-STABLE on a (bi)weekly basis. So, all > >> postfix binaries considered in this thread have been recompiled > >> numerous times > >

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> FTR: I am using poudriere for the compilation of every FreeBSD >> port, and I do upgrade 13.1-STABLE on a (bi)weekly basis. So, all >> postfix binaries considered in this thread have been recompiled >> numerous times > > Well that may (part of) the pro

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Matus UHLAR - fantomas wrote: > > > > On 24.04.22 14:35, Wietse Venema wrote: > > >> Looks good, I see nothing concerning here or in the FreeBSD patches > >> for the postfix ports. > > > > while talking about FreeBSD, I'd consider recompiling required software > > you never kno

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Matus UHLAR - fantomas wrote: > > On 24.04.22 14:35, Wietse Venema wrote: >> Looks good, I see nothing concerning here or in the FreeBSD patches >> for the postfix ports. > > while talking about FreeBSD, I'd consider recompiling required software > you never know when binary compatibility it br

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On 24.04.22 14:35, Wietse Venema wrote: Looks good, I see nothing concerning here or in the FreeBSD patches for the postfix ports. while talking about FreeBSD, I'd consider recompiling required software you never know when binary compatibility it broken by random library upgrade, which can cau

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Looks good, I see nothing concerning here or in the FreeBSD patches for the postfix ports. Wietse

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm wrote: > Wietse Venema wrote: >> I can use some additional information, off-list email preferred. Well I screwed it ;-) Regards, Michael

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > I can use some additional information, off-list email preferred. Ok the following configuration is identical at both servers (besides hostname). > Complete output from: > >postconf -n autoresponder_destination_recipient_limit = 1 command_directory = /usr/local/sbin

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

I can use some additional information, off-list email preferred. Complete output from: postconf -n postconf -P Again, off-list email preferred. Wietse

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> I do have to admit that I haven't been using tcpdump a lot. I found 35 >> distinct IP addresses that do trigger 'signal 11'. I am currently running >> tcpdump on both servers with those addresses. AND: I did remove >> smtputf8_enable=8 on master.cf for

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > I do have to admit that I haven't been using tcpdump a lot. I found 35 > distinct IP addresses that do trigger 'signal 11'. I am currently running > tcpdump on both servers with those addresses. AND: I did remove > smtputf8_enable=8 on master.cf for these tests. Hope that's what

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm wrote > [had to remove one of two attachments due to 'Message too long' issue] And here is the previously omitted attachment. HTH and regards, Michael zMX1.txt.bz2 Description: BZip2 compressed data

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni wrote: > On Sat, Apr 23, 2022 at 10:28:37PM -0400, Wietse Venema wrote: >> It would be invaluable to have a recording of a complete session >> with that system. Something like: >> >>tcpdump -i name-of-interface is 2000 -w /file/name host 1.2.3.4 > > I think Wietse meant "-s

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni wrote: > On Sun, Apr 24, 2022 at 01:19:49PM +0200, Michael Grimm wrote: >> Mar 25 03:43:17 mx2.lan postfix/postscreen[5463]: CONNECT from >> [89.248.165.24]:61384 to [10.1.1.1]:25 >> Mar 25 03:43:17 mx2.lan postfix/postscreen[5463]: PREGREET 47 >> after 0 from [89.248.165.24]:

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On Sun, Apr 24, 2022 at 01:19:49PM +0200, Michael Grimm wrote: > This time the maillog files are unedited (besides my local hostnames), > thus showing the real IPs. Some do resolve, some not. > > I reported in my first post that all those 'signal 11' events were > headed by 'BARE NEWLINE' entries

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

[had to remove one of two attachments due to 'Message too long' issue] Wietse Venema wrote:Michael Grimm:Wietse Venema wroteWhat is the output from:postconf smtputf8_enableToday it is: smtputf8_enable = noThis is in main.cf. When was this changed? The c

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On Sat, Apr 23, 2022 at 10:28:37PM -0400, Wietse Venema wrote: > It would be invaluable to have a recording of a complete session > with that system. Something like: > > tcpdump -i name-of-interface is 2000 -w /file/name host 1.2.3.4 I think Wietse meant "-s 2000" rather than "is" 2000. The

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni: > On Sat, Apr 23, 2022 at 09:02:09PM -0400, Wietse Venema wrote: > > > The PREGREET logging for those eight craashing sessions shows that > > this client 1.2.3.4 was changing its TLS record version from 0x0303 > > (\003\003) to 0x0302 (\003\002) to 0x0301 (\003\001). > > > > Mar

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On Sat, Apr 23, 2022 at 09:02:09PM -0400, Wietse Venema wrote: > The PREGREET logging for those eight craashing sessions shows that > this client 1.2.3.4 was changing its TLS record version from 0x0303 > (\003\003) to 0x0302 (\003\002) to 0x0301 (\003\001). > > Mar 28 01:33:22 mail.lan postfix/p

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Wietse Venema wrote > > > Did you have NON-SMTP command events for the cases that had signal 11 > > errors? If so, can we have more complete logs for ONE such case? > > No, I haven't. I can find those entries a lot, but not in conjunction > with signal 11. Sorry for the noise.

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> Apr 23 12:07:45 mail.lan postfix/postscreen[61983]: PREGREET 159 >> after 0.03 from [1.2.3.4]:58878: >> \026\003\001\000\232\001\000\000\226\003\0030An';\265\235\335\250\344N,%\233Y\305\226\030tMb\024\b\3 >> Apr 23 12:09:49 mail.lan postfix/postscreen[

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote > Did you have NON-SMTP command events for the cases that had signal 11 > errors? If so, can we have more complete logs for ONE such case? No, I haven't. I can find those entries a lot, but not in conjunction with signal 11. Sorry for the noise. > What is the output from: >

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Apr 23 12:07:45 mail.lan postfix/postscreen[61983]: PREGREET 159 > after 0.03 from [1.2.3.4]:58878: > \026\003\001\000\232\001\000\000\226\003\0030An';\265\235\335\250\344N,%\233Y\305\226\030tMb\024\b\3 > Apr 23 12:09:49 mail.lan postfix/postscreen[4271]: PREGREET 159 > after

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Did you have NON-SMTP command events for the cases that had signal 11 errors? If so, can we have more complete logs for ONE such case? What is the output from: postconf smtputf8_enable Wietse

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On 4/23/22 20:14, Michael Grimm wrote: 1) Is smtputf8_enable=yes essential in email traffic as of today? Good question. Is there any other MTA besides postfix supporting SMTPUTF8? Ciao, Michael.

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> Wietse Venema wrote: >>> Would these commands make a difference (for Postfix 3.7 or 3.8): >>> >>> postconf -P smtp/inet/smtputf8_enable=no >>> postfix reload >> >> Done. Please give me 24/48 hours to respond, because these events >> are not that often .

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Wietse Venema wrote > > > Would these commands make a difference (for Postfix 3.7 or 3.8): > > > > postconf -P smtp/inet/smtputf8_enable=no > > postfix reload > > Done. Please give me 24/48 hours to respond, because these events > are not that often ... When I delete the posts

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote > Would these commands make a difference (for Postfix 3.7 or 3.8): > > postconf -P smtp/inet/smtputf8_enable=no > postfix reload Done. Please give me 24/48 hours to respond, because these events are not that often ... Thanks and with kind regards, Michael

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > > You have already mentined that the problem started after you > > updated from 3.6 to 3.7. > > Yes, postfix 3.6 didn't trigger my problem. > > But I wonder, if that the simultaneous upgrade of the openssl > package might be the cause of postscreen's dying after that "TLS > rand

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Would these commands make a difference (for Postfix 3.7 or 3.8): postconf -P smtp/inet/smtputf8_enable=no postfix reload There have been some invasive changes in postscreen 3.7 that imvolve the handling of SMTPUTF8 in SMTP commands. Postfix 3.6 did not care. Wietse

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> Wietse Venema wrote: >>> Viktor Dukhovni: That looks like a TLS client HELLO. Perhaps the client is misconfigured and using wrapper mode on port 25 instead of 465... >>> >>> It should not matter. postscreen is designed to handle random g

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Wietse Venema wrote: > > Viktor Dukhovni: > > >> That looks like a TLS client HELLO. Perhaps the client is misconfigured > >> and using > >> wrapper mode on port 25 instead of 465... > > > > It should not matter. postscreen is designed to handle random garbage. > > > > If you

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni: > On Wed, Apr 20, 2022 at 08:26:16PM -0400, Viktor Dukhovni wrote: > > > > this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD > > > 13.1-STABLE. > > > > You could install the "postfix" rather than "postfix-current" port. > > I have: > > > > -rw-r--r-- 1

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni wrote: > On Wed, Apr 20, 2022 at 08:26:16PM -0400, Viktor Dukhovni wrote: >>> this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD >>> 13.1-STABLE. >> >> You could install the "postfix" rather than "postfix-current" port. >> I have: >> >>-rw-r--r-- 1 root

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On Wed, Apr 20, 2022 at 08:26:16PM -0400, Viktor Dukhovni wrote: > > this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD > > 13.1-STABLE. > > You could install the "postfix" rather than "postfix-current" port. > I have: > > -rw-r--r-- 1 root wheel 13544 Mar 17 17:23 >

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

On Wed, Apr 20, 2022 at 10:20:56PM +0200, Michael Grimm wrote: > this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD > 13.1-STABLE. You could install the "postfix" rather than "postfix-current" port. I have: -rw-r--r-- 1 root wheel 13544 Mar 17 17:23 /usr/ports/mail/p

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Viktor Dukhovni: >> That looks like a TLS client HELLO. Perhaps the client is misconfigured and >> using >> wrapper mode on port 25 instead of 465... > > It should not matter. postscreen is designed to handle random garbage. > > If you could test withg Postfix 3.6 then

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Viktor Dukhovni: > > > On 20 Apr 2022, at 4:20 pm, Michael Grimm wrote: > > > > Apr 20 06:36:27 mail.lan postfix/postscreen[74803]: PREGREET > > 429 after 0 from [1.2.3.4]:49074: > > \026\003\003\001\250\001\000\001\244\003\003\327j\316\343\332\272\233\200\236\017\243`\342e\217\204\ > > That

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

> > On 20 Apr 2022, at 4:20 pm, Michael Grimm wrote: > > Apr 20 06:36:27 mail.lan postfix/postscreen[74803]: PREGREET 429 > after 0 from [1.2.3.4]:49074: > \026\003\003\001\250\001\000\001\244\003\003\327j\316\343\332\272\233\200\236\017\243`\342e\217\204\ That looks like a TLS client HELLO.

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Wietse Venema wrote: > Michael Grimm: >> this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD >> 13.1-STABLE. >> >> I do find comparable entries in my logfiles that I do not understand, >> honestly, like: > > The text from the remote client is encoded in octal, the way that

Re: warning: process /usr/local/libexec/postfix/postscreen pid xxxxx killed by signal 11

Michael Grimm: > Hi, > > this is postfix 3.8-20220325 (FreeBSD port postfix-current) on FreeBSD > 13.1-STABLE. > > I do find comparable entries in my logfiles that I do not understand, > honestly, like: The text from the remote client is encoded in octal, the way that C programs used to do suc

Re: warning: unreasonable macro call nesting

On Wed, Sep 15, 2021 at 04:17:40PM -0400, post...@ptld.com wrote: > Doing main.cf:milter_rcpt_macros = $milter_rcpt_macros {tls_version} That's a self-recursive definition that results in a variable expansion loop. > Are you supposed to be able to use $variables in milter_*_macros or is > it by

Re: warning: too many reverse jump records

Wietse Venema: > Mehmet Avcioglu: > > Wietse Venema: > > > Then I suspect that the code reaches the 1 limit because > > > there are ~1 files in the queue. > > > > > Below is a patch that should fix this. > > > > Thank you for the patch. I had previously said that we were not > > runni

Re: warning: too many reverse jump records

Mehmet Avcioglu: > Wietse Venema: > > Then I suspect that the code reaches the 1 limit because > > there are ~1 files in the queue. > > > Below is a patch that should fix this. > > Thank you for the patch. I had previously said that we were not > running 'showq' or 'postqueue -p' freq

Re: warning: too many reverse jump records

Wietse Venema: > Then I suspect that the code reaches the 1 limit because > there are ~1 files in the queue. > Below is a patch that should fix this. Thank you for the patch. I had previously said that we were not running 'showq' or 'postqueue -p' frequently, but upon further investig

Re: warning: too many reverse jump records

Mehmet Avcioglu: > > Now, Postfix queue files don't repair themselves spontaneously. > > Before I go off with speculation, I have a few questions to narrow > > the search: > > > > - Is only the showq process affected or other programs, too? > > Yes, only the 'showq' logs this message. > > > - Is

Re: warning: too many reverse jump records

Wietse Venema: > > Mehmet Avcioglu: > > I am getting "too many reverse jump records" messages. Couldn't find > > any information about this message and looking at the source code > > The postfix/showq logging repeats the same error for the same file, > every 15 seconds, presumably because you are r

Re: warning: too many reverse jump records

Mehmet Avcioglu: > I am getting "too many reverse jump records" messages. Couldn't find > any information about this message and looking at the source code > (record.c) it seems to be related with adding recipients and/or > headers, but I am not adding that many (1) of either. > > There is a m

Re: warning: dnsblog_query lookup error

On 08 Apr 2021, at 07:31, Benny Pedersen wrote: > On 2021-04-08 14:16, Matus UHLAR - fantomas wrote: >> in addition to this, you can whitelist outlook's IP ranges at postscreen >> level, as they "likely" aren't what postscreen is supposed to stop - bots. > > there is bots at microsoft, there serv

Re: warning: dnsblog_query lookup error

Benny Pedersen: > if anyone is willing to make c code to postfix it basicly SASL AUTH > Blacklist so postscreen can use this ip list to active block port 25 > clients Use something like fail2ban to update an lmdb-based postscreen_access_list, or to update an rbldns service. No Postfix changes ne

Re: warning: dnsblog_query lookup error

On 2021-04-08 18:22, Rob McGee wrote: Whitelisting in postscreen only affects postscreen itself, not any other ports nor services. http://www.postfix.org/postconf.5.html#postscreen_access_list fail2ban can make cidr list used in postscreen based on abuse on port other then port 25, wake up

Re: warning: dnsblog_query lookup error

On 2021-04-08 09:12, Benny Pedersen wrote: On 2021-04-08 15:56, Matus UHLAR - fantomas wrote: On 2021-04-08 14:16, Matus UHLAR - fantomas wrote: in addition to this, you can whitelist outlook's IP ranges at postscreen level, as they "likely" aren't what postscreen is supposed to stop - bots.

Re: warning: dnsblog_query lookup error

On 2021-04-08 15:56, Matus UHLAR - fantomas wrote: On 2021-04-08 14:16, Matus UHLAR - fantomas wrote: in addition to this, you can whitelist outlook's IP ranges at postscreen level, as they "likely" aren't what postscreen is supposed to stop - bots. On 08.04.21 15:31, Benny Pedersen wrote: th

Re: warning: dnsblog_query lookup error

On 2021-04-08 14:16, Matus UHLAR - fantomas wrote: in addition to this, you can whitelist outlook's IP ranges at postscreen level, as they "likely" aren't what postscreen is supposed to stop - bots. On 08.04.21 15:31, Benny Pedersen wrote: there is bots at microsoft, there servers try port 465

Re: warning: dnsblog_query lookup error

On 2021-04-08 14:16, Matus UHLAR - fantomas wrote: in addition to this, you can whitelist outlook's IP ranges at postscreen level, as they "likely" aren't what postscreen is supposed to stop - bots. there is bots at microsoft, there servers try port 465, and 587 randomly, no mta would do thi

Re: warning: dnsblog_query lookup error

On April 8, 2021 8:29:09 AM GMT+02:00, Maurizio Caloro wrote: I have the issue with mail from Outlook, or Hotmail this Warning appair and the mail don't deliver to me. Apr 8 08:04:24 ail postfix/dnsblog[7379]: warning: dnsblog_query: lookup error for DNS query 109.75.92.40.list.dnswl.org:

Re: warning: dnsblog_query lookup error

'm only using a local unbound on this server for name resolution. This is what I get: valo:~ $ dig 109.75.92.40.list.dnswl.org +short 127.0.3.0 valo:~ $ >Thanks >Mauri >-Ursprüngliche Nachricht- >Von: owner-postfix-us...@postfix.org >Im Auftrag von Christian Kivalo >

Re: warning: dnsblog_query lookup error

On April 8, 2021 8:29:09 AM GMT+02:00, Maurizio Caloro wrote: >Hello > >I have the issue with mail from Outlook, or Hotmail this Warning appair >and >the mail don't deliver to me. > > > >Apr 8 08:04:24 ail postfix/dnsblog[7379]: warning: dnsblog_query: >lookup >error for DNS query 109.75.92

Re: Warning: Hostname Does Not Resolve

On 09.03.21 15:26, Curtis Maurand wrote: your a record and fqdn, your helo/ehlo hostname and the ptr record all need to match. that's incorrect. IP address has to point to DNS name that maps back to the IP address. HELO (EHLO) hostname does not necessarily need to point to that DNS name. HE

Re: Warning: Hostname Does Not Resolve

Thank you Victor. The LAN is created by the Host physical server as a software construct -- there is no physical network connection outside of the Host. The Host and Virtual Machines (VMs) communicate on this LAN. The mail server is using an API that is available to the Host and all VMs for send

Re: Warning: Hostname Does Not Resolve

your a record and fqdn, your helo/ehlo hostname and the ptr record all need to match. Sent from my iPhone > On Mar 9, 2021, at 12:36 PM, Greg Sims wrote: > >  > We are receiving the following in our email logs: > > Mar 09 08:12:15 mail01.raystedman.org postfix/smtpd[13431]: warning: hostnam

Re: Warning: Hostname Does Not Resolve

On Tue, Mar 09, 2021 at 09:35:35AM -0800, Greg Sims wrote: > Mar 09 08:12:15 mail01.raystedman.org postfix/smtpd[13431]: > warning: hostname mail01.raystedman.org > does not resolve to address 192.168.122.12 An SMTP client at IP address 192.168.122.12 connected to your SMTP server. That IP a

Re: warning: Connection rate limit exceeded: 10 from localhost[127.0.0.1] for service 127.0.0.1:10025

On Thu, Oct 29, 2020 at 11:43:41AM +0100, Helmut Schneider wrote: > [helmut@BSDHelmut ~]$ postfix.sh -i postfix-in -C 'postconf > smtpd_client_connection_limit_exceptions' > Getting Instances ... done > Instance 'postfix-in': smtpd_client_connection_limit_exceptions = > /usr/local/etc/postfix-in

Re: warning: Connection rate limit exceeded: 10 from localhost[127.0.0.1] for service 127.0.0.1:10025

Am 29.10.2020 um 13:44 schrieb Matus UHLAR - fantomas: On 29.10.20 11:43, Helmut Schneider wrote: What did I miss? smtpd_client_connection_rate_limit Hum, the obvious...Thank you.

Re: warning: Connection rate limit exceeded: 10 from localhost[127.0.0.1] for service 127.0.0.1:10025

On 29.10.20 11:43, Helmut Schneider wrote: [helmut@BSDHelmut ~]$ postfix.sh -i postfix-in -C 'postconf smtpd_client_connection_limit_exceptions' you apparently mean smtpd_client_event_limit_exceptions postfix-in/master.cf: ### This is the after-filter smtpd, it receives mail from amavisd to

Re: warning: Illegal address syntax on submission

Kurt Roeckx: > Hi, > > The log file shows: > postfix/submission/smtpd[28578]: warning: Illegal address syntax from > unknown[192.168.1.144] in RCPT command: Indeed, unquoted whitespace is not valid in this context. > Since it's a user of my domain, I would expect to get an error. Is > there a

Re: Warning about non-existent MX for destination domain

On 10/03/2020 19:47, Gerald Galster wrote: what happens if you set delay_warning_time=1h or delay_warning_time=300  (as in 300 seconds)? In the template file it says hours, so everything below one hour might evaluate to zero? Best regards Gerald /"Time units: s (seconds), m (minutes), h (h

Re: Warning about non-existent MX for destination domain

On 10/03/2020 19:49, Dominic Raferd wrote: My responses seem like OP's: # host -t mx imake.ro 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host imake.ro not found: 2(SERVFAIL) # host -t mx sometotallyINVENTEDdomainTHATdoesNOTexist.com 8.8.8.8 Using domain server: Name:

Re: Warning about non-existent MX for destination domain

On Tue, Mar 10, 2020 at 12:18:28PM -0700, Fred Morris wrote: > NOERROR doesn't necessarily mean that there was an answer. The number of > answers to the question asked can be 0, even if the FQDN (fully qualified > domain name) exists, if some other type of information is associated with > it. I

Re: Warning about non-existent MX for destination domain

Let's try to clear up DNS even though that's not what the original querant is asking. On Tue, 10 Mar 2020, Wietse Venema wrote: Catalin Bucur: On 10/03/2020 17:16, Wietse Venema wrote: This is a problem with your DNS resolver WHICH IS NOT PART OF POSTFIX. You need to use a better DNS resolver

Re: Warning about non-existent MX for destination domain

On 10/03/2020 19:49, Dominic Raferd wrote: My responses seem like OP's: # host -t mx imake.ro 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host imake.ro not found: 2(SERVFAIL) # host -t mx sometotallyINVENTEDdomainTHATdoesNOTexist.co

Re: Warning about non-existent MX for destination domain

On Tue, 10 Mar 2020 at 17:37, Jaroslaw Rafa wrote: > Dnia 10.03.2020 o godz. 19:33:14 Catalin Bucur pisze: > > Google dns says: > > # host -t mx imake.ro 8.8.8.8 > > Using domain server: > > Name: 8.8.8.8 > > Address: 8.8.8.8#53 > > Aliases: > > Host imake.ro not found: 2(SERVFAIL) > > Something'

Re: Warning about non-existent MX for destination domain

> Gerald and Bill, you have both of you right, delay_warning_time it's the > parameter I was looking for. > Anyway, after setting up delay_warning_time=5m I noticed some warnings in > logs: > > Mar 10 17:52:02 mail postfix/bounce[7326]: warning: [built-in]: zero result > in delay template conv

Re: Warning about non-existent MX for destination domain

On 10/03/2020 19:33, Jaroslaw Rafa wrote: If you get reply 2(SERVFAIL) it means DNS server for the domain failed and did not return any usable reply, so we actually don't know if the domain exists or not. In that case Postfix SHOULD keep trying to deliver mail (maybe the DNS server for the domai

Re: Warning about non-existent MX for destination domain

Dnia 10.03.2020 o godz. 19:33:14 Catalin Bucur pisze: > Google dns says: > # host -t mx imake.ro 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > Host imake.ro not found: 2(SERVFAIL) Something's wrong with resolver library on your machine. Mine says: raj@rafa:~$ h

Re: Warning about non-existent MX for destination domain

Dnia 10.03.2020 o godz. 19:11:33 Catalin Bucur pisze: > You mean that I should modify standard configuration for my dns > server (resolver) to force reply that MX record does not exist, > instead of "Host doman.com not found: 2(SERVFAIL)" ? If you get reply 2(SERVFAIL) it means DNS server for the

Re: Warning about non-existent MX for destination domain

On 10/03/2020 19:26, Wietse Venema wrote: SERVFAIL (for a domain without MX record) means that something is broken. If the fault is not with your local resolver, then you need make sure that you point your resolver at a proper implementation. I have seen nonsense results from cheap routers that e

Re: Warning about non-existent MX for destination domain

SERVFAIL (for a domain without MX record) means that something is broken. If the fault is not with your local resolver, then you need make sure that you point your resolver at a proper implementation. I have seen nonsense results from cheap routers that expect queries from web clients that never as

  1   2   3   4   >