> In article ,
> Jonathan de Boyne Pollard wrote:
>
> > KD> some misguided mail servers/admins use reverse lookups as a
> > KD> kind of litmus test for spam (as if spammers couldn't come
> > KD> up with their own reverse records, duh).
> >
> > CM> Right, but spambots don't.
> >
> > Rubbish. Hijacked third-party machines also often have address->name
> > mappings, and for pretty much the same reason: The people whose machines
> > have
> > been hijacked also have deal with the numbskulls who employ these daft
> > "security" mechanisms on their various TCP services.

Of the spam that gets through the main filters here, more than half
originates from IP addresses for which there is no rDNS. That probably
reflects the fact that many of the systems which are (a) infected by
spam trojans and (b) have rDNS, are likely also listed in one of the
dynamic address DNSBLs. Blocking SMTP sessions from IP addresses
lacking rDNS would clearly cut down on spam here; I don't have any
information available to indicate whether it would also result in
a significant number of false-positive rejections.

In comp.protocols.tcp-ip.domains David C. Stone wrote:
>> In article ,
>> Jonathan de Boyne Pollard wrote:
>>
>> > KD> some misguided mail servers/admins use reverse lookups as a
>> > KD> kind of litmus test for spam (as if spammers couldn't come
>> > KD> up with their own reverse records, duh).
>> >
>> > CM> Right, but spambots don't.
>> >
>> > Rubbish. Hijacked third-party machines also often have address->name
>> > mappings, and for pretty much the same reason: The people whose machines
>> > have
>> > been hijacked also have deal with the numbskulls who employ these daft
>> > "security" mechanisms on their various TCP services.

> Of the spam that gets through the main filters here, more than half
> originates from IP addresses for which there is no rDNS. That probably
> reflects the fact that many of the systems which are (a) infected by
> spam trojans and (b) have rDNS, are likely also listed in one of the
> dynamic address DNSBLs. Blocking SMTP sessions from IP addresses
> lacking rDNS would clearly cut down on spam here; I don't have any
> information available to indicate whether it would also result in
> a significant number of false-positive rejections.

All "serious" senders of mail to me and my affiliates has correct dns, forwards
and backwards. The few that don't will call me by phone and have me fix
their dns ( since their mail don't work).

So even if there is no mandatory requirement on correct rdns in practive there is.

And why should one not make life a little easier and avoid mailbounces ?

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

"David C. Stone" wrote in news:200720040905001152%
no.email@example.com:

> Of the spam that gets through the main filters here, more than half
> originates from IP addresses for which there is no rDNS. That probably
> reflects the fact that many of the systems which are (a) infected by
> spam trojans and (b) have rDNS, are likely also listed in one of the
> dynamic address DNSBLs. Blocking SMTP sessions from IP addresses
> lacking rDNS would clearly cut down on spam here; I don't have any
> information available to indicate whether it would also result in
> a significant number of false-positive rejections.

IME, *only* trojanized spam-spewers lack any rDNS whatsoever. Or, more
accurately, the only HELOs I see that contain merely an IP are trojanized
spam-spewers; all of my users HELO with something alphabetic, even if it's
a mere "desktop" hostname (that's a literal, BTW).

Ergo, it appears to me that there is a zero chance of a false positive to
reject on a HELO that consists solely of an IP address.

--
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
. . .
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/

"The Open Sourceror's Apprentice" wrote:
> IME, *only* trojanized spam-spewers lack any rDNS whatsoever. Or, more
> accurately, the only HELOs I see that contain merely an IP are trojanized
> spam-spewers;

HELO is distinct from DNS.


paul

Paul Jarc wrote:
> "The Open Sourceror's Apprentice" wrote:
>> IME, *only* trojanized spam-spewers lack any rDNS whatsoever. Or, more
>> accurately, the only HELOs I see that contain merely an IP are trojanized
>> spam-spewers;
>
> HELO is distinct from DNS.

*sigh*

Jul 19 00:29:21 server sendmail[7921]: NOQUEUE: connect from [193.219.234.170]
Jul 19 00:29:29 server sendmail[7922]: i6J5TNh07922: ruleset=check_rcpt, arg1=, relay=[193.219.234.170], reject=586 5.0.0 Message accepted for delivery
Jul 19 00:29:29 server sendmail[7922]: i6J5TNh07922: from=, size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=[193.219.234.170]

--
DAMN tax cuts! They're letting money trickle down to people who spend it!
WASHINGTON, July 13 (Reuters) - The U.S. government posted a larger-than-
expected budget surplus in June, propped up by higher quarterly business tax
receipts, a government report released on Tuesday showed.

prj@po.cwru.edu (Paul Jarc) wrote in news:m3acxu5p4x.fsf@multivac.cwru.edu:

> "The Open Sourceror's Apprentice" wrote:
>> IME, *only* trojanized spam-spewers lack any rDNS whatsoever. Or, more
>> accurately, the only HELOs I see that contain merely an IP are trojanized
>> spam-spewers;
>
> HELO is distinct from DNS.

Agred; I was attempting (apparently badly) to explain that a HELO that fails
rDNS completely (which is what I am seeing) is functionally identical to a
HELO that is a plain IP (and frequently, those are forged; what the point of
that might be is more than I can tell. Raw IP as a HELO is cause for a local
block anyhow).


--
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
. . .
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/

Barry Margolin wrote:

> IIRC, this really began when the US government prohibited companies like
> Microsoft and Netscape from distributing strong encryption to certain
> foreign countries. So they had to come up with a way to check whether
> people downloading browsers were in the US or not. I don't know if
> their techniques were ever publicized, but it appeared that part of it
> involved a reverse DNS lookup, and then they checked the WHOIS record of
> the domain in the response. If the reverse lookup failed then there was
> no domain to check, so the test failed. I used to have quite a few
> customers who had trouble downloading the domestic versions of Netscape
> and IE until we delegated reverse DNS to them.


Well there is that, but I believe that a fair number of ftp
servers will refuse connections without a reverse, even if they
aren't enforcing any access restrictions.

-- glen

In article <9HpLc.135488$IQ4.34423@attbi_s02>,
glen herrmannsfeldt wrote:

> Barry Margolin wrote:
>
> > IIRC, this really began when the US government prohibited companies like
> > Microsoft and Netscape from distributing strong encryption to certain
> > foreign countries. So they had to come up with a way to check whether
> > people downloading browsers were in the US or not. I don't know if
> > their techniques were ever publicized, but it appeared that part of it
> > involved a reverse DNS lookup, and then they checked the WHOIS record of
> > the domain in the response. If the reverse lookup failed then there was
> > no domain to check, so the test failed. I used to have quite a few
> > customers who had trouble downloading the domestic versions of Netscape
> > and IE until we delegated reverse DNS to them.
>
>
> Well there is that, but I believe that a fair number of ftp
> servers will refuse connections without a reverse, even if they
> aren't enforcing any access restrictions.

I never really understood why they did that. If they allow anonymous
uploads, I suppose it might have been an attempt to reduce warez. But
other than that, what problem is it trying to solve?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

In comp.protocols.tcp-ip.domains Barry Margolin wrote:
> In article <9HpLc.135488$IQ4.34423@attbi_s02>,
> glen herrmannsfeldt wrote:

>> Barry Margolin wrote:
>>
>> > IIRC, this really began when the US government prohibited companies like
>> > Microsoft and Netscape from distributing strong encryption to certain
>> > foreign countries. So they had to come up with a way to check whether
>> > people downloading browsers were in the US or not. I don't know if
>> > their techniques were ever publicized, but it appeared that part of it
>> > involved a reverse DNS lookup, and then they checked the WHOIS record of
>> > the domain in the response. If the reverse lookup failed then there was
>> > no domain to check, so the test failed. I used to have quite a few
>> > customers who had trouble downloading the domestic versions of Netscape
>> > and IE until we delegated reverse DNS to them.
>>
>>
>> Well there is that, but I believe that a fair number of ftp
>> servers will refuse connections without a reverse, even if they
>> aren't enforcing any access restrictions.

> I never really understood why they did that. If they allow anonymous
> uploads, I suppose it might have been an attempt to reduce warez. But
> other than that, what problem is it trying to solve?

Keeping the unwanted out. Simple as that.

While it will only keep some out, if your ftp server is used for a community
where everyone has their rdns in order, then it's a simple way of
sorting out _some_ scumbags.

> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

In article , phn@icke-reklam.ipsec.nu
wrote:

> In comp.protocols.tcp-ip.domains Barry Margolin wrote:
> > In article <9HpLc.135488$IQ4.34423@attbi_s02>,
> > glen herrmannsfeldt wrote:
>
> >> Barry Margolin wrote:
> >>
> >> > IIRC, this really began when the US government prohibited companies like
> >> > Microsoft and Netscape from distributing strong encryption to certain
> >> > foreign countries. So they had to come up with a way to check whether
> >> > people downloading browsers were in the US or not. I don't know if
> >> > their techniques were ever publicized, but it appeared that part of it
> >> > involved a reverse DNS lookup, and then they checked the WHOIS record of
> >> > the domain in the response. If the reverse lookup failed then there was
> >> > no domain to check, so the test failed. I used to have quite a few
> >> > customers who had trouble downloading the domestic versions of Netscape
> >> > and IE until we delegated reverse DNS to them.
> >>
> >>
> >> Well there is that, but I believe that a fair number of ftp
> >> servers will refuse connections without a reverse, even if they
> >> aren't enforcing any access restrictions.
>
> > I never really understood why they did that. If they allow anonymous
> > uploads, I suppose it might have been an attempt to reduce warez. But
> > other than that, what problem is it trying to solve?
>
> Keeping the unwanted out. Simple as that.
>
> While it will only keep some out, if your ftp server is used for a community
> where everyone has their rdns in order, then it's a simple way of
> sorting out _some_ scumbags.

But this practice was pretty widespread a long time ago, when even a
large fraction of the wanted did not have rDNS set up properly.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

In article ,
Barry Margolin wrote:
>In article , phn@icke-reklam.ipsec.nu
>wrote:
>> While it will only keep some out, if your ftp server is used for a community
>> where everyone has their rdns in order, then it's a simple way of
>> sorting out _some_ scumbags.
>
>But this practice was pretty widespread a long time ago, when even a
>large fraction of the wanted did not have rDNS set up properly.

It was a good trick to get people to setup rDNS. I think that the main
advantage of rDNS is that I don't have to get the whois data to get some
idea about the network an addres belongs to.

Just an endless stream of IP addresses is much less convenient then
an endless stream of domain names.

One way to solve that problem is to put the whois data in DNS. As long as
that doesn't happen, refusing service to systems without rDNS (and matching
forward DNS of course) makes live a little bit easier.

Of course, refusing mail from systems without a proper reverse DNS avoids
a large amount of spam (mostly from Asia).



--
The Electronic Monk was a labor-saving device, like a dishwasher or a video
recorder. [...] Video recorders watched tedious television for you, thus saving
you the bother of looking at it yourself; Electronic Monks believed things for
you, [...] -- Douglas Adams in Dirk Gently's Holistic Detective Agency

In comp.protocols.tcp-ip.domains Barry Margolin wrote:
> In article , phn@icke-reklam.ipsec.nu
> wrote:

>> In comp.protocols.tcp-ip.domains Barry Margolin wrote:
>> > In article <9HpLc.135488$IQ4.34423@attbi_s02>,
>> > glen herrmannsfeldt wrote:
>>
>> >> Barry Margolin wrote:
>> >>
>> >> > IIRC, this really began when the US government prohibited companies like
>> >> > Microsoft and Netscape from distributing strong encryption to certain
>> >> > foreign countries. So they had to come up with a way to check whether
>> >> > people downloading browsers were in the US or not. I don't know if
>> >> > their techniques were ever publicized, but it appeared that part of it
>> >> > involved a reverse DNS lookup, and then they checked the WHOIS record of
>> >> > the domain in the response. If the reverse lookup failed then there was
>> >> > no domain to check, so the test failed. I used to have quite a few
>> >> > customers who had trouble downloading the domestic versions of Netscape
>> >> > and IE until we delegated reverse DNS to them.
>> >>
>> >>
>> >> Well there is that, but I believe that a fair number of ftp
>> >> servers will refuse connections without a reverse, even if they
>> >> aren't enforcing any access restrictions.
>>
>> > I never really understood why they did that. If they allow anonymous
>> > uploads, I suppose it might have been an attempt to reduce warez. But
>> > other than that, what problem is it trying to solve?
>>
>> Keeping the unwanted out. Simple as that.
>>
>> While it will only keep some out, if your ftp server is used for a community
>> where everyone has their rdns in order, then it's a simple way of
>> sorting out _some_ scumbags.

> But this practice was pretty widespread a long time ago, when even a
> large fraction of the wanted did not have rDNS set up properly.

All the folks i talked to at that time did know how to set up their dns.
( 1990 and forward a couple of years)

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

philip@pch.home.cs.vu.nl (Philip Homburg) wrote in message news:<7etgab1m36mr4t23ilbta31102@inews_id.stereo.hq.phic oh.net>...
> Of course, refusing mail from systems without a proper reverse DNS avoids
> a large amount of spam (mostly from Asia).

Indeed it does. On our relatively small network the primary mail
server in the last 7 days has rejected 7,881 emails at the SMTP level
because there has been no rDNS, and there have been no complaints at
all (postmaster and abuse skip these checks, so complaining is
possible!)

Lee.
--
www.spam-trap.net

"The Open Sourceror's Apprentice"
wrote in news:Xns952C9F26178AAMorelyDotesspamblock@216.99.2 11.247:

>...
> I was attempting (apparently badly) to explain that a
> HELO that fails rDNS completely (which is what I am seeing)
>...

The difficulty in explaining this is that it makes no sense. rDNS
tests are not applied to HELO arguments, they are applied to the IP
address of the connecting client.

There is no connection between the rDNS test and the HELO/EHLO
command, unless you are talking about comparing the PTR name to the
HELO name. But "fails rDNS completely" implies that there is no PTR
record in the first place, so you can't be meaning that.

- Fred

In article ,
Barry Margolin wrote:
>In article <9HpLc.135488$IQ4.34423@attbi_s02>,
> glen herrmannsfeldt wrote:

>> Well there is that, but I believe that a fair number of ftp
>> servers will refuse connections without a reverse, even if they
>> aren't enforcing any access restrictions.
>
>I never really understood why they did that. If they allow anonymous
>uploads, I suppose it might have been an attempt to reduce warez. But
>other than that, what problem is it trying to solve?

It was once legal to let people download the encryption-enabled
versions of programs only if they were in certain countries. So,
looking at rDNS and parsing the whois record was a reasonable
approximation for the server (enough to keep it from getting busted,
which is presumably what they actually cared about).

Seth

Barry Margolin wrote:

> In article <9HpLc.135488$IQ4.34423@attbi_s02>,
> glen herrmannsfeldt wrote:

(snip regarding reverse lookup verification)

>>Well there is that, but I believe that a fair number of ftp
>>servers will refuse connections without a reverse, even if they
>>aren't enforcing any access restrictions.

> I never really understood why they did that. If they allow anonymous
> uploads, I suppose it might have been an attempt to reduce warez. But
> other than that, what problem is it trying to solve?

When I first started working with nameservers and domains
it was with SunOS 4.x, where one needed a modified shared library
to make it work. The SunOS resolver gethostbyaddr() routine would
always verify the supplied address. If it didn't verify it would,
I believe, write to syslog and not return the unverified result.

If one wants to believe the domain names in a log file, the
addresses should be verified. A year or so ago I had to
complain to attbi.com as my address didn't have a reverse.
(Most did, but some didn't.) Then I had to explain to them
what a reverse DNS entry was and why it was needed.
(They should have known!) After a few weeks they did fix
it, but it shouldn't have taken that long.
(I believe it was ssh that required it.)

-- glen

In article ,
sethb@panix.com (Seth Breidbart) wrote:

> In article ,
> Barry Margolin wrote:
> >In article <9HpLc.135488$IQ4.34423@attbi_s02>,
> > glen herrmannsfeldt wrote:
>
> >> Well there is that, but I believe that a fair number of ftp
> >> servers will refuse connections without a reverse, even if they
> >> aren't enforcing any access restrictions.
> >
> >I never really understood why they did that. If they allow anonymous
> >uploads, I suppose it might have been an attempt to reduce warez. But
> >other than that, what problem is it trying to solve?
>
> It was once legal to let people download the encryption-enabled
> versions of programs only if they were in certain countries. So,
> looking at rDNS and parsing the whois record was a reasonable
> approximation for the server (enough to keep it from getting busted,
> which is presumably what they actually cared about).

I know about that, but I was asking about FTP sites like ftp.uu.net that
flat out *refused* to allow use by anyone that didn't have reverse DNS,
even though they didn't have any content that required special treatment
like this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

In article ,
Barry Margolin wrote:
[...]
> But this practice was pretty widespread a long time ago, when even a
> large fraction of the wanted did not have rDNS set up properly.

It was widespread before most people operating legitimately had a unique
IP address assigned to any device they could touch.

I think that mostly explains it.

A lot of early SLIP and PPP dialup users had no rDNS and coincidentally
also were hard to track because providers largely did not bother. For
some time (early 90's) shunning machines without rDNS correlated
(imperfectly) to shunning dialup users with sloppy ISP's, and machines
with rDNS (particularly rDNS that was simply symmetrical with forward
DNS for the names) tended to be machines that had some hope of an audit
trail.

The PARANOID compile option for TCP wrappers probably helped perpetuate
that sort of heuristic checking.

--
Now where did I hide that website...

Seth Breidbart wrote:

[]

> It was once legal to let people download the encryption-enabled
> versions of programs only if they were in certain countries. So,
> looking at rDNS and parsing the whois record was a reasonable
> approximation for the server (enough to keep it from getting busted,
> which is presumably what they actually cared about).

Which, of course failed miserably if one wanted to download the crypto
stuff from a non-US country through a US-companie's private transat X25
link.

My UK ISP address was refused initially, but hey, it saved me from
typing in the Pretty Good crypto from the dead-tree book ;-)

ftp.uu.net may have been set up in the Innocent Days when it was
/assumed/ that folks would do the right thing - and enter their real
email addresses when login onto anonymous ftp sites...

rgds, Alan
--
99 Ducati 748BP, 95 Ducati 600SS, 81 Guzzi Monza, 74 MV Agusta 350
"Ride to Work, Work to Ride" SI# 7.067 DoD#1930 PGP Key 0xBDED56C5