Re: [exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Viktor Dukhovni via Exim-users
> On Nov 13, 2019, at 7:10 PM, Cyborg via Exim-users > wrote: > > It would be better to change the rfc and make it mandatory to log the > version and cipher used ;) There's no IETF RFC police. MTAs will log what their developers and administrators conspire to log. So there's no "mandatory",

Re: [exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Cyborg via Exim-users
Am 13.11.19 um 18:27 schrieb Wolfgang Breyha via Exim-users: > I think it's no good idea to change the default in favor of that RFC while > dropping important information like the TLS Version used. > Those informations are vital to make checks for contacts, using old and broken tls versions.

Re: [exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Viktor Dukhovni via Exim-users
> On Nov 13, 2019, at 6:01 PM, Wolfgang Breyha via Exim-users > wrote: > >> I agree that the new format is inadequate, especially for TLS 1.3. >> In Postfix I've kept, and even expanded the "comment" form of the >> TLS trace info. For example: > > Do you know of any proposed improvements to

Re: [exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Wolfgang Breyha via Exim-users
On 13/11/2019 18:46, Viktor Dukhovni via Exim-users wrote: > I agree that the new format is inadequate, especially for TLS 1.3. > In Postfix I've kept, and even expanded the "comment" form of the > TLS trace info. For example: Do you know of any proposed improvements to RFC 8314? I did not find

Re: [exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Viktor Dukhovni via Exim-users
On Wed, Nov 13, 2019 at 06:27:42PM +0100, Wolfgang Breyha via Exim-users wrote: > While testing 4.93-RCx I recognized that it uses a new default for Received: > headers including TLS information as RFC 8314 defines it using > by with esmtps tls TLS_AES_256_GCM_SHA384 > instead of > by with

[exim] Exim 4.93 Received Header tls clause

2019-11-13 Thread Wolfgang Breyha via Exim-users
Hi! While testing 4.93-RCx I recognized that it uses a new default for Received: headers including TLS information as RFC 8314 defines it using by with esmtps tls TLS_AES_256_GCM_SHA384 instead of by with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) Am I the only one missing the TLS

Re: [exim] conditional email forwards to another host

2019-11-13 Thread Lars Schimmer via Exim-users
On 11/13/19 8:47 AM, Andrew C Aitchison wrote: > On Tue, 12 Nov 2019, Lars Schimmer via Exim-users wrote: > >> Hi! >> >> I need a little help, mostly for security. >> I do run a exim4 host (debian), and I want to forward all emails >> incoming for 3-5 Emails to another host (NOT a different

Re: [exim] conditional email forwards to another host

2019-11-13 Thread Lars Schimmer via Exim-users
On 11/13/19 7:23 AM, Jasen Betts via Exim-users wrote: > On 2019-11-12, Lars Schimmer via Exim-users wrote: > >> Hi! >> >> I need a little help, mostly for security. >> I do run a exim4 host (debian), and I want to forward all emails >> incoming for 3-5 Emails to another host (NOT a different

Re: [exim] Client-initiated renegotiation

2019-11-13 Thread Jeremy Harris via Exim-users
On 13/11/2019 11:03, jmedard--- via Exim-users wrote: > Do you know how I could force this option directly on OpenSSL? Like an > openssl.cfg configuration ! I'm not aware of a way. However, the forthcoming 4.93 release will support that option (and have it set as default). -- Cheers, Jeremy

Re: [exim] Determining smarthoust address from message

2019-11-13 Thread Jeremy Harris via Exim-users
On 12/11/2019 13:02, Richard Evans via Exim-users wrote: > server_set_id = $auth1 > > and then referring to $authenticated_id in the route_data expression.  > But debug shows that $authenticated_id expands to empty in the > route_data setup, which I guess make sense since the authentication >

[exim] Determining smarthoust address from message

2019-11-13 Thread Richard Evans via Exim-users
Hi I'm trying to setup an Exim configuration to allow users to test sending emails from an application.  Users will run their own mail receiver (such as Java's fakesmtp) but always send to the central Exim server. So I would like the smarthost route_data to be derived from /something/ in

[exim] Client-initiated renegotiation

2019-11-13 Thread jmedard--- via Exim-users
Hello, Unlike other OpenSSL options provided on Exim via "openssl_options", it is not possible for the moment to set the current option on OpenSSL 1.1.1: "-no_renegotiation" (SSL_OP_NO_NO_RENEGOTIATION) in order to avoid the possibility of DDOS on "Client-initiated renegotiation". That's a