[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

2016-10-07 Thread admin
https://bugs.exim.org/show_bug.cgi?id=1895

Andreas Metzler  changed:

   What|Removed |Added

 CC||eximus...@bebt.de

--- Comment #4 from Andreas Metzler  ---
BTW I think the documentation on tls_dhparam is not completely correct for
GnuTLS:

If Exim is using OpenSSL and this option is empty or unset, then Exim will load
a default DH prime; the default is the 2048 bit prime described in section 2.2
of RFC 5114, "2048-bit MODP Group with 224-bit Prime Order Subgroup", which in
IKE is assigned number 23.

Afaict this is not OpenSSL-specific but also applies to GnuTLS.

-- 
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 1897] New: Exim not falling back to non-TLS on callouts

2016-10-07 Thread admin
https://bugs.exim.org/show_bug.cgi?id=1897

Bug ID: 1897
   Summary: Exim not falling back to non-TLS on callouts
   Product: Exim
   Version: 4.86+ HEAD
  Hardware: x86
OS: Linux
Status: NEW
  Severity: bug
  Priority: medium
 Component: ACLs
  Assignee: jgh146...@wizmail.org
  Reporter: chir...@spamexperts.com
CC: exim-dev@exim.org

In exim 4.86.2+fixes, TLS communication was enabled by default when doing
callouts. However we sometimes deliver messages to some Exchange(?) machines
("Microsoft ESMTP MAIL Service", I don't have any information about them) that
have problems with TLS.

While delivering the emails we always see in the log:

```
TLS error on connection (SSL_connect): error::lib(0):func(0):reason(0)
TLS error on connection (SSL_connect): error::lib(0):func(0):reason(0)
TLS error on connection (SSL_connect): error::lib(0):func(0):reason(0)
```

Messages are still delivered successfully as Exim will simply fallback on
non-TLS somehow and the messages is correctly sent. 

After we enabled TLS on callouts as well, ALL callouts deferred for those
Exchange servers, so we are not able to verify the recipients. It seems that
for callouts Exim doesn't fallback on non-TLS. The exact same error appearing
in the exim mainlog. 

Unfortunately managing a list of servers that have such problems is not really
an option for me. Even though I'm 100% this is just an issue with their
configuration. 

I think it would make sense if the behavior from message delivery to be copied
to the callouts as well.

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