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

Off topic (of the original subject), but just fyi... :)

Alan wrote:
> 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.


Yes, that is true - and as I just went back and checked (on my mail servers)
I had indeed disabled the ident daemon, as I was tired of seeing floods of
lookups for the exim user over and over again in the system logs - I've yet
to hear of a mail server rejecting mail because of no ident check, so I
currently see no harm in not serving ident requests on the mail servers.

I still had my ident checks enabled in Exim however, but have just removed
them - I figure if I don't want to serve out ident, I shouldn't expect
others to either. This information could be used by other postmasters in
tracking spammers down however, but my view is that I should be able to
provide you with a message ID and nothing more to track down an abusive
user. Not that I do that - I give all the headers in abuse cases, but you
should NEVER depend on others providing more information than you are sure
you provided them with, and ident information can't be known to ALWAYS be
received or accepted (it's not a mandatory part of the SMTP protocol... I
think).

For those two separate reasons I disabled ident daemon and ident auth checks
in Exim.

> > 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.

Quite true, I just trust myself more than others. I know if I record all
the information I know I'd need to track abusers down then I'm all good to
go. If others don't, that's their fault and not mine. I ensure that my
logs have all the info required, and that all email sent out by my users
have headers that will instantly lead me to the offending user - I like
making my job as easy as possible. Not to mention since ident information
is useless for me in *my* environments, that is why I don't run the ident
daemon any more. If I were using Cpanel however, I'd still be running it
(since it's part of how Cpanel tracks info for emails I believe).

> > 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.

Interesting, never heard about encrypted tokens, but yes I know it can't
easily be faked (can't on my servers unless I let you!). I was more meaning
that it could be purposefully faked on a remote system, thus making the
information my system collects rather useless, so for that reason I don't
much care to really track it.

> 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.

I would never reject a message based off of ident information alone.

> [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!!

I know that situation all too well - however it's not an issue on my
dedicated mail servers :)

Eli.