[lug] DNS error. Kinda vague.

[John Starkey]

> > Is there really any need for this?? Why would login need to get involved
> > with sendmail??
> 
> They don't have anything to do with each other, per se, but rather,
> tcpwrappers is doing a reverse lookup on the originating IP. If hosts.deny
> has ALL:PARANOID in it, any IP that doesn't match forward and reverse is
> denied.
> 
> Sendmail also does a similar sort of lookup and will put a warning in the
> headers if the reverse dns doesn't match what the originating server
> claims it is.

I just checked the tty it's spitting this information out too (I set up
tail >> tty8). Looks like it's exactly what you're saying (or seems that
way to me). A new error is popping up that looks like it's related.

It's on the 2's, every ten minutes (ie 12:02, 12:12, etc.) so It's
probably gonna be easy to track down if I can figure out how to read/view
the crontabs. Someone here tried to explain this to me a couple weeks ago;
how the wildcards work.

*/2 * * * * /usr/bin/sendmail

The above is what I can remember of an entry I added yesterday while
trying to force sendmail to open via inetd instead of rc.d/init.d. I did
this after my first email on this topic and I think the error message has
changed due to my change.

It reads:

inetd[]: auth/tcp: bind: address already in use
inetd[]: smtp/tcp: bind: address already in use

I'm not sure if this is directly related but I have PTR RR's that
duplicate like:

1	PTR	mail.machine.com
1	PTR	www.machine.com

When you said "originating address" I would think you meant the sender's
address is being checked. It seems logical that the PTR records are fine
since I'm able to virtuallize my server and need many addresses for the
same machine anyway. These addys also match the CNAMEs. Maybe there's
another way to approach this issue in the reverse zones that I don't
know about and it's causing this error??

Thanks,

John