Hi
> warning: run-time library vs. compile-time header version mismatch:
> OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0
Is this warning still relevant with OpenSSL's new versioning scheme,
where OpenSSL 3.x releases are guaranteed[1] to be ABI compatible ?
[1] http
On Thu, Oct 24, 2024 at 10:50:18AM +0200, Geert Hendrickx via Postfix-users
wrote:
> > warning: run-time library vs. compile-time header version mismatch:
> > OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0
>
> Is this warning still relevant with OpenSSL's new ver
On Thu, Oct 24, 2024 at 20:00:05 +1100, Viktor Dukhovni via Postfix-users wrote:
> And this is the logic used in Postfix >= 3.10-20240612, but while you've
> upgraded to a shiny new OpenSSL, you haven't also upgraded to a shiny new
> Postfix snapshot. :-)
This is using standard Arch Linux package
t; that message has already been returned to the sender.
>
> Thank you. It is not empty but I am not sure what I am looking at:
>
> postcat -eq 7883F510EBC | grep warning_message_time
> warning_message_time: Wed Dec 31 18:59:59 1969
This means that the warning message was already se
On Tue, 21 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
The most current message (edited for privacy):
Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
from=, size=1
Doug Denault:
> On Mon, 20 Feb 2023, Wietse Venema wrote:
>
> > Doug Denault:
> >> On Mon, 20 Feb 2023, Wietse Venema wrote:
> >>
> >>> Doug Denault:
> The most current message (edited for privacy):
>
> Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
> from=, size=1
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
The most current message (edited for privacy):
Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport po
Doug Denault:
> On Mon, 20 Feb 2023, Wietse Venema wrote:
>
> > Doug Denault:
> >> The most current message (edited for privacy):
> >>
> >> Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
> >> from=, size=1943447, nrcpt=41 (queue active)
> >> Feb 20 09:25:15 freeport postfix/smtp[67456
On Mon, 20 Feb 2023, Rob McGee wrote:
On 2/20/2023 4:20 PM, Doug Denault wrote:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
The most current message (edited for privacy):
Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
from=, size=1943447, nrcpt=41 (queue active)
Feb
On Mon, 20 Feb 2023, Rob McGee wrote:
On 2/20/2023 9:25 AM, Doug Denault wrote:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Sun, 19 Feb 2023, Viktor Dukhovni wrote:
On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
With my setup no warning is deferred errors
On 2/20/2023 4:20 PM, Doug Denault wrote:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
The most current message (edited for privacy):
Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
The most current message (edited for privacy):
Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
from=, size=1943447, nrcpt=41 (queue active)
Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC:
to=, relay=none, delay=329
On 2/20/2023 9:25 AM, Doug Denault wrote:
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Sun, 19 Feb 2023, Viktor Dukhovni wrote:
On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
With my setup no warning is deferred errors such as 'time out' or
'Con
Doug Denault:
> The most current message (edited for privacy):
>
> Feb 20 09:25:14 freeport postfix/qmgr[88969]: 7883F510EBC:
> from=, size=1943447, nrcpt=41 (queue active)
> Feb 20 09:25:15 freeport postfix/smtp[67456]: 7883F510EBC:
> to=, relay=none, delay=329206,
> delays=329205/0.08/0.
On Mon, 20 Feb 2023, Wietse Venema wrote:
Doug Denault:
On Sun, 19 Feb 2023, Viktor Dukhovni wrote:
On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the messag
* messages. Messages already in the queue
will not elicit the warning. There's a queue-file record for that...
I'm sorry I was not clear. New messages do not get the warning.
This is a FreeBSD 12.2-RELEASE-p7. postfix 3.6.2_1
https://www.postfix.org/DEBUG_README.html#mai
Doug Denault:
> On Sun, 19 Feb 2023, Viktor Dukhovni wrote:
>
> > On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
> >
> >> With my setup no warning is deferred errors such as 'time out' or
> >> 'Connection refused' until
Doug Denault skrev den 2023-02-20 04:35:
With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.
if ...
I added:
delay_warning_time = 8h
to main.cf. This made no difference so I assume an a
hing.
> >
> > This setting only affects *new* messages. Messages already in the queue
> > will not elicit the warning. There's a queue-file record for that...
>
> I'm sorry I was not clear. New messages do not get the warning.
>
> This is a FreeBSD
On Sun, 19 Feb 2023, Viktor Dukhovni wrote:
On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.
I added:
delay_warning_time =
On Sun, Feb 19, 2023 at 10:35:43PM -0500, Doug Denault wrote:
> With my setup no warning is deferred errors such as 'time out' or
> 'Connection refused' until the message is delete from the queue.
>
> I added:
>
>delay_warning_time = 8h
>
> to
With my setup no warning is deferred errors such as 'time out' or
'Connection refused' until the message is delete from the queue.
I added:
delay_warning_time = 8h
to main.cf. This made no difference so I assume an additional setting is
required, but I cou
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
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
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/bounc
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)
postfix/local[1124
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: warni
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/li
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
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
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
>>
> 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
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/
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 talking to service
private/scache
I didn't suggest that it was, or should be.
As I didn't notice the reference in the thread, thought it might be helpful.
Not an issue for me either way.
PGNet Dev:
> perhaps of use
>
> https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrep
> https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html
Postfix is cross-platform, and not all the world uses GNU grep.
Wietse
perhaps of use
https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrep
https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html
postfix check
> >
>
> FYI, with grep 3.8, this triggers deprecation warnings on 'egrep':
>
> $ sudo postfix check
> egrep: warning: egrep is obsolescent; using grep -E
For the sake of portability I had to do a quick due diligence
for non-GNU grep implementations.
s triggers deprecation warnings on 'egrep':
$ sudo postfix check
egrep: warning: egrep is obsolescent; using grep -E
Usage of 'egrep' in postfix-script (as well as postfix-tls-script)
should be replaced with 'grep -E', patch attached.
The documentation refers to egrep/fgr
On Thu, Oct 06, 2022 at 01:37:39PM -0400, Viktor Dukhovni wrote:
> It is possible that your resolver has fallen victim to the RHEL/Fedora
> "crypto policy" changes that by default disable (i.e. make fail)
> RSAwithSHA1 signature validation.
>
> https://lwn.net/Articles/887832/
> https://b
On Thu, Oct 06, 2022 at 12:19:48PM -0400, PGNet Dev wrote:
> I see lots of these,
>
> 2022-10-05T17:30:13.277421-04:00 mx03 postfix/smtp-out-ext/smtp[8484]:
> warning: DANE TLSA lookup problem:
> Host or domain name not found.
> Name service
PGNet Dev:
> 2022-10-05T17:30:13.277421-04:00 mx03 postfix/smtp-out-ext/smtp[8484]:
> warning: DANE TLSA lookup problem: Host or domain name not found. Name
> service error for name=_25._tcp.christopher-ew.state.gov type=TLSA: Host not
> found, try again
The Postfix SMTP cl
[8477]: disconnect from
internal.mx.example.net[10.17.1.32] ehlo=1 xforward=2 mail=1 rcpt=1 data=1
quit=1 commands=7
2022-10-05T17:30:13.277421-04:00 mx03 postfix/smtp-out-ext/smtp[8484]:
warning: DANE TLSA lookup problem: Host or domain name not found. Name service
error for name=_25
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
t
> > 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 event handling (typic
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
gt; > 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 handling (typically, whether or not a
> file descriptor
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 Post
abnormally high memory or cpu usage.
I've searched through the logs just before it happens, but I don't see anything
that triggers it. The OS is RHEL 7.9.
Aug 15 14:40:35 mx03 postfix/master[1553]: warning: service "smtpd"
(private/smtpd) has reached its process limit &qu
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
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
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
ix/smtps/smtpd[11831]: warning:
unknown[178xxx.xxx.58]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Jun 5 23:25:08 saturn postfix/smtps/smtpd[11831]: lost connection after
AUTH from unknown[178.88.160.58]
Jun 5 23:25:08 saturn postfix/smtps/smtpd[11831]: disconnect from
unknown[178.xxx.xxx
Hi
On 01.06.22 12:17, Maurizio Caloro wrote:
I don't know much about Acme.sh, but it doesn't look right combining
"--rsa-key-size 4096" and "--key-type ecdsa".
Yes try with command certbot
I think raf is referring to the mismatch between algorithm, i.e. ECDSA,
and the key specification and
>I don't know much about Acme.sh, but it doesn't look right combining
"--rsa-key-size 4096" and "--key-type ecdsa".
>
>cheers,
>raf
Yes try with command certbot
Maurizio
On Tue, May 31, 2022 at 02:18:35PM +0200, Maurizio Caloro
wrote:
> Hello Viktor
> Thanks for your Answer. the creation of this Cert are the following:
>
> The one key-type are for RSA and ECDSA
> Acme.sh certonly --standalone --rsa-key-size 4096 --domain
> nmail.caloro.ch --key-type
On Tue, May 31, 2022 at 02:18:35PM +0200, Maurizio Caloro wrote:
> ## RSA
> /etc/letsencrypt/live/nmail.caloro.ch-rsa/privkey.pem
> /etc/letsencrypt/live/nmail.caloro.ch-rsa/fullchain.pem
>
> >These are the same as the below.
> Corrected now to other folder(writing error)
> ## ECDSA
>
On 31/05/2022 16:38, Jaroslaw Rafa wrote:
Dnia 31.05.2022 o godz. 22:18:56 Bret Busby pisze:
I keep seeing "AW" prepended to message subjects and I have no idea
of what it means.
What does it mean?
Some MUA authors falsely assume that the string "Re:" at the beginning of
subject of a reply i
Dnia 31.05.2022 o godz. 22:18:56 Bret Busby pisze:
>
> I keep seeing "AW" prepended to message subjects and I have no idea
> of what it means.
>
> What does it mean?
Some MUA authors falsely assume that the string "Re:" at the beginning of
subject of a reply is a shortcut for the English word "R
On 5/31/2022 10:18 AM, Bret Busby wrote:
I keep seeing "AW" prepended to message subjects and I have no idea of
what it means.
What does it mean?
I believe it's the German equivalent for re:
(https://en.wikipedia.org/wiki/List_of_email_subject_abbreviations) as
in Regarding.
Regards,
KAM
On 31/5/22 7:05 pm, Maurizio Caloro wrote:
Hello.
I keep seeing "AW" prepended to message subjects and I have no idea of
what it means.
What does it mean?
--
Bret Busby
Armadale
West Australia
(UTC+0800)
..
ck to just one key type for now.
Yes at this time no forwarding possibilities, thanks for possible update
Maurizio
-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org Im
Auftrag von Viktor Dukhovni
Gesendet: Dienstag, 31. Mai 2022 13:41
An: postfix-users@postfix.org
Betreff:
On Tue, May 31, 2022 at 01:05:57PM +0200, Maurizio Caloro wrote:
> Today create new my key file RSA, and ECDSA, and signed with certbot.
>
> ## TLS/SSL
> /etc/letsencrypt/live/nmail.caloro.ch/privkey.pem
> /etc/letsencrypt/live/nmail.caloro.ch/fullchain.pem
What does "TLS/SSL" mean?
13:00:24 nmail postfix/smtps/smtpd[27271]: warning: key at index 1 in
/etc/letsencrypt/live/nmail.caloro.ch-rsa/privkey.pem does not match next
certificate
May 31 13:00:24 nmail postfix/smtps/smtpd[27271]: warning: TLS library
problem: error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing
On Mon, May 30, 2022 at 08:52:21AM +0200, Maurizio Caloro wrote:
> try to install RSA and ECDSA, but it's don't run like normal mode.
Simplest in most cases (and quite sufficient) to stick to just one
algorithm. Multiple algorithms require a deeper understanding of
what you're doing.
> Generate
< Log >
May 30 08:37:05 postfix/smtps/smtpd[27908]: warning: No certs for key at
index 1 in /etc/letsencrypt/live/nmail.caloro.ch/postfix-rsa.key
/etc/letsencrypt/live/nmail.caloro.ch/postfix_ecc.key
May 30 08:37:05 postfix/smtps/smtpd[27908]: warning: error loading private
keys and ce
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
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
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
> >
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
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
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
h can cause signal 11
--
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.
- Have you got anything without Spam in it?
- Well, there's Spam e
Looks good, I see nothing concerning here or in the FreeBSD patches
for the postfix ports.
Wietse
Michael Grimm wrote:
> Wietse Venema wrote:
>> I can use some additional information, off-list email preferred.
Well I screwed it ;-)
Regards,
Michael
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
I can use some additional information, off-list email preferred.
Complete output from:
postconf -n
postconf -P
Again, off-list email preferred.
Wietse
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
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
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
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
after 0 from [89.248.165.24]:61384:
>> \003\000\000/*\340\000\000\000\000\000Cookie:
>> mstshash=Administr\r\n\001\000\b\000\003\000\000\000
>> Mar 25 03:43:17 mx2.lan postfix/master[2645]: warning: process
>> /usr/local/libexec/postfix/postscreen pid 5463 killed by sign
000\003\000\000\000
> Apr 19 03:49:08 mx2.lan postfix/postscreen[17604]: CONNECT from
> [94.232.41.27]:48397 to [10.1.1.1]:25
> Apr 19 03:49:08 mx2.lan postfix/postscreen[17604]: PREGREET 44
> after 0 from [94.232.41.27]:48397:
> \003\000\000,'\340\000\000\000\000\000Coo
03:49:08 <mail.info> mx2.lan postfix/postscreen[17604]: CONNECT from [94.232.41.27]:48397 to [10.1.1.1]:25Apr 19 03:49:08 <mail.info> mx2.lan postfix/postscreen[17604]: PREGREET 44 after 0 from [94.232.41.27]:48397: \003\000\000,'\340\000\000\000\000\000Cookie: mstshash=Domain
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
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
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
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.
88 after
\026\003\003\001\245\001\000\001\241\003\003\037\r\f\371\240\320\2070Q\307\302\3048\241l-=\335\330C\360$\263\304\271\017\335
\276\035:\361\242
z\236\345\333\257\334_b\324fB\333\a\026`\213\365\225n\321M\036\237
Mar 28 01:33:22 mail.lan postfix/tlsproxy[7185]: DISCONNECT
[1.2.3.4]:5
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:
>
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
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
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.
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 .
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
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
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
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
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
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
1 - 100 of 818 matches
Mail list logo
