[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More Ident nonsense

On Tue, Sep 28, 2004 at 02:18:17PM -0600, [email protected] wrote:
> I contend that this is infact not the case, at least not for MTAs
> developed within the last few years. I've seen no evidence that
> this happens with any of the three MTAs I mentioned that I have
> had the mispleasure of installing, configuring, and maintaining
> lately. I have actually looked for this condition with Sendmail
> v8+ using port monitoring and net sniffing tools, and not found
> it. Just don't believe this code is active in later rfc-compliant
> MTAs. 
Oh, it's most certainly in use with sendmail that ships with OpenBSD 3.5
and 3.6 (and it's certainly not an OpenBSD-specific extension).
Here's an example I just sent to [email protected]:
Received: from insomnia.benzedrine.cx ([email protected] [])
        by openbsd.cs.colorado.edu (8.13.0/8.13.0) with ESMTP id i8SN7Pou016408   
        (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=FAIL)      
        for <[email protected]>; Tue, 28 Sep 2004 17:07:26 -0600 (MDT)         
Note the "[email protected]" part, that's the result of the ident lookup. If the
lookup fails, sendmail doesn't add that part.
Sniff more carefully, you should see a TCP SYN to port 113 and in most
cases a RST back (when the sending peer doesn't have identd open).
Whether to leave it open or not is probably moot for mail nowadays, but
if you close the port without returning RST (which brings us back to the
topic of this thread, I hope), the receiving MTA will get delayed until
its ident connect(2) times out. Which, I assume, is also the motivation
If you're still not convinced, take a look at
  getauthinfo() calling getservbyname("auth", "tcp");