https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #11 from Jeremy Harris ---
I can't tell in general. I've not had any reports of similar from users on
my own servers, but you'll be handling more traffic than me. Probably worth
your while scanning logs for other yahoo destinations, in
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #10 from David Carter ---
Yes, hosts_avoid_pipelining has fixed the dropped connections, and email is now
delivered immediately:
2021-10-10 10:03:54 +0100 1mZUkM-00037M-se <= dp...@ppsw.cam.ac.uk U=dpc22
P=local S=562 for
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #9 from Jeremy Harris ---
Yup, that's a useful debuglog. They're screwing up pipelining. Let's disable
it for these hosts and run another test:
hosts_avoid_pipelining = *.yahoo.co.jp
set on the transport.
--
You are receiving this
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #8 from David Carter ---
Created attachment 1397
--> https://bugs.exim.org/attachment.cgi?id=1397=edit
debuglog for 1mZF9E-000LUC-rJ
Hopefully the correct ticket this time around.
--
You are receiving this mail because:
You are on the
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #7 from David Carter ---
My user states:
"Yes, I have received 6 copies each of your first and second mail test mails."
(sent using Exim 4.95)
Yes indeed, I received only one copy of your "third test" mail.
(send using Exi 4.94.2 from
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #6 from David Carter ---
I have a debuglog, but "control = debug" in the ACL only captured the initial
delivery attempt (which failed),
2021-10-09 17:25:08 +0100 1mZF9E-000LUC-rJ <= dp...@cam.ac.uk
H=ppsw-50.csi.cam.ac.uk (me)
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #5 from Jeremy Harris ---
There might be something different about the .123 host which allowed it
to give a definitive response. It's only seen in that one case, above.
But that doesn't tell us why the others fail.
The delivery line for
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #4 from David Carter ---
Just to add:
This isn't a transcient problem at the yahoo.co.jp end.
That was my immediate assumption based on a collection of dropped connections
following by a single successful delivery in my logs (see below).
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #3 from David Carter ---
I was using "invalid_t...@yahoo.co.jp" as a test address, as I do't have an
account on that system. Presumably we could create one if we find someone who
speaks Japanese, or we could ask my user to translate for the
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #2 from Jeremy Harris ---
The test using "invalid_t...@yahoo.co.jp" doesn't appear to have delivered
at all, according to our end's visibility. I'm unclear how this ties up to
the complaint about a legitimate account there getting multiple
https://bugs.exim.org/show_bug.cgi?id=2806
--- Comment #1 from David Carter ---
For what it is worth, I see exactly the same behaviour with 4.95 if I
disable:
DKIM signing
tls_require_ciphers.
hosts_randomize
Also: "message_linelength_limit = 100" which was a configuration change
from
11 matches
Mail list logo
