At 4:53 PM -0400 10/11/01, Stefan Jeglinski imposed structure on a
stream of electrons, yielding:
>header:
>
>>Received: from opt20.edirectnetwork.net ([198.139.238.246] verified)
>
>Using the same resolver as the SIMS box is pointed to, I see:
>
><nslookup:opt20.edirectnetwork.net/A>
>Non-authoritative answer:
>opt20.edirectnetwork.net A 198.139.238.246
>
><nslookup:246.238.139.198.in-addr.arpa/*>
>Non-authoritative answer:
>246.238.139.198.in-addr.arpa PTR u-198-139-238-246.classichosting.net
>
><nslookup:u-198-139-238-246.classichosting.net/A>
>Authoritative answer:
> Name Error - domain name referenced does not exist.
>
>I'm not concerned about the A and PTR not matching up or the A
>record not existing - these are pretty standard fare - but how does
>SIMS figure certain things out?
>
>I assume it starts with the HELO and looks up that domain name. If
>the HELO is "correct" and all is copasetic, it is "verified" and
>we're done.
Yup.
>If the HELO is not "real," SIMS still has an IP with which to do a
>reverse lookup. Does it do this reverse lookup and try to resolve
>the matter further, or does it always just stop there and place the
>IP and HELO in the header?
SIMS never bothers with a reverse lookup. There's little to no point
to that, since the owner of an IP address can, if he controls reverse
resolution, make it say anything he likes without limits. This
effectively means that anyone with a /24 ('Class C') block or more
can make their reverse resolution do whatever they like, so it yields
no really useful information to do a reverse lookup.
--
Bill Cole
[EMAIL PROTECTED]
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
