RE: [exim] sender verify at verizon.net (sigh)

Pàgina inicial
Delete this message
Reply to this message
Autor: Alan J. Flavell
Data:  
A: 'Exim users list'
Assumpte: RE: [exim] sender verify at verizon.net (sigh)
On Tue, 22 Feb 2005, Eli wrote:

[much snippage]
> I used to run ident on the servers as well (and on webservers too),
> however nothing ever used ident except for email, and even then it
> was completely 100% useless [...]


The question whether you're running identd yourself, and whether
you're making identd queries of others, are two quite independent
questions: each should be decided on their own merits, IMO.

> I found that using internal checks to record the real sending user
> far more useful than ident ever was, so I (think) I turned off the
> ident checks in Exim, and I turned off the ident daemon on the
> servers as well.


Well, that's your choice, with which I'd have no dispute as far as
your own server is concerned.[1] It doesn't necessarily fit everyone
else's profile, is all that I'm getting at.

> It can be faked so easily anyways, it's one of those legacy things
> which is really useless in the current day.


I think you're missing the point. Anyone who *cares* about their
identd would be running encrypted tokens, and they cannot be faked
without an even more-serious security compromise.

On the other hand, as you quoted me saying - but apparently didn't
care to comment on - those folks who were responding "CacheFlow
Server", "squid" etc. to us didn't *try* to fake anything: we didn't
even need to burden the dnsRBLs with a query, because the offering
MTA's identd told us all that we needed to know, and we kicked the
caller off.

So it's a matter of scale rather than of principle, IMO. And by now
I'd agree there isn't a lot to be gained. But I've not seen it cause
much grief, so I'm comfortable with it for a while yet.

all the best

[1] although, thinking it into our own situation - some years back we
were penetrated by an intruder who (as subsequent investigations
showed) was calmly using our resources for 8 weeks before being
discovered. It would have been handy if any of the sites he was
attacking had been able to provide our encrypted identd token. As it
turned out, I got a phone call from Chicago late on a Friday afternoon
- our time - complaining about being attacked from one of our hosts.
And that was my weekend washed out. But that's some years back now!
And we've learned quite a bit more about security since!!