Re: [exim] 30 second wait for protocol timeout exceeded

On Wed, 15 Feb 2006, Jakob Hirsch wrote:

> As I understand, ident information was not intended to be useful for
> the requesting system, but for the requested system.

Agreed. Nevertheless, there's a few tell-tale $sender_ident values
which are good for an immediate rejection: the ones which stick in my
memory are "squid" and "CacheFlow Server", although instances of those
have faded down with time: anything with "proxy" in it would also seem
deeply suspicious, and I dare say an inspection of logged idents would
show up a few more which smell bad and are most unlikely to represent
a bona fide MTA.

> Unix systems with shell access for many users seem to be not very
> common any more. But I'd say it can still be useful without much
> effort.

In a way, it's a pity that so many firewalls are configured to just
drop these packets on the floor, instead of actively rejecting them:
but it does seem to be the usual approach, so, if one makes the
request, it does usually provoke a timeout. I was running with exim's
rfc1413_query_timeout set at 7s for a long time, but I've no reason to
suppose that 5s wouldn't be adequate really.

As for being on the other end of such an ident, it seemed to me that
a multi user system could beneficially use the crypted option of
pidentd, to return a token which gives nothing away to the "other
side", but if presented by their admin to the admin of the issuing
system, can be validated and decoded.

Nowadays, however, our campus firewall blocks outgoing port 25 coming
from any host that isn't a registered MTA, and the registered MTA
hosts don't allow ordinary users to log on to them, so the scenario of
needing to identify *users* who are abusing email in this way, doesn't
really happen nowadays in our situation, in the way it would have
done in the heyday of such multi-user systems.

regards