This problem was resolved off-list.
Greg Sims:
> Wietse & Viktor,
>
> All is not lost. Restarting BIND on Ray08 solved the problem of
> c=30!! I am sorry that I did not review/restart this service earlier.
> Your comments related to the 5 second intervals and DNS timeouts
> caused me to look th
On Thu, May 23, 2024 at 05:48:29PM -0400, Wietse Venema via Postfix-users wrote:
> Greg Sims via Postfix-users:
> > We see conn_use about 24% of the time:
>
> But none of the sessions shown in your message have that.
>
> Do they also have multiple-of-5-second type 'c' delays?
Indeed those multi
Greg Sims via Postfix-users:
> We see conn_use about 24% of the time:
But none of the sessions shown in your message have that.
Do they also have multiple-of-5-second type 'c' delays?
Wietse
___
Postfix-users mailing list -- postfix-users@post
On Thu, May 23, 2024 at 7:07 AM Greg Sims wrote:
>
> Thank you Viktor. All recommended changes have been made. I hope to
> collect useful "collate" data with our next distribution at Noon today
> pacific.
>
Still having problems with the inbound smtpd from our private network
flooding "collate".
Thank you Viktor. All recommended changes have been made. I hope to
collect useful "collate" data with our next distribution at Noon today
pacific.
I hope you have a great day! Greg
> [root@mail01 postfix]# postconf -nf
>
> [root@mail01 postfix]# postconf -Mf
___
On Wed, May 22, 2024 at 12:19:03PM -0500, Greg Sims wrote:
> [root@mail01 postfix]# postconf -nf
> maximal_backoff_time = 16m
> minimal_backoff_time = 2m
> queue_run_delay = 2m
FWIW (not related to your immediate issue) I would not recommend such a
short maximal backoff, you're potentiall
Greg Sims via Postfix-users:
> > It is assumed that you're not a victim of systemd-journald log mangling.
> > It may be dropping some messages, and recording others out of order,
> > breaking "collate". On Linux systems where systemd is doing the
> > logging, you'll want to have Postfix writing it
Alexander Leidinger via Postfix-users wrote in
:
|Am 2024-05-22 01:22, schrieb Greg Sims via Postfix-users:
|> TLS connection reuse is being used. About 10% of the connections are
|> reused for large volume ISPs. Small volume ISPs do not see connection
|> reuse. I believe this is as expected
> It is assumed that you're not a victim of systemd-journald log mangling.
> It may be dropping some messages, and recording others out of order,
> breaking "collate". On Linux systems where systemd is doing the
> logging, you'll want to have Postfix writing its own log files directly,
> bypassing
> This is perhaps a good time to ask you for your full configuration,
> not just cherry-picked individual settings. Please post the outputs of:
>
> $ postconf -nf
> $ postconf -Mf
>
> with all whitespace (including linebreaks) preserved.
[root@mail01 postfix]# postconf -nf
alias_datab
>
> If the delay is with sending or receiving RSET, then the SMTP client
> log "conversation with XXX timed out". I don't know if that has a
> queue ID logged with that, though. Just grep for 'conversation with'.
[root@mail01 postfix]# journalctl -u postfix.service | grep 'conversation with'
retu
Wietse Venema via Postfix-users:
> Greg Sims via Postfix-users:
> > May 22 03:13:22 mail01.raystedman.org t123/smtp[46725]:
> > 604BE30A4ACA: to=<@gmail.com>,
> > relay=gmail-smtp-in.l.google.com[142.251.2.26]:25, conn_use=2,
> > delay=1576, delays=0.05/1550/25/0.84, dsn=2.0.0, status=sent (250
>
> It is assumed that you're not a victim of systemd-journald log mangling.
> It may be dropping some messages, and recording others out of order,
> breaking "collate". On Linux systems where systemd is doing the
> logging, you'll want to have Postfix writing its own log files directly,
> bypassing
Greg Sims via Postfix-users:
> May 22 03:13:22 mail01.raystedman.org t123/smtp[46725]:
> 604BE30A4ACA: to=<@gmail.com>,
> relay=gmail-smtp-in.l.google.com[142.251.2.26]:25, conn_use=2,
> delay=1576, delays=0.05/1550/25/0.84, dsn=2.0.0, status=sent (250
> 2.0.0 OK 1716372802 41be03b00d2f7-6578166
On Wed, May 22, 2024 at 08:15:41AM -0500, Greg Sims via Postfix-users wrote:
> I am having problems with "collate". I greped a 10 minute portion of
> our mail.log which created a 6.8M file. I ran "collate" on this file
> and collected the output -- a 796M file. I looked at the file and it
> seem
I am having problems with "collate". I greped a 10 minute portion of
our mail.log which created a 6.8M file. I ran "collate" on this file
and collected the output -- a 796M file. I looked at the file and it
seems to be filled with records like the following:
May 22 02:10:00 mail01.raystedman.o
I have data collection homework to do -- and I will be happy to do it!
Config data and "collate" is next after morning meetings.
Here is some summary data by ISP from the logs:
Email Ave Max Conn
Relay SentDelay
Le 22/05/2024 à 12:35, Greg Sims via Postfix-users a écrit :
Thank you again for your feedback on this issue.
I watched the workload in real time this morning and now have more
insight into what is happening. It appears the large ISPs are using
TLS connection as a way to throttle incoming traff
Greg Sims via Postfix-users:
> This is a sample of delays= for google.com -- 20 and 25 second delays:
>
> 0.01/11/20/0.73,
> 0.01/9.5/20/0.77,
> 0.01/0/25/0.74,
> 0.01/7.6/25/0.91,
> 0.01/6.9/25/1.1,
> 0.01/13/20/4.6,
> 0.01/14/25/0.56,
> 0.01/14/25/1.1,
> 0.01/0/0.22/0.72,
> 0
On Wed, May 22, 2024 at 05:35:25AM -0500, Greg Sims wrote:
> Thank you again for your feedback on this issue.
You're welcome, but I don't see anything in your reply that responds
directly to my requests for more detailed configuration and log data.
> I watched the workload in real time this morn
Thank you again for your feedback on this issue.
I watched the workload in real time this morning and now have more
insight into what is happening. It appears the large ISPs are using
TLS connection as a way to throttle incoming traffic. I looked at the
inbound mail queue and found most of the t
On Tue, May 21, 2024 at 08:31:51AM -0500, Greg Sims wrote:
> Changes:
> * certs back to defaults
> * smtp_tls_loglevel = 1
Better. Now it is time to post a more detailed transcript of a single
message (the sender and recipient addresses can be obfuscated if you
wish, the recipient domain wou
Am 2024-05-22 01:22, schrieb Greg Sims via Postfix-users:
TLS connection reuse is being used. About 10% of the connections are
reused for large volume ISPs. Small volume ISPs do not see connection
reuse. I believe this is as expected.
I did some testing of our DNS setup. A DNS query using dig
TLS connection reuse is being used. About 10% of the connections are
reused for large volume ISPs. Small volume ISPs do not see connection
reuse. I believe this is as expected.
I did some testing of our DNS setup. A DNS query using dig is less
than 20 msec for both our primary and secondary dns
Jaroslaw Rafa via Postfix-users:
> Dnia 21.05.2024 o godz. 16:38:21 Wietse Venema via Postfix-users pisze:
> > > delays=0.01/2639/25/0.41
> > > delays=0.01/2639/25/0.58
> > > delays=0.01/2641/25/0.58
> > > delays=0.01/2644/25/0.69
> > > delays=0.01/2643/25/0.58
> > > delays=0.01/2640/25
Dnia 21.05.2024 o godz. 16:38:21 Wietse Venema via Postfix-users pisze:
> > delays=0.01/2639/25/0.41
> > delays=0.01/2639/25/0.58
> > delays=0.01/2641/25/0.58
> > delays=0.01/2644/25/0.69
> > delays=0.01/2643/25/0.58
> > delays=0.01/2640/25/0.57
[...]
> c=25s. It takes a whopping 25 eco
Greg Sims via Postfix-users:
> Thank you Viktor.
>
> Answers:
> * smtp_connection_cache_on_demand = yes -- this was configured
>
> Changes:
> * certs back to defaults
> * smtp_tls_loglevel = 1
>
> Before enabling TLS our send rate was about 4K emails per minute -- we
> are now seeing 300 t
Thank you Viktor.
Answers:
* smtp_connection_cache_on_demand = yes -- this was configured
Changes:
* certs back to defaults
* smtp_tls_loglevel = 1
Before enabling TLS our send rate was about 4K emails per minute -- we
are now seeing 300 to 500 per minute.
The email creation process is se
On Tue, May 21, 2024 at 06:51:08AM -0500, Greg Sims via Postfix-users wrote:
> Our main.cf contains:
> smtpd_tls_cert_file =
> smtpd_tls_key_file =
> smtpd_tls_security_level = none
There's no point in configuring SMTP server certificates when TLS is
disabled in the SMTP serv
29 matches
Mail list logo