Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
On Fri, Oct 22, 2021 at 10:34:20PM +0100, Simon Arlott via Exim-dev wrote: > It is likely that pipelining the QUIT results in the connection being > closed with outgoing data discarded. It's entirely possible that a > stateful firewall decides not to allow the half-closed connection to > transfer the remaining data. Possible, and perhaps on the sender's end rather than at Yahoo? FWIW, Postfix also pipelines QUIT, and I don't recall seeing similar reports on postfix-users. > A packet capture of this issue would be useful. Yes, definitely. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
It is likely that pipelining the QUIT results in the connection being closed with outgoing data discarded. It's entirely possible that a stateful firewall decides not to allow the half-closed connection to transfer the remaining data. A packet capture of this issue would be useful. -- Simon Arlott -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
On Fri, Oct 22, 2021 at 08:17:03PM -, Jasen Betts via Exim-dev wrote: > >> If this is really an exim bug, it's still worth correcting it, but you > >> should > >> really disable pipelining to yahoo, even when this bug will be resolved. > > > > Why would they bother advertising PIPELINING, if they don't > > actually mean to tolerate its use? That does not seem right... > > > > BINARYMIME > RFC3030 (https://datatracker.ietf.org/doc/html/rfc3030#section-4.2) > doesn't show pipelined BDAT: the sender synchronises before sending > body data. Dropping the connection seems like a resonable response > to such a synchronisation error. > > PIPELINING > RFC2920 (https://datatracker.ietf.org/doc/html/rfc2920) > synchrionises the pipeline before any message content is trasmitted > (the "DATA" command is allowed but the sender must wait for "354" > before sending content) The yahoo.co.jp domain advertises only PIPELINING not CHUNKING or BINARYMIME: < 250-mtagw7025.mail.djm.ynwp.yahoo.co.jp < 250-PIPELINING < 250-8BITMIME < 250 SIZE 2048 If they wanted to punish senders for *using* it, WTF advertise it? -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
On 2021-10-22, Viktor Dukhovni via Exim-dev wrote: >> On 22 Oct 2021, at 11:45 am, admin--- via Exim-dev wrote: >> >> For what it's worth, by experience, you should avoid sending anything to any >> yahoo domains using pipelining. They will just retaliate on you if you do it, >> they will, for example, greylist the servers using pipelining but will allow >> the other ones. >> If this is really an exim bug, it's still worth correcting it, but you should >> really disable pipelining to yahoo, even when this bug will be resolved. > > Why would they bother advertising PIPELINING, if they don't > actually mean to tolerate its use? That does not seem right... > BINARYMIME RFC3030 (https://datatracker.ietf.org/doc/html/rfc3030#section-4.2) doesn't show pipelined BDAT: the sender synchronises before sending body data. Dropping the connection seems like a resonable response to such a synchronisation error. PIPELINING RFC2920 (https://datatracker.ietf.org/doc/html/rfc2920) synchrionises the pipeline before any message content is trasmitted (the "DATA" command is allowed but the sender must wait for "354" before sending content) -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
> On 22 Oct 2021, at 11:45 am, admin--- via Exim-dev wrote: > > For what it's worth, by experience, you should avoid sending anything to any > yahoo domains using pipelining. They will just retaliate on you if you do it, > they will, for example, greylist the servers using pipelining but will allow > the other ones. > If this is really an exim bug, it's still worth correcting it, but you should > really disable pipelining to yahoo, even when this bug will be resolved. Why would they bother advertising PIPELINING, if they don't actually mean to tolerate its use? That does not seem right... -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2816] Repeated deliveries to yahoo.co.jp
https://bugs.exim.org/show_bug.cgi?id=2816 Renaud Allard changed: What|Removed |Added CC||ren...@allard.it --- Comment #13 from Renaud Allard --- For what it's worth, by experience, you should avoid sending anything to any yahoo domains using pipelining. They will just retaliate on you if you do it, they will, for example, greylist the servers using pipelining but will allow the other ones. If this is really an exim bug, it's still worth correcting it, but you should really disable pipelining to yahoo, even when this bug will be resolved. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2822] DHE ciphers missing, under GnuTLS
https://bugs.exim.org/show_bug.cgi?id=2822 --- Comment #6 from Ferry --- Until they fix it, it might be wise to set the dhparams, load the referenced ones from RFC7919 or not ignoring tls_dhparam. Without it, it's broken. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2822] DHE ciphers missing, under GnuTLS
https://bugs.exim.org/show_bug.cgi?id=2822 Jeremy Harris changed: What|Removed |Added See Also||http://bugs.debian.org/9681 ||45 --- Comment #5 from Jeremy Harris --- (In reply to Ferry from comment #4) > According to the responses there either: > gnutls_certificate_set_dh_params or gnutls_certificate_set_known_dh_params > should be called. For both of those the GnuTLS docs say "This function is unnecessary and discouraged on GnuTLS 3.6.0 or later. Since 3.6.0, DH parameters are negotiated following RFC7919." We're doing what those docs say. It they are *wrong* then it's a bug in GnuTLS, or in the GnuTLS docs. We'd like to know, but I see no project acknowlegement of the issue in the Gitlab page you reference, or action. > If someone would set tls_dhparam [...] or the > option should be removed. If we did that someone would raise it as a bug. We can't win. We do document that is is ignored, in the main-section options chapter. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
