Ted Cooper wrote:
> Ron Gorodetzky wrote:
>> I found that at least one of the misbehaving messages was hanging on the
>> following:
>>
>> initializing GnuTLS as a client
>> generating 512 bit RSA key...
>> selecting on subprocess pipes
>> selecting on subprocess pipes
> ...
>> That seemed to do the trick. I'm not entirely sure why the other
>> supposed fixes didn't work. I certainly support the use of tls (I use
>> it for smtp between client apps when I setup a mail server with
>> authentication) so it feels odd turning it off. Is it common practice
>> to leave it on for server to server mail exchange? Should I expect a
>> lot of rejected mail using this setting?
>
> Your computer ran out of entropy while generating a transaction key. It
> will just hang there forever until it gathers enough. If GnuTLS fixed
> the problem then I would assume that it installs a cached or looped
> device that generates random data without stalling. A /dev/urandom
> instead of a /dev/random.
>
> TLS is a negotiated addition to the connection. If you have it turned on
> and the other end wants to talk TLS too then it will be used. It
> shouldn't cause rejected mails at all and now that you have infinite not
> so random but probably good enough randomness, it should no longer block.
>
> You're probably better off putting those other settings back to defaults
> unless they prove to be problematic in some other way.
Woops! I read your mail wrong, I thought you had fixed the entropy
issue. Anyway, it's a known bug.
http://wiki.debian.org/PkgExim4KnownBugsInSarge
There is a solution to it... but it's a little whack. Something like
that might help your problem though.
There's even a slightly less secure one which is link /dev/random to
/dev/urandom. That is usually considered A Bad Thing though as you loose
your real randomness.
--
The Exim Manual
http://www.exim.org/docs.html
http://www.exim.org/exim-html-current/doc/html/spec_html/index.html
