Re: [exim-dev] Disabling BDAT by default for upcoming Debian stable release?

[Heiko Schlittermann]

Andreas Metzler  (Do 19 Jan 2017 15:44:17 CET):
> Hello,
> 
> I am considering to temporarily disable BDAT in Debian's exim packages.
> 
> Afaict BDAT in exim is still stabilizing, multiple issues have shown up
> since 4.88 and some are still unfixed.
> 
> OTOH we (Debian) do not have time to wait for BDAT to get ready. Debian
> is currently preparing for a new stable release. On February 5 the "Full
> Freeze" will come into effect, i.e. uploads targeted for the release
> will require manual approval by the release team. (With the ten day
> waiting period for automatic appproval, the upload deadline is about
> January 26.
> 
> I would apply the attached patch.
> Any thoughts, strong opinions against?

Good idea. We survived years w/o chunking :)

> diff --git a/src/src/globals.c b/src/src/globals.c
> index 90e46dff..8f26487a 100644
> --- a/src/src/globals.c
> +++ b/src/src/globals.c
> @@ -494,7 +494,7 @@ BOOLcheck_rfc2047_length   = TRUE;
>  int check_spool_inodes = 100;
>  int check_spool_space  = 10*1024;/* 10K Kbyte == 10MB */
>  
> -uschar *chunking_advertise_hosts = US"*";
> +uschar *chunking_advertise_hosts = NULL;
>  unsigned chunking_datasize = 0;
>  unsigned chunking_data_left= 0;
>  BOOLchunking_offered   = FALSE;

The above patch is Ok, IMHO.


> diff --git a/src/src/transports/smtp.c b/src/src/transports/smtp.c
> index 87082717..314d74f1 100644
> --- a/src/src/transports/smtp.c
> +++ b/src/src/transports/smtp.c
> @@ -206,7 +206,7 @@ smtp_transport_options_block 
> smtp_transport_option_defaults = {
>NULL,/* serialize_hosts */
>NULL,/* hosts_try_auth */
>NULL,/* hosts_require_auth */
> -  US"*",   /* hosts_try_chunking */
> +  NULL,/* hosts_try_chunking */
>  #ifdef EXPERIMENTAL_DANE
>NULL,/* hosts_try_dane */
>NULL,/* hosts_require_dane */

But this patch?? As far as I know, the issues with chunking are
*inbound*, not outbound, so, the disabling chunking for outgoing
connections isn't strictly necessary.

But I'd add update the spec, just in case somebody reads it:

--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -14437,12 +14437,14 @@ may wish to deliberately disable them.
 .wen
 
 .new
-.option chunking_advertise_hosts main "host list&!!" *
+.option chunking_advertise_hosts main "host list&!!" unset
 .cindex CHUNKING advertisement
 .cindex "RFC 3030" "CHUNKING"
 The CHUNKING extension (RFC3030) will be advertised in the EHLO message to
 these hosts.
 Hosts may use the BDAT command as an alternate to DATA.
+(Defaulting this option to "unset" is Debian specific. Nativ Exims
+default to "*".)
 .wen
 
 .option daemon_smtp_ports main string &`smtp`&


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
-- 
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -


signature.asc
Description: Digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] Disabling BDAT by default for upcoming Debian stable release?

[Andreas Metzler]

On 2017-01-19 Jeremy Harris  wrote:
> On 19/01/17 14:44, Andreas Metzler wrote:
> > Any thoughts, strong opinions against?

> It's the right way to do it, and probably wise
> given the outstanding bug against CHUNKING vs. DKIM.

Thank you for doublechecking the patch.

I have just uploaded since I 
a) had some time, and
b) it's easy to undo by re-upoading without the patch.

cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] Disabling BDAT by default for upcoming Debian stable release?

[Jeremy Harris]

On 19/01/17 14:44, Andreas Metzler wrote:
> Any thoughts, strong opinions against?

It's the right way to do it, and probably wise
given the outstanding bug against CHUNKING vs. DKIM.
-- 
Cheers,
  Jeremy


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] Disabling BDAT by default for upcoming Debian stable release?

[Andreas Metzler]

Hello,

I am considering to temporarily disable BDAT in Debian's exim packages.

Afaict BDAT in exim is still stabilizing, multiple issues have shown up
since 4.88 and some are still unfixed.

OTOH we (Debian) do not have time to wait for BDAT to get ready. Debian
is currently preparing for a new stable release. On February 5 the "Full
Freeze" will come into effect, i.e. uploads targeted for the release
will require manual approval by the release team. (With the ten day
waiting period for automatic appproval, the upload deadline is about
January 26.

I would apply the attached patch.

Any thoughts, strong opinions against?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
>From 6ed375c38b0d7a743fa37e61ac4353cd34aeed9e Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Thu, 19 Jan 2017 15:16:45 +0100
Subject: [PATCH] Disable chunking (BDAT) by default.

Change default value of main option chunking_advertise_hosts and
smtp transport option hosts_try_chunking from "*" to empty.
---
 src/src/globals.c | 2 +-
 src/src/transports/smtp.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/src/globals.c b/src/src/globals.c
index 90e46dff..8f26487a 100644
--- a/src/src/globals.c
+++ b/src/src/globals.c
@@ -494,7 +494,7 @@ BOOLcheck_rfc2047_length   = TRUE;
 int check_spool_inodes = 100;
 int check_spool_space  = 10*1024;	/* 10K Kbyte == 10MB */
 
-uschar *chunking_advertise_hosts = US"*";
+uschar *chunking_advertise_hosts = NULL;
 unsigned chunking_datasize = 0;
 unsigned chunking_data_left= 0;
 BOOLchunking_offered   = FALSE;
diff --git a/src/src/transports/smtp.c b/src/src/transports/smtp.c
index 87082717..314d74f1 100644
--- a/src/src/transports/smtp.c
+++ b/src/src/transports/smtp.c
@@ -206,7 +206,7 @@ smtp_transport_options_block smtp_transport_option_defaults = {
   NULL,/* serialize_hosts */
   NULL,/* hosts_try_auth */
   NULL,/* hosts_require_auth */
-  US"*",   /* hosts_try_chunking */
+  NULL,/* hosts_try_chunking */
 #ifdef EXPERIMENTAL_DANE
   NULL,/* hosts_try_dane */
   NULL,/* hosts_require_dane */
-- 
2.11.0

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2016] DKIM bodyhash mismatch on Gmail > 64kB

[admin]

https://bugs.exim.org/show_bug.cgi?id=2016

Andreas Metzler  changed:

   What|Removed |Added

 CC||eximus...@bebt.de

--- Comment #5 from Andreas Metzler  ---
(In reply to Jeremy Harris from comment #4)
> Possibly a duplicate of bug 2004?

No, it still seems to be reproducible even with
f4630439f888df191a151ac935eacf04517fb2ee (CHUNKING: fix non-pipelined synch
checks.  Bug 2004) applied.

-- 
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/ ##

Re: [exim-dev] [Bug 2018] proxy protocol is not supported on smtps (direct SSL/TLS) connections

[Phil Pennock]

On 2017-01-18 at 16:06 +, Jeremy Harris wrote:
> To expand: Exim's implementation of Proxy Protocol
> is currently hooked in after the TLS start done for
> tls-on-connect.
> 
> It turns out that the protocol spec document is ambiguous
> and the other way about (proxy-protocol handling done
> in-clear, then TLS) is the preferred way for HAproxy.
> 
> Is anyone using and relying on the current Exim implementation
> ordering?   Or shall I just swap them round?

I think that Jeremy knows my opinion here, but so that others know what
is likely to happen if nobody speaks up:

I strongly favour swapping them around, putting a note in
README.UPDATING and avoiding adding yet another knob.

So if you are relying upon something which speaks Proxy Protocol
initiating its _own_ TLS connection to an Exim TLS-on-connect backend,
_then_ speaking PP within that, _before_ passing off to hand-off from
the origin client, then you need to speak up with some details so that
we can understand and weigh the cost of the added complexity, and make
sure that we can then handle it without ending up with TLS tunnelled
inside TLS.

-Phil

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [exim] [Bug 2018] proxy protocol is not supported on smtps (direct SSL/TLS) connections

[Viktor Dukhovni]

On Wed, Jan 18, 2017 at 04:06:05PM +, Jeremy Harris wrote:

> It turns out that the protocol spec document is ambiguous
> and the other way about (proxy-protocol handling done
> in-clear, then TLS) is the preferred way for HAproxy.
> 
> Is anyone using and relying on the current Exim implementation
> ordering?   Or shall I just swap them round?

It seems unlikely that HAproxy terminates TLS, posesses certificates
for all the ultimate end-points and initiates another TLS connection
to the target service.  So, as a default, I would guess that the
proxy protocol never runs inside TLS.  Given the current code,
getting confirmation for the hunch from the user community before
an incompatible change seems sensible.

-- 
Viktor.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##