Subject: [Asrg] 6. Proposals - RMX-like implementation via rDNS

From: [email-masked]
Date: Wed, 10 Sep 2003 02:35:45 -0400

I'm not quite certain whether this should go in "6. Proposals" or
"7. BCP".  It's a proposal that can be implemented by a change in
current practices.  No re-writing of core software is required.  The
idea is to allow MTA's to infer from IP addresses and/or rDNS, whether a
particular IP address is authorized to send email.

Rationale
=========

  Much of today's spam comes direct-to-MX via compromised home machines
on dynamic IP addresses.  The dynamic nature of these IP addresses
reduces the effectiveness of DNSbls of compromised machines.  The next
step is to pre-emptively block email from *ALL* dynamic addresses.  The
problem is that there are so many, that the zones get huge.  For
instance, RoadRunner is reported to have 24 SMTP servers and 15,696 /24
DHCP blocks.  Whitelisting the 24 SMTP servers, and blocking everything
else with an rDNS ending in "rr.com" would be much easier than blocking
15,696 /24 DHCP blocks.  An associated problem is keeping track of ISPs'
residential service address ranges as ISPs expand and get new blocks of
IP addresses.

The proposal
============

  The proposal is that ISPs publish a list of their outbound email
servers and any static IP address ranges that are authorized to send
email direct-to-MX.  All other IP addresses within the ISP's domain
would be assumed to be unauthorized to send email direct-to-MX.  The
publishing could be on a web page.  The addresses could be either
numeric, or rDNS patterns.  A real-life example is AOL.

  - Their dialup IP addresses have rDNS ending with ipt.aol.com
  - AOL attempts (not always successfully) to intercept outbound SMTP
    connections direct-to-remote-MX from its dialups and relay them via
    servers with rly-ipXX.mx.aol.com, where XX is a number from 00 to 99.
  - Email sent from dialups via "official channels" (i.e. AOL's email
    gateways) goes out via servers with rDNS ending imo-rXX.mx.aol.com.

  Thus, rejecting *.ipt.aol.com and rly-ip[0-9][0-9].mx.aol.com is
sufficient to block unauthorized senders using AOL's dialups.  If your
MTA's pattern-matching isn't that flexible, you can hardcode in the
following rDNS or IP addresses...

rly-ip01.mx.aol.com has address 205.188.156.49
rly-ip02.mx.aol.com has address 152.163.225.160
rly-ip03.mx.aol.com has address 64.12.138.7
rly-ip04.mx.aol.com has address 64.12.138.8
rly-ip05.mx.aol.com has address 64.12.138.9
rly-ip06.mx.aol.com has address 205.188.156.51

  That, plus *.ipt.aol.com, gives a grand total of 7 rDNS patterns to
block.  This is much easier to handle than a DNSbl zone of dialups.

  To get an up-to-date list of rly-ipXX.mx.aol.com machines, run the
following script...

#!/bin/bash
i=0
while [ ${i} -lt 10 ]
do
  j=0
  while [ ${j} -lt 10 ]
  do
    host rly-ip${i}${j}.mx.aol.com | grep -v "not found:"
    j=$(( $j + 1 ))
  done
  i=$(( $i + 1 ))
done

Advantages
==========

  1) This proposal does *NOT* require new types of DNS records or other
protocols.  It can be implemented within the existing structure.  AOL
already does this, an example that it can be done.

  2) Lists of authorized sending addresses/rDNS-patterns will generally
be much smaller than lists of residential IP addresses.

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

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

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Wed, 10 Sep 2003 07:32:29 -0400

Hello.  A few toughts:

> problem is that there are so many, that the zones get huge.

I think there is a much stronger reason to avoid trying to block dynamic
addresses:  it causes false positives.  A well implemented UA that injects
mail
via SMTP (with or without the submission subprotocol) is the "correct"
way to do things given that the 'net was designed for end-to-end
communication.

I would say that the proper way to handle dynamic addresses is by behavior
control and not by outright blocking.  Rate limiting comes to mind, as well
as
error counting.

> [...]

Being able to distinguish the "offical" outbound mail clients for a specific
domain is, however, useful in general.  Whether one decides to block or
control incoming connections when they come from another client is an
orthogonal decision.

> already does this, an example that it can be done.

Yes, but unless that list can be published and retreived automatically, and
kept in sync without human intervention, it has very limited usefulness.
This
means that you would need to define:

  a) a standard location where given a domain name 'example.com' you have
      a method and exact location where that list can be found.  E.g.:

      http://example.com/smtp-outbound-servers.xml

      Problem: this only work for domain names which have publically
accessible
      file serving.  Not all domains from which mail could be sent have http
servers,
      or even ftp servers for that matter.

  b) Some way of delegating.  'us.example.com' may well have different
      administrators and mail policies than 'jp.example.com' in addition to
being
      on different continents.

Because of (b), you may find that the easiest way to find that location
might
be to put /it/ in DNS (in a TXT record, say).  This solves most of (a) since
the
TXT record might point to an URL at some hoster or upstream provider that
does serve files.

  c) When you do manage to get your hands on the list, it needs to be in a
      stable, documented and machine parsable format.  A good idea might be
      an XML DTD.

  d) How can the system be broken, exploited?  What happens if 'evil.com'
      points at a dynamic IP on some random ISP?  What happens when the
      file is broken or otherwise unusable?

Indeed, when you think about it that file might contain lots of useful
metainformation about a domain (abuse address, technical contacts, policy)
related to mail or not.  Despite the apparent weaknesses, it might we worth
it
to examine the concept.

-- Marc A. Pelletier

---

From: Brad Knowles <[email-masked]>
Date: Wed, 10 Sep 2003 15:32:44 +0200

>        administrators and mail policies than 'jp.example.com' in addition to

	Indeed.  You can't really co-opt mx.example.com as the subdomain 
to use to specify the outbound mail servers, because many companies 
have subdomains per-country, and ".mx" is a valid ccTLD -- Mexico.

	I realized this a couple of months after we chose mx.aol.com as 
the subdomain to handle all inbound MX records for AOL -- we were 
screwed if we ever got a Mexican service.

	You also can't really co-opt a name like relay.example.net and 
then list all IP addresses of all officially known mail servers, 
because some sites use that as their customer-visible name for their 
outbound mail relays.

	Moreover, some sites will put that IP address on a load-balancing 
switch, although the servers behind the switch will use their real IP 
addresses for their outbound connections (which might be on a 
different interface, and would obviously have to be completely 
different from the customer-advertised address).

	And there remain all the problems with legitimate third-party 
relay activity, which have been previously discussed.

-- 
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: [email-masked]
Date: Wed, 10 Sep 2003 18:57:15 -0400

On Wed, Sep 10, 2003 at 07:32:29AM -0400, Marc A. Pelletier wrote

> > The next step is to pre-emptively block email from *ALL* dynamic
> > addresses.  The problem is that there are so many, that the zones
> > get huge.
> 
> I think there is a much stronger reason to avoid trying to block
> dynamic addresses:  it causes false positives.  A well implemented
> UA that injects mail via SMTP (with or without the submission
> subprotocol) is the "correct" way to do things given that the 'net
> was designed for end-to-end communication.

  "The 'net was designed for..."
  - a clientel consisting of white, male, middle-class military types
    and civilians doing reasearch for the military.  These people needed
    security clearance simply to get on the net, which is why smtp had
    no security designed in.  This clientel would have no incentive to
    spam; doing so would risk their security clearance.
  - administration by BOFH admins who knew what they were doing

  Today, every fourteen-year-old 133t-hax0r-dude can get on.  The vast
majority of residential customers have problems finding the "ANY" key,
and are easy targets for evil people who want to take over their
machines.

> I would say that the proper way to handle dynamic addresses is by
> behavior control and not by outright blocking.

  For whatever reason, some big ISPs can't be bothered.  Ask anybody
who's been mailbombed by a stuck virus on a compromised machine, and the
offender's ISP takes forever to shut them down.

> Rate limiting comes to mind, as well as error counting.

  How does an ISP rate-limit except by routing SMTP transactions through
its own MTAs ?  And it's *NOT* really point-to-point communications when
the machine/person at IP address w.x.y.z can be someone totally
different than who connected to you from the same address five minutes
ago.  What it all comes down to is that the vast majority of emails sent
direct-to-mx from residential/dynamic IP addresses is spam.  If you're
going to accept smtp traffic from another ISP's dynamic IP addresses,
you need some form of authentication.  This can be the POP-before-SMTP
hack, or ssh-tunneling, or SSL, or whatever.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 11 Sep 2003 01:41:37 +0200

>      spam; doing so would risk their security clearance.

	The original ARPAnet was unclassified.  Granted, getting access 
to ARPAnet was extremely difficult, and therefore things like 
inter/intra protocol security were not priorities.  However, this has 
nothing to do with security clearance.

>    - administration by BOFH admins who knew what they were doing

	Indeed, most the the users were the admins.  Everybody was on a 
first-name basis.  You could look at the way the washer-size disk 
drives were moving around and tell what jobs were running.  You could 
listen to the printers and tell what was being printed.  From half a 
building away, you could recognize the dimming of the lights and the 
sound of a crash dump being printed.  Knowing that it would take at 
least thirty minutes to complete, you could be safe in the knowledge 
that you'd have enough time to eat a leisurely lunch before you had 
to be back at the office.

>  and are easy targets for evil people who want to take over their

	Indeed.  But many "cures" being proposed seem no better than the 
disease, and some of them would even seem to be worse.  We have to be 
careful in what we recommend.

>        What it all comes down to is that the vast majority of emails sent

	Some of us don't have effective alternatives for access.  There 
is only one dominant carrier available, and while their service may 
just be sufficient to get our bits onto the 'net, they couldn't find 
their backside if they were stuck into a room with mirrors on all 
sides and the world's most powerful lighting.  We wouldn't route our 
mail through their servers if our lives depended on it.  They are 
Access Providers, no more.

	Indeed, in some countries, the only access available is from 
providers who explicitly refuse to provide anything more than just 
bare access, requiring you to get all your service somewhere else.

		First they came for the communists, and I did not speak out --
			because I was not a communist;
		Then they came for the socialists, and I did not speak out --
			because I was not a socialist;
		Then they came for the trade unionists, and I did not speak out --
			because I was not a trade unionist;
		Then they came for the Jews, and I did not speak out --
			because I was not a Jew;
		Then they came for me --
			and there was no one left to speak out for me.
				Pastor Martin Niemöller

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Sep 2003 19:54:36 -0400

Brad Knowles wrote:
>     The original ARPAnet was unclassified.  Granted, getting access to 
> ARPAnet was extremely difficult, and therefore things like inter/intra 
> protocol security were not priorities.  However, this has nothing to do 
> with security clearance.
> 

Please see the draft written by the IAB on this 
(http://www.iab.org/documents/drafts/draft-iab-e2e-futures-03.txt):

----snip--------
"3.1 Lack of Trust

Perhaps the single most important change from the Internet of 15 years 
go is the lack of trust between end nodes. Because the end users in the 
Internet of  15 years ago were few, and were largely dedicated to using 
the Internet as a  tool for academic research and communicating research 
results (explict commercial use of the Internet was forbidden when it 
was run by the US government), trust between end users (and thus between 
the end nodes that they use) and between network operators and their 
users was simply not an issue in general. Today, the motivations of some 
individuals using the Internet are not always entirely ethical, and, 
even if they are, the assumption that end nodes will always co-operate 
to achieve some mutually beneficial action, as implied by the end to end 
principle, is not always accurate. In addition, the growth in users who 
are either not technologically sophisticated enough or simply 
uninterested in maintaining their own security has required network 
operators  to become more proactive in deploying measures to prevent 
naive or uninterested users from inadvertently or intentionally 
generating security problems.
----snip--------

It is sufficient for our purposed to know that the Internet is insecure 
today as per above draft. The reasons for that do not matter unless they 
have direct relevance to our work.

>     Some of us don't have effective alternatives for access.  There is 
> only one dominant carrier available, and while their service may just be 
> sufficient to get our bits onto the 'net, they couldn't find their 
> backside if they were stuck into a room with mirrors on all sides and 
> the world's most powerful lighting.  We wouldn't route our mail through 
> their servers if our lives depended on it.  They are Access Providers, 
> no more.
> 
> providers who explicitly refuse to provide anything more than just bare 
> access, requiring you to get all your service somewhere else.
> 

I can definatly relate to that - my own provider is providing a 
bare-bones SMTP server which has been an open-relay at one point and is 
still blacklisted in some places.

Please keep in mind the technical considerations and requirements 
documents, especially the sections regarding not placing a large burden 
on users and backwards compatability. These are issues with all 
proposals, the question is whether the benefits outweigh the 
disadvantages. This is something that needs to be evaluate objectively 
for every proposal without going off-topic.

Yakov

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 11 Sep 2003 10:53:18 -0400

> bare access, requiring you to get all your service somewhere else.

  Which looks a whole lot like the 'roaming user' previously discussed
on this list.  For that reason, I'm inclined to believe that most
consent frameworks which work in the first situation will also work in
the second.

  Alan DeKok.

---

From: Raymond S Brand <[email-masked]>
Date: Thu, 11 Sep 2003 12:36:59 -0400

Have a (or another) look at DRIP; it achieves most of what you're looking
for.

	http://www.ietf.org/internet-drafts/draft-brand-drip-01.txt

Raymond S Brand

---

From: david nicol <[email-masked]>
Date: 15 Sep 2003 01:11:51 -0500

> The proposal

Does anyone argue with this?  The only problem is selecting
a standard for publishing the information.  I suggested one
last may (and june) in a message archived here:

http://msgs.securepoint.com/cgi-bin/get/djbdns-0306/9.html

and I suppose I'll keep posting links to it until I see something
equivalent in the form of an I-D, and then I'll link to that.

Okay, DRIP
http://www.ietf.org/internet-drafts/draft-brand-drip-01.txt
is very similar; however instead of 

         192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

         192_0_2_11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11

         127_0_0_1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1

OMX would have example.com list

	omx.m.example.com IN A 192.0.2.10
	omx.m.example.com IN A 192.0.2.11
	omx.m.example.com IN A 127.0.0.1

up to the first seven relays, if there are seven of
them then we put the next seven in omx1... and then
omx2... until there aren't any more.

This means, less DNS traffic.  It is harder to get wrong than
DRIP, which appears to insist that the address gets repeated
in the name and the response.

As for what it is reccommended that the MTA do with the listedness/notlistedness
of the peer, I guess that isn't beyond the scope of the to-be-written
OMX I-D, since it is included in the DRIP draft.

> Advantages

Amen.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 15 Sep 2003 11:54:44 -0400

> is very similar; however instead of 
..
> 	omx.m.example.com IN A 192.0.2.11

  Which is overkill.  The recipients of a message want to know if a
particular IP is marked as "sending MX".  Forcing the recipient to
wade through tons of unwanted information is inefficient.

  This was my preference:

 http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-02.txt

  It appears to have expired, though.

  "designated senders" are looked up by reverse IP, which is simple to
configure in DNS, and allows simple wildcarding for the "third-party
relaying" issue.  Further, the response can be a TXT record, with
additional consent information.

  The other benefit is that when the recipient MTA asks "is this IP
permitted to send messages as your domain?", then the response is
"yes", or "no", or "unknown".  This response is much more helpful than
most similar proposals, which involve responding with huge amounts of
information.

  Alan DeKok.