Subject: RR DNS and spam

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 15:21:54 +0200

Over in the IRTF ASRG group I made a proposal to get rid of all the
spam that comes via abused (proxies etc.) workstations.

My idea was to "mark" hosts in RR DNS zones als being a mailserver by
(e.g.) adding a TXT record like

8.0.30.195.in-addr.arpa		IN	PTR	mail.space.net.
				IN	TXT	"mailto:[email-masked]"

That way the maintainers of the RR zone could authorize IPs to be valid
mailservers and receiving mailservers would only accept mails from
sending IPs that have the RR TXT record.
It would be easily implemented, existing DNSBL code could be used by using
"in-addr.arpa" as a base and inverting the meaning of "there is a TXT
record".
A non existant TXT record in RR DNS could be "overridden" by
- a proper authentification (e.g. SMTP AUTH) so roaming users would bot
  be locked out.
- local configuration that lets smarthosts accept emails from "well
  known" hosts without making that hosts sending mailservers to the public.
The TXT record could carry a contact address (mailto, http) for abuse.

And now my question to this audience :-)
With all the recent discussions about the in-addr.arpa zone and reverse
IPv6 resolution, would such a proposal be accepted by the DNS operators?
Would they be willing to "change mind" and take more care of reverse zones?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 3 Apr 2003 12:47:26 -0500 (EST)

There have been several proposals along this line (notably, DNS
Whitelists). These have tended to fail for the same reasons as blacklists:
Administrative variation, revenge use, and other reasons.

Some people will undoubtably pick it up. Not everyone will. So it won't be
much use.  Further, spammers are authorized to use their ISP's mail
relays. Most spam comes directly. KLEZ virus infections, which are
responsible for increasing amounts of spam, use the infected users mail
relay.

Spam is a problem of authorized, but inappropriate behavior. People keep
trying to find ways to identify spam using an authorization process. All
spammers are authorized users of some ISP.  They remain authorized users
until their ISP cancels their account.  There is no way for outsiders to
obtain control over who is authorized by another ISP. Any such controls
are themselves subject to abuse.

		--Dean

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 20:50:29 +0200

On Thu, Apr 03, 2003 at 12:47:26PM -0500, Dean Anderson wrote:
> Some people will undoubtably pick it up.

That was my question: with all the "we don't want to manage RR zones"
how many will pick it up, which would cause them to do at least some
administration of the RR zones.

> Not everyone will. So it won't be much use.

That depends on how many "not everyone" is. If 80% percent use it
and you can send mail only to 20% of the Internet if you don't use
it, the 20% will change rather fast. It's called group pressure.

> Further, spammers are authorized to use their ISP's mail

Maybe my English is way too bad ... but what is so hard to understand
in the wording "I want to get rid of all those millions of hosts that
nobody (even not the owner) wants to be a publicly acting mailserver,
but which are abused as mailservers because of e.g. bad maintenance
or virus infection or cracking". I don't care about spam from official
ISP smarthosts NOW, neither do I care NOW about spam from hosts having
that TXT record set. These admins will be lart'd later.

I want a way to express "this IP SHOULD act as a mailserver sending to
the public" or "this IP SHOULD NOT act as a mailserver sending to the
public".

Does anyone responsible for

    unknown:61.254.148.198 HELO compuserve.com
    unknown:61.254.148.198 rejected:
	<[email-masked]> to <[email-masked]> badhelohost

want 61.254.148.198 to act as a mailserver sending to the public?
Or how about

    pcp042221pcs.unl.edu:129.93.209.153 rbl-allowed:
	<[email-masked]> to <[email-masked]>
    pcp042221pcs.unl.edu:129.93.209.153 rbl-allowed:
	<[email-masked]> to <[email-masked]>

    dhcp024-209-033-173.neo.rr.com:24.209.33.173 HELO earthling.net
    dhcp024-209-033-173.neo.rr.com:24.209.33.173 rejected:
	<[email-masked]> to <[email-masked]>

    mail.harborside.com:12.45.56.18 rejected:
	<[email-masked]> to <[email-masked]> badrcptto

I don't know. But with a mechanism like a TXT record for
    198.148.254.61.in-addr.arpa.
    153.209.93.129.in-addr.arpa.
    173.33.209.23.in-addr.arpa.
    18.56.45.12.in-addr.arpa.
identifying that host as "is chosen to be a mailserver" we would know.

And I really would like it if spammers have to change and can't abuse
"taken" hosts in the wild any longer and have to use their ISPs
mailserver, because they have to go through a bottle neck and if the
ISP doesn't take approriate actions it's easy to put a cork in the neck
and that's it.

	\Maex

---

From: Dean Anderson <[email-masked]>
Date: Thu, 3 Apr 2003 14:43:27 -0500 (EST)

> it, the 20% will change rather fast. It's called group pressure.

"group pressure" will alter the spammers, too.  The rest of the "group"
gets tired of jumping through stupid hoops that are provably, and
theoretically pointless from the start.

Your assumption is that spam can only come from not-real-mailservers.
This is a false assumption.  Even so, much real mail also comes from such
"not-real-mailservers". SMTP is a client-server protocol, not a
server-server protocol.  Your proposal is just a way to use DNS to make
SMTP server-server.

> or virus infection or cracking".

Your English was fine. The problem is your assumptions about SMTP make
this a useless goal.

> I don't care about spam from official ISP smarthosts NOW, neither do I
> care NOW about spam from hosts having that TXT record set. These admins
> will be lart'd later.

The LART may go the other way.  I'm sure Rob Austein didn't expect to be
LARTed for advocating not putting numeric IP addresses in Recieved:
headers.  Of course, he's tried to deflect the LART by saying there wasn't
anything wrong with IN-ADDR, but that one shouldn't use open relays.
Obviously, history shows he was wrong.  History eventually corrects such
errors.

Most of the anti-spammers trying to use DNS to block spam don't understand
the SMTP protocol and in particular what entities put headers in email
messages. On more than one occasion, seemingly technically experienced
people have failed to understand that the spammer can't modify a header
put in the message after they give it to a mail relay.

> ISP doesn't take approriate actions it's easy to put a cork in the neck

Yes, it would be nice if spammers would just raise their hand and identify
themselves. It would be nicer if spammers would just obey the rules.  Of
course, this is a naive expectation.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Fri, 4 Apr 2003 01:33:10 +0200

At 2:43 PM -0500 2003/04/03, Dean Anderson wrote:

>                          SMTP is a client-server protocol, not a

	This is a demonstrably false statement.  The updated RFCs for 
Internet e-mail explicitly state that SMTP is a server-to-server 
protocol.  If you want client-to-server, this would be the Mail 
Server Protocol (MSP).  Right now, MSP looks a hell of a lot like 
SMTP, but they will diverge in the future.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 4 Apr 2003 03:48:25 +0200

>  SMTP, but they will diverge in the future.

	Sorry, I meant Message Submission Protocol.  My bad.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Apr 2003 16:45:17 +0200

On Thu, Apr 03, 2003 at 03:21:54PM +0200,
 Markus Stumpf <[email-masked]> wrote 

> sending IPs that have the RR TXT record.

I would refuse *any* proposal relying on in-addr.arpa records. Why?
Because in many countries (typically all of Africa, except may be
RSA), even the ISP have no delegation of the in-addr.arpa space.

There are many reasons for that: laziness of the upstream ISP is the
most common. But there is also the technical difficulty of delegating
in-addr.arpa when the typical allocation is much more specific than a
/24. (RFC 2317 is not widely used.)

Look at ANRT (Morocco) for instance: they use 194.204.241.128/26 (the
object is properly registered in the RIPE database), are fed by the
ISP "ONPT" and look at the delegation of the in-addr.arpa...

Or look at the Pasteur Institute in Senegal. The IP addresse is
213.154.75.74 (in RIPEland again), The upstream is Sonatel and look at
the delegation of the in-addr.arpa...

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 04 Apr 2003 10:34:49 -0500

Good point. Important one too.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 15:41:00 -0500 (EST)

What RFC's would that be?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 16:06:44 -0500 (EST)

Ah, you mean RFC 2476. 2476 is a _proposed_ standard. Since it hasn't
moved since 1998, I think it is a _dead_ proposed standard.  It is just
another in a list of gratuitous changes that are shown by experience to be
a waste of time and effort, as their proponents tilt at windmills trying
to invent a protocol which can't be subjected to abuse and will prevent
human behavior.

So, I guess a statement has been demonstrated to be false, but it wasn't
mine.

		--Dean

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 4 Apr 2003 23:23:43 +0200

> to invent a protocol which can't be subjected to abuse and will prevent

Yeah, just like POP (3) which was invented in Oktober 1984 and was
"dead" for 10 years until "suddenly" with the rush of dialin users
it became a desperately needed protocol to access mailboxes.

Or like FSP which's principle was reinvented by P2P.

	\Maex

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 17:02:24 -0500 (EST)

Just like that. POP finally found a use, though.

Historical note, I don't think it was dialin that got POP going, it was
client server computing and PC's that made POP attractive.  I remember
trying to get users with unix workstations to use POP. We had to use a
program called snarfmail. Snarfmail was a pop client that put mail in
/usr/spool/mail, as though it had been received by sendmail, where Unix
mail and mh could pick it up.

		--Dean