Subject: RE: [Asrg] 6. Proposals - RMX I Never send mail

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 25 Sep 2003 08:13:32 -0700

All,

	There seems to be an issue with current blacklist implementations.
The DNS server approach works fine functionally but the blacklist server
becomes a target for a DoS attack. While it is possible to run DNS
configurations hardened against DNS attack this costs a collosal amount. The
cost of the necessary bandwidth, hardware, support of doing it right is
huge.

	I would like to suggest therefore that we look for ways that we can
distribute certain information that is currently distributed via DNS
blacklists in a more distributed fashion. This will not be possible for all
information of course but is possible for certain subsets.

	In particular dial up modem pools, residential broadband links,
services that never send mail can be blacklisted through the rDNS. This has
a second advantage, the responsibility for maintenance is brought back to
the owner of the IP address. This would address current problems with large
IP address blocks being contaminated by prior spammer hijacking, listing by
an ISP etc.

	For example 18.2.1.xx might have a DNS record of one of the
following forms

		TXT		<ASRG><TYPE>DIALUP</TYPE></ASRG>
		POLICY	DIALUP

	Where POLICY would be a new record written for the purpose (usual
caveats apply). The usual caveats about using the DNS would also apply, risk
of spoofing etc. However I think that if those are really an issue we just
go fix DNS.

	I would see the following as useful identifiers:

		SERVER		A full service IP address
		DIALUP		The address is allocated to a dialup modem
pool
		RESIDENTIAL		The address is allocated to
residential broadband
		BLOCKED		The address is blocked, you should never
connect
		UNALLOCATED		The address has not been allocated

	It might be useful to make this a bit more complex so as to allow
specific protocols to be identified, but I think that is best done through
the forward DNS.

	This might be interpreted as breaking the end to end religion, but
people are already doing that of their own accord. I would rather have ISPs
open port 25 outgoing and label the connection honestly as residential than
have then block the port entirely to stop attacks from anti-spam vigilantes.

		Phill

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Raymond S Brand <[email-masked]>
Date: Thu, 25 Sep 2003 12:51:23 -0400

Although I agree with the motivation and sentiments expressed in this idea,
it suffers from the same set problems that _ALL_ of the TXT RR ideas suffer
from:

1) Large responses to the query. Potentially very large when you include
	some other TXT RRs people have suggested.
2) Multiple responses to search through to find the specifically formatted
	TXT RR the application is looking for.
3) Parsing the formatted TXT RR to find the data that the application is
	interested in.

If instead you use the name from the the rDNS query result to do an A RR
query of the following (DRIPish) form:

	addrtype._email_.${PTR_VALUE}

This way you get 24 bits to assign meaning to (if results must be part of
127.0.0.0/8). The query response will be small. Multiple A RRs in the
response mean the test failed. No parsing needed.

You should also do an A RR query on ${PTR_VALUE} to verify that the PTR RR
record isn't bogus.

Raymond S Brand

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 25 Sep 2003 13:08:44 -0400

Hallam-Baker, Phillip wrote:

[Omitted having ISPs putting policy tags in their rDNS TXT entries]

> have then block the port entirely to stop attacks from anti-spam vigilantes.

Problem is that this solves _none_ of the things you want it to.

1) What's to prevent the DDOS attackers from DDOS'ing the DNS servers 
serving up the ranges they're spamming from?  I sense yet another 
business opportunity for the DDOSers - "pay us to blow the brains out of 
your ISP's DNS servers!"

2) This treats only one current aspect of the spamming issue.  We don't 
want to block residential IPs per se, we want to block spam[+].  Might 
as well have ISPs TXT-label their appropriate blocks as "SPAM SOURCES".

3) How are you going to get the ISPs to provide "OPEN PROXY" TXTs?  Have 
them scan their own IP ranges?  If they're doing that, they should shut 
'em _off_ instead [+]

4) How does "labeling" a block as residential (or even dynamic) "stop 
attacks from anti-spam vigilantes"?  If I know enough to attack an ISP 
for spams from "residential and/or dynamic", I'm _already_ blocking the 
damn things, and I'm complaining about the insistent and repeat spam 
attacks continuing to chew up our resources.  While it may seem 
otherwise, most spam blocking mechanism "block first" and _only_ and 
don't bother complaining.

[+] "residential blocking" only solves a small part of the _existing_ 
spam problem.  Indeed, the traditional DHCP DNSBLs only block around 3% 
of _all_ spam.  Easynet's "residential blocking" (DYNABLOCK) only gets 
it up to 10%, with a MUCH higher level of FPs.  In constrast, some of 
the well-targetted single-IP DNSBLs (CBL, the defunct UPL, SORBS 
proxy/http etc) are achieving success rates nearing and some cases 
greatly exceeding 50%, with much lower FPs.  There's no way in heck that 
ISPs can replace that functionality.  Even if they wanted to.

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 25 Sep 2003 23:22:38 +0200

> business opportunity for the DDOSers - "pay us to blow the brains out of 

What do they gain?
If the defaults are correctly adjusted, none of the emails will go
through, because no answer = don't accept.

> them scan their own IP ranges?  If they're doing that, they should shut 

I am currently writing a draft. I hope to finish it up next week.

The idea is to to have TXT records in revDNS that say
    MTA=yes  or  MTA=no
that way the admin of the in-addr.arpa block has a way to tell others
whether this IP is intended to be a MTA or not. This not only helps
reduce spam but also viri that come with their own SMTP module and
spit their garbage out.

IMHO one big problem whith spam and viri currently is the anarchistic (sp?)
nature of the Internet.
In priciple everyone can put a sending "MTA" on every IP address and
contact any receiving MTA. The receiving MTA has no real chance to
identify whether the sending partner is the postman or a bad guy.

History shows that you can't depend on the "admins" of the computers
to keep up with security patches, antigenes for viri or even reading a
manual. So if they fail the complicated task to secure the computer,
give them an easy way to tell the world "regardless what this host does,
I don't want it to send emails across the Internet".

	\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"

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 25 Sep 2003 23:24:49 +0200

> 3) Parsing the formatted TXT RR to find the data that the application is

This all isn't rocket science ;-)
See
    Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
    String Attributes", RFC 1464, May 1993.

	\Maex

---

From: Raymond S Brand <[email-masked]>
Date: Thu, 25 Sep 2003 19:09:11 -0400

Please DO NOT cc with the message is also sent to the list.

I have. I my concerns remain.

Raymond S Brand

---

From: [email-masked]
Date: Thu, 25 Sep 2003 19:51:19 -0400

On Thu, Sep 25, 2003 at 08:13:32AM -0700, Hallam-Baker, Phillip wrote

> specific protocols to be identified, but I think that is best done through

  Wouldn't it be simpler all around for plain, simple, rDNS to return
xx.1.2.18.residential.bad.example.com ?  Parse the rDNS name rather than
a TXT record.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 25 Sep 2003 19:58:00 -0400

> I am currently writing a draft. I hope to finish it up next week.

Let me know if you want to submit it as an Internet draft through the
group. Otherwise, let us know once it is submitted so we can link to it
from the ASRG site.

On a related note, I have tried sending email to you off-list and it 
bounced because of anti-spam blocking. Please contact me off-list to 
resolve this.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 02:04:40 +0200

> xx.1.2.18.residential.bad.example.com ?  Parse the rDNS name rather than

Yes! And I always wished they would adopt RFC2317 style naming for their
otherwise informationbare naming scheme. As their WHOIS services are
broken most of the time or referrals don't work this would help enormously
when setting up blocks in DNSBLs ;-))

Instead of
   10-0-0-14.dyn.example.com [10.0.0.14]
it would help if it looked like
   14.0/27.0.10.dyn.example.com
or even
   14-0/27-0-10.dyn.example.com

	\Maex

---

From: Brad Knowles <[email-masked]>
Date: Fri, 26 Sep 2003 03:14:20 +0200

>     14-0/27-0-10.dyn.example.com

	You can't use slashes in domain names.

-- 
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(+++)

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 03:59:12 +0200

> 	You can't use slashes in domain names.

RFC 2317 Classless IN-ADDR.ARPA delegation
4. Classless IN-ADDR.ARPA delegation
   [ ... ]
   Some DNS implementations are not kind to special characters in domain
   names, e.g. the "/" used in the above examples.  As [3] makes clear,
   these are legal, though some might feel unsightly.  Because these are
   not host names the restriction of [2] does not apply. Modern clients
   and servers have an option to act in the liberal and correct fashion.
   [ ... ]

   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
        Table Specification", RFC 952, October 1985.
   [3]  Elz, R., and R. Bush, "Clarifications to the DNS Specification",
	RFC 2181, July 1997.

But thinking about it a bit more I wondered if the above statement also
applies to the RHS of a PTR RR and I think you are completely right.
So let's change the
    14.0/27.0.10.dyn.example.com
to
    14.0-27.0.10.dyn.example.com

;-)
	\Maex

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 26 Sep 2003 13:35:45 -0400

> through, because no answer = don't accept.

Anything that defaults to "email blocked if DNS doesn't give me an 
answer" is, um, way too dangerous.

Ie: You could kill my inbound and outbound mail altogether by DDOS'ing 
_my_ DNS servers.  Ouch.

Even in the impossible event that _everyone_ complied with such a 
standard, having your email abruptly stop working altogether if your DNS 
fails is not something I want to propose to the PTBs.

Thus, it would have to default to "let it through", and DDOS'ing the 
ISP's (or recipient's) DNS servers will be too attractive an idea to 
pass up.

We either have to come up with a proposal to make the feature 
DDOS-proof, _or_, find some way to stop DDOS's in general (technically 
or bomb-from-orbit).  I think stopping DDOS's is a vastly preferable 
approach than bandaiding individual protocols.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 20:54:07 +0200

> answer" is, um, way too dangerous.

It depends.
If you mean "blocked = permanently rejected" I agree.
If you mean by "blocked = temp failure" I don't. If you f'cked up your
(caching) DNS you won't get eMails out. If you f'cked up your (auth) DNS
you have to solely depend on cached MXs at other caches.

> Ie: You could kill my inbound and outbound mail altogether by DDOS'ing 

Yeah ... guess what, I could also kill all your inbound and outbound mail
altogether by DDoS'ing you mailservers, and this is by far easier ;-)

> fails is not something I want to propose to the PTBs.

If your DNS fails you have a lot of other things that don't work either.
Inbound and outbound.
In the scenario you describe (i.e. DDoS all DNS servers) I'd prefer
to reject all incoming messages with a temp failure over accepting
500,000 messages because the DDoS was deliberate to get the spam
through. But if they don't get the spam through, why should they DDoS you?

And as you're supposed to
a) split AUTH and CACHE DNS
b) have AUTH DNS separated to different network branches to make them
   failsafe to network failures
c) the spammers surely don't know which CACHE DNS servers your MTAs use
I don't think this will be too successful an attack.

	\Maex

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 21:26:59 +0200

On Fri, Sep 26, 2003 at 12:07:13PM -0700, Dennis Gearon wrote:
> this RMX scheme, it guarantees  only that the server sending and email 
> can use the name for the server in the FROM field, correct?

Kinda. Only hosts listed with RMX for a domain can send eMails with
Envelope-Sender addresses of that domain.

> It doesn't 
> guarentee that the username is correct, right? And it is open to relays 
> being taken over, right?

Correct in both.
And it breaks forwarding, and I don't like the artificial routing
information they want to put into the addresses to "fix" it. Even if
they use e.g. '#' instead of '%' it will bring all the problems that we
had with the '%' address paths.

But IMHO we need something started rather fast.
I am writing up a draft (which I'll try to finish in a first version
over the weekend).
It has for one a much weaker authetication scheme that all the other
"RMX" like proposals use, but it doesn't need changes to bexisting
Internet techniques and it doesn't break anything existing.

What I propose is to label hosts like
   o  "This IP address is assigned to a MTA that is intended to send
      messages across the Internet"
   o  "This IP address does not host a MTA, do not accept emails from
      that IP address."
We cannot depend/trust on all the millions of so called admins out there
to have control over the software on their computer and keep up with
security holes. So why don't we give them an *easy* instrument that
is independant of their software.
If they (or their ISP) can add records like (BIND notation)

    1.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=yes"
			    IN  TXT  "ASRG.CONTACT=mailto:[email-masked]"
    2.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=yes"
    *.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=no"

nobody has to care about whether the workstation with IP address
10.0.0.13 is infected by a virus or has an open proxy server. It is
labelled ASRG.MTA=no and no MTA will accept messages from that host
unless the sender has a stronger auth mechanism to override this label.

With this proposal we don't need new records defined in DNS, we don't
need some 10 DNS queries to find out whether a given connection is
allowed to send email with a sender address in domain  example.com  and
we don't have to care about 512 byte DNS packet limitations.

It is a weaker proposal as the other RMX like mechanisms, because it
does not try to match domains to valid MTAs for that domain. But it is
cheap in use and implementation, it is easy implemented, we don't need
new DNS records.

A "MTAmapd" can run in front of a standard MTA. The MTAmapd accepts
the connection, looks up TXT records for the IP address of the sender
and if it has MTA=no it sets and ENV variable for the "real" MTA.
The "real" MTA can clear this ENV variable if the connector can
authenticate via a stronger auth scheme (e.g. SMTP AUTH). If the
receiving MTA sees a RCPT TO and the ENV var is still set it will
reject the command with a
   550-5.7.1 Message rejected. Sender is not labelled a valid MTA.
   550 5.7.1 Please contact <[email-masked]>.
and the contact address could be taken from the ASRG.CONTACT record
and be supplied as content of the ENV var.

This is easy, fast, cheap and effective ;-)

	\Maex

---

From: Steven F Siirila <[email-masked]>
Date: Fri, 26 Sep 2003 14:51:34 -0500

> had with the '%' address paths.

I agree with Markus.

>    o  "This IP address does not host a MTA, do not accept emails from

This is exactly what we've been wanting for some time now.  In some ways,
we are doing it today.  For example, we whitelist based on some criteria
which gives us a high certainty that the connection is from a real MTA.
And we blacklist dynamic IP addresses and the like which gives us a high
certainty that the connection is from an IP address which does not host an
MTA.  What we need now is to formalize this and distribute the information
in some manner (e.g. DNS).  Allowing IP block owners to set up these
attributes is a key difference from what we have today (DNSbls) which is
pretty centralized and more error-prone.

>     *.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=no"

I agree that we need to use an existing DNS RR to provide this information,
but I also believe that we should define a new RR to be used in preference
to this method for the long-term.  Perhaps an "MTA" RR.  TXT records are too
general-purpose to be used long-term, IMO.

> cheap in use and implementation, it is easy implemented, we don't need

This "weakness" is actually something that will allow more sites (such as
our own) to adopt it.  We could NEVER adopt RMX due to its tying the
originator domain name with the connecting IP address.  That won't fly here.

> This is easy, fast, cheap and effective ;-)

There are a number of ways that this could be implemented; given the
amount of open-source software out there, a patch could easily be made.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 22:32:15 +0200

> pretty centralized and more error-prone.

Although the bad guys will set "MTA=yes" for their hosts (which is in
some way correct behaviour ;-) we have moved them tighter to the corner
and DNSBLs can more easily deal with them. They don't any longer have to
take care of the whole IP address range (which is even worse with IPv6)
but only with a small dark place in the corner.

> general-purpose to be used long-term, IMO.

IMHO the problem with a new RR (and that's why I tried to avoid it) is
that DNS software of all kinds has to be adopted. DNS server, DNS
resolvers and (IMHO the stronges argument against) ISP management
software. (Large) ISPs don't edit zone files with an editor. They have a
database and a GUI of some sort that is capable handling all sorts of
"well known" RRs.
I had quick and easy adoption mind and if all ISP management software
has to be changed to make use of the new RR it will either take a long
time or will never happen. TXT records are well understood and there is

;-))

> amount of open-source software out there, a patch could easily be made.

Surely ... and not really an issue.

	\Maex

---

From: Steven F Siirila <[email-masked]>
Date: Fri, 26 Sep 2003 16:19:41 -0500

> but only with a small dark place in the corner.

Go ahead and let the "bad guys" do this.  Direct spammers are the easiest
ones to deal with today.  The difficult ones are the ones that hop around.

Speaking of IPv6, does anyone know if there are any MTAs out there using
SMTP over IPv6 yet?  We plan to be very restrictive at the time we roll
this out.  For example, rDNS would be required across-the-board.  Perhaps
"MTA=yes" could also be required if it were in sufficient use by then, too.

>    String Attributes", RFC 1464, May 1993.

I understand the difficulty in adding new RR's.  However, that shouldn't
stop us from getting such a record put into the "long pipeline" so that
it would eventually become just another "weel-known" RR someday.  I was
not aware of RFC 1464; thanks for the reference.