Bug#482404: confirming the issue + "workaround"

[Yaroslav Halchenko]

Today a friend of mine told me that he got an email which we were
waiting for, but I didn't get it although should have... WTF?
I looked in the logs and saw multiple logs like

2009-08-01 21:50:19 TLS error on connection from smtp.mssupport.microsoft.com [131.107.1.37] (gnutls_handshake): A TLS packet with unexpected length was received.

Sure it is easy to blame M$ but this time I really wanted to have my server to
be able to receive those emails from the evil empire.  Quick search through
google and exim4 bugs lead me to this report. Suggested solution to reduce the
number of available certificates via dpkg-reconfigure ca-certificates resolved
the problem (I left available probably around 8 or so among >50 available) and
almost immediately got the email which M$ was so desperately to deliver.

Running little statistics on the logs since March 2009, here is the list
of the domains/hosts which were similarly unsuccessful at their delivery:

6 : 89.83.35.72.in-addr.arpa domain name pointer ns1a.itechosting.net.
8 : 100.64/26.75.195.82.in-addr.arpa domain name pointer liszt.debian.org.
11 : 29.162.103.70.in-addr.arpa domain name pointer master.debian.org.
14 : 218.93.198.88.in-addr.arpa domain name pointer projects.openmoko.org.
15 : Host 2.131.141.58.in-addr.arpa. not found: 3(NXDOMAIN)
27 : Host 155.222.124.222.in-addr.arpa. not found: 3(NXDOMAIN)
28 : 10.186.248.60.in-addr.arpa domain name pointer a1.nichia.com.tw.
48 : 184.83.31.69.in-addr.arpa domain name pointer nylug.org.
50 : 41.192.231.204.in-addr.arpa domain name pointer smtp-cpk.frontbridge.com.
232 : 131.207.1.195.in-addr.arpa domain name pointer mail1.ktf-as.no.
271 : 214.62.107.209.in-addr.arpa domain name pointer mail2.clancysystems.com.
278 : 37.1.107.131.in-addr.arpa domain name pointer smtp.mssupport.microsoft.com.
430 : 162.56.60.202.in-addr.arpa domain name pointer smtp.instun.gov.my.
753 : 124.227.7.208.in-addr.arpa is an alias for 208.7.227.124.clancysystems.com.
2422 : 203.124.198.88.in-addr.arpa domain name pointer sita.openmoko.org.
4901 : 36.81.68.200.in-addr.arpa domain name pointer mail.anmat.gov.ar.

As you can see -- even debian servers had quite few failures, although probably
delivery was succesfull on some  trial afterwards (could original failures be
due to lack of entropy?? or smth else?)

I know that this issue is not that critical in general but imho it deserves
higher severity than normal since it undermines reliability of exim server? and
how good is smth unreliable in as critical system as the mail server? ;)

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-exim4-maintainers/attachments/20090801/9d5b5d7f/attachment.pgp>