Re: [exim] Issue with Larger email deliveries and TLS

Góra strony
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
Dla: Andrew McCombe
CC: exim-users
Temat: Re: [exim] Issue with Larger email deliveries and TLS
On 2011-02-05 at 15:12 +0000, Andrew McCombe wrote:
> I have run strace on the process Id that the google mail was coming in on
> which I have pasted below (at least, the last few lines - it is a large
> mail). However, I'll admin I don't really understand the contents of the
> trace. There is a 'Bad file descriptor' line before the log file is opened.


The file descriptor number there is the value you get when you take -1
in 32 bits and interpret it as unsigned.

fd 6 is never closed, so it looks as though something is losing fd 6 as
a reference.

> I'm a bit reluctant to compile Exim from scratch as the current set-up is
> running Ubuntu 9.04 LTS and is on a third party server. However I will do
> this at a last resort.


So at present, Exim is reporting an error from the TLS library and then
continuing. A little more checking shows that this is GnuTLS (for that
particular message).

If you were running Exim 4.73 or newer, I'd suggest using the debug
control in the ACL logic to turn on base+TLS debugging for any
connections from netblocks listed in Google's SPF records, which would
go to a new log-file; the SPF support could stand to be improved to make
this easier. :/

If you do choose to build a new Exim to test the SSL logic then you
might want to grab 4.74, read the README.UPDATING to deal with the new
security stance, and try something like this in an ACL registered for
acl_smtp_connect:

  warn    condition = ${if match_ip {$sender_host_address}{\
    <; ${map {<; ${filter {<; ${sg{${lookup dnsdb{txt=_spf.google.com}}}{\N\s+\N}{;}}}{match{$item}{ip[46]:}}}}\
             {${sg{$item}{\N^ip[46]:\N}{}}}}}}
        control = debug/tag=.gmail/opts=+tls


This should create a new log-file "debuglog.gmail" which will contain
debug logging for all connections from Gmail, with TLS debugging turned
up.

I'll, er, think about making an "spf" lookup type to make that a little
less horrendous. :) This only works because _spf.google.com is the
final target referenced when you look for SPF TXT records for
@gmail.com.

> recvfrom(6, "\27\3\1\5\210", 5, 0, NULL, NULL) = 5
> recvfrom(6,
> "\221\365em\360\254\375\250\3747\2566\264\263#K\210o\327\271\31r\6kLp\264\312\22(\266\327"...,
> 1415, 0, NULL, NULL) = 964
> recvfrom(6, "", 451, 0, NULL, NULL)     = 0
> alarm(0)                                = 1800
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
> close(4294967295)                       = -1 EBADF (Bad file descriptor)


So, GnuTLS which I'm not really familiar with, but as I look through the
code, I'm not seeing a close() by Exim before logging the result. This
could be oversight on my part. But for the time being, I'm inclined to
suspect that the bad close(-1) is also inside GnuTLS.

-Phil