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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
