> On Aug 29, 2018, at 10:55 AM, Fazzina, Angelo <angelo.fazz...@uconn.edu>
> wrote:
>
> Hi, Thank you for the bread crumbs. After looking at my logs I do see
> differences in the "delay"
> from 0.72 to 2.2 seconds to send an email.
The time that it takes your server to deliver each message to its destination
nexthop is not visible to and does not slow down the sender. Senders deliver
to your queue, your queue delivers to the destination nexthop.
> Then I googled this little tid-bit:
> Postfix logs additional delay information as "delays=a/b/c/d" where a=time
> before queue manager, including message transmission; b=time in queue
> manager; c=connection setup time including DNS, HELO and TLS; d=message
> transmission time.
You don't generally need to be concerned with the "c" and "d" values. They
matter only under extreme stress, when the "active" queue is full, and the
queue manager stops reading the "incoming" queue until some mail is drained.
When that happens, messages may encounter an "inflow_delay", but that is
extremely unlikely in your case.
> If most of the time is in "d", what can I do to speed that up ?
Ignore the red-herring.
> I also went here http://www.postfix.org/TUNING_README.html and the only
> offense I seem to be making is using the header_checks variable so I can get
> the email subjects in my logs.
>
> Should my first test be to comment out "header_checks =
> regexp:/etc/postfix/header_checks" from my main.cf ?
Should not be a problem. More plausible is a DNS timeout issue with:
connect from unknown[137.99.149.148]
that could lead to connection setup delays, IIRC Postfix measures the
"a" time from the "MAIL FROM" command, not from the TCP connection
setup. Any latency doing DNS lookups for the client name is not
included. When I query for:
148.149.99.137.in-addr.arpa. IN PTR ?
I get a quick NXDOMAIN. Is that also true for your mail server?
> Below is a sample of 4 emails:
You're not seeing the forest for the trees, a sample of 4 is not that
interesting.
How many messages were sent by that user during a sustained transmission window.
What was the arrival rate? Did it change over that window?
> 09:22:43 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> 09:22:45 mail4 postfix/smtpd[16278]: disconnect from unknown[137.99.149.148]
>
> 09:23:06 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> 09:23:08 mail4 postfix/smtpd[16278]: disconnect from unknown[137.99.149.148]
>
> 09:23:12 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> 09:23:15 mail4 postfix/smtpd[16278]: disconnect from unknown[137.99.149.148]
>
> 09:23:17 mail4 postfix/smtpd[16278]: connect from unknown[137.99.149.148]
> 09:23:20 mail4 postfix/smtpd[16278]: disconnect from unknown[137.99.149.148]
If the client is doing one delivery at a time with a new connection for each
message, with no concurrency, what's interesting to see here is the spacing
*between* connections, which is considerably longer than the duration of
connections, which again hints at a possible DNS issue, but you have to
look more closely.
--
Viktor.
