Subject: [Asrg] Proposal: NO_XMIT DNS record

From: Walter Dnes <[email-masked]>
Date: Sun, 13 Jul 2003 01:15:46 -0400

I've seen various proposals for RMX and variants.  There are two major
problems...

  1) If a domain can specify which machines can send for it, spammers
simply point their domains' records to trojaned machines, *JUST LIKE
THEY'RE DOING FOR WEBSERVERS AND DNS RIGHT NOW*.  And I'd have to keep
up to date on MTA names for 3 ISPs (IStop plus a couple of backups).  So
there are no major security benefits, but there is additional paperwork
for me.

  2) If a domain can specify which machines it can send for, you're back
to the fiasco at (I thik it was) Bell Atlantic, where for a time, you
could only send out email "From:" your own account, not from a valid 3rd
party or personal domain you were authorized to use.

  Let's get back to basics to see why RMX has been proposed.  Trojaned
machines have been used to originate spam.  The RMX proposal seeks to
set up lists of which machines can tramsit for which domains.  This
misses the point of the problem.  It's not the authorized MTAs we have
problems with, it's the trojaned home machines, that have no business
whatsoever connecting to port 25 (except to their own ISP) on behalf of
*ANY* domain whatsoever.

  So much for criticism; what do I propose as an improvement ?

  My proposal is for a NO_XMIT record in DNS.  It effectively stands the
RMX proposal on its head.  It would signify IP addresses that have no
business connecting to external MTAs.  This would be very similar in
function to MAPS DUL(TM) and other lists of dynamic IP addresses.  Here
is a sample implementation for discussion...

  1) IP address 10.1.2.3, which is not one of your customers, connects
     to your MTA wanting to send you mail.  "customers" includes those
     authorized to ssh/vnc/vpn/etc to your system.

  2) Your MTA queries someting like "host -t NO_XMIT 10.1.2.3"

  3) If the query returns 127.0.0.2, your MTA may choose to reject the
     email.  This depends on ISPs wildcarding their dynamic IP address
     ranges to return 127.0.0.2.

Notes...
  1) Since absence of a DNS record implies accepting the email, NO_XMIT
     will "fail safely" during DNS outages; i.e. all email (including
     spam) will be authorized, rather than no mail

  2) Since absence of a DNS record implies accepting the email, NO_XMIT
     is backwards-compatable to systems which haven't implemented it.
     If NO_XMIT is widely accepted, non-adopters may be seen as bad
     internet neighbours, and be blocked locally, but that's another
     thing altogether.

  3) This proposal depends on ISPs wildcarding their dynamic IP address
     ranges to return 127.0.0.2.  However, it will have much less
     logistical hassle than trying to maintain *UP-TO-DATE* lists of who
     can send for whom from which IP addresses.

  4) I'd prefer to use strictly the 127.0.0.2 return value for rejection.
     This would allow for future extensions, e.g. 127.0.0.3 might mean
     that an RMX record exists, and you can further query it if you wish.

  5) Given that IPV6 will get here eventually, it's probably a good idea
     to develope an IPV6 version at the same time as IPV4.

-- 
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: Daniel Feenberg <[email-masked]>
Date: Sun, 13 Jul 2003 07:48:42 -0400 (EDT)

> is a sample implementation for discussion...
This is a proposal really worth discussing. I have some questions below,
but don't think they are intended as complaints. This is the best proposal
we have seen.

First, given the nature of existing DNS clients and servers, which
need to be updated to support a new record type? Just the authoritative
server? Or all the servers and the client too? If the latter, isn't there
a strong argument for overloading an existing record, such as MX, SRV, or
TXT? Is it possible to specify a transition period during which an
existing record is overloading, and a new record is established?

I like the fact that it is based on "consent of the sending ISP", which
is an important form of consent that hasn't had enough emphasis. As a
result, sending ISPs have few ready-made tools to suppress outbound spam. 

This is a refinement of three existing practices - 

(1) some receiving MTAs reject mail from hosts with the strings "dial-up"
or "dhcp" in their hostnames. Is that effective? Does it affect the way
ISPs name their systems? If systems avoid those names for this very
reason, then NO_XMIT will not attract them. Does Spamassain look at the
hostname? How many points for those strings?

(2) Some systems block outbound port 25 from dial-up lines at the router.
This seems very attractive as a policy, why would an autonomous system
support NO_XMIT rather than just blocking the port? If the intent is to
reduce abuse complaints, wouldn't that be more effective? Is the downside
router workload, or do some ISPs want to support direct to MX mail?

(3) You mentioned the MAPS DUL. Do systems voluntarily send their IP
address ranges to MAPS, or does MAPS generally figure it out for
themselves? If the latter, do we have any idea why they don't cooperate?
Does that indicate they won't cooperate with NO_XMIT? Will the existence
of a formal standard affect many of them?

Daniel Feenberg

---

From: Florian Weimer <[email-masked]>
Date: Sun, 13 Jul 2003 14:09:32 +0200

Walter Dnes <[email-masked]> writes:

> business connecting to external MTAs.

Why not filter 25/TCP instead?

There isn't much difference between these approaches (and I find both
of them questionable).

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 13 Jul 2003 08:19:45 -0400 (EDT)

> is a sample implementation for discussion...

Some questions for discussion (I really like this proposal):

Given the nature of DNS, does the whole chain of clients and servers
need to be modified to support NO_XMIT, or just the servers? If everything
has to be updated, isn't that an argument for overloading and existing
record (such as MX, TXT, or SRV), at least during a transition period?

From the point of view of the sending ISP or autonomous system, what is
the advantage of supporting NO_XMIT, as compared to blocking outbound port
25 at the network edge? Is the problem router load, or philisophical?
Wouldn't that be both easier and more effective? Would the existence of a
formal standard for NO_XMIT make it more acceptable than blocking port 25?

Daniel Feenberg

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 13 Jul 2003 09:04:28 -0400

>   I've seen various proposals for RMX and variants.  There are two major

  There are more problems with RMX-style solutions than the two you
posted.  For RMX, the single largest problem is the requirement of a
new record type, which your proposal shares.

> business connecting to external MTAs.

  This is semantically identical to the DUL blacklists, but
implemented differently.  It shares the DUL problem, in that
administrators have to sign up to an "opt-out" list for it to work.
Experience has showed that opt-out lists are problematic.  In
addition, there are ~2^32 possible machines which are not dedicated
MTA's, and ~2^18 or so long-lived MTA's.  (See previous stats posted
to the list)

  So an "opt-in" list of "yes, I'm really an honest ISP" would be
smaller, and probably more effective.

>   2) Your MTA queries someting like "host -t NO_XMIT 10.1.2.3"

  Implicit in that statement is a global manager for the list, similar
to the existing reverse map.

  i.e. You're looking up IP's, not domains.  So this proposal *cannot*
be implemented by updating DNS for a domain, there *must* be a global
registry.

>      can send for whom from which IP addresses.

  Is it really that difficult to update a reverse record, at the same
time as you update an MX record?

>      that an RMX record exists, and you can further query it if you wish.

  TXT records?

  Alan DeKok.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 13 Jul 2003 11:42:38 -0400

>Why not filter 25/TCP instead?

Because that prevents users from connecting to an SMTP server as an 
authorized client.

However that does raise a variation on the use of the field. 
Presumably if you have roving users, you would only fail connections 
from NO_XMIT IP addresses when they failed to authorized, rather than 
simply at connection time.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 13 Jul 2003 11:55:47 -0400 (EDT)

> Because that prevents users from connecting to an SMTP server as an 

These should be done on the submit port (587). See RFC 2476. 

Since there is no point in trying to send spam to port 587 (it requires
authorization) only port 25 need be blocked. It is the only port for
mail coming from complete strangers.

k

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 13 Jul 2003 20:46:28 -0400

At 01:15 AM 7/13/2003 -0400, Walter Dnes wrote:
>....
>...

This brings to mind a general issue, should IPv6 support be part of the 
requirements?

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 13 Jul 2003 20:54:49 -0400

At 01:15 AM 7/13/2003 -0400, Walter Dnes wrote:

>.....
>function to MAPS DUL(TM) and other lists of dynamic IP addresses.
>......

Where in the DNS system would this data be stored?

---

From: "C. Wegrzyn" <[email-masked]>
Date: Sun, 13 Jul 2003 21:14:19 -0400

I think we should include it but not as an exclusive requirement unless 
there is no other solution.

Chuck Wegrzyn

Yakov Shafranovich wrote:

> This brings to mind a general issue, should IPv6 support be part of 
> the requirements?
>

---

From: Andrew Akehurst <[email-masked]>
Date: Mon, 14 Jul 2003 16:32:27 +0100 (BST)

> there is no other solution.

Why not just use the generic term "IP address" in any discussions and leave it 
to implementation detail?

If a proposed anti-spam scheme specifically relies upon some feature of IPv6 
which does not exist in IPv4 then the issue becomes relevant. But in general if 
you're using an IP address in a way which works equally well in either protocol 
version then why would it matter?

Many people here worry that requiring a new SMTP protocol would unnecessarily 
delay implementation of anti-spam solutions. Not that it's a bad idea in the 
long-term, but we also need short and medium-term techniques too. Surely 
requiring IPv6, which is not yet widely used, would have a similar delaying 
effect?

Andrew

---

From: Walter Dnes <[email-masked]>
Date: Tue, 15 Jul 2003 00:01:24 -0400

On Sun, Jul 13, 2003 at 07:48:42AM -0400, Daniel Feenberg wrote

> (3) You mentioned the MAPS DUL. Do systems voluntarily send their
> IP address ranges to MAPS, or does MAPS generally figure it out
> for themselves? If the latter, do we have any idea why they don't
> cooperate?  Does that indicate they won't cooperate with NO_XMIT? Will
> the existence of a formal standard affect many of them?

  Quite a few systems give out their dynamic IP ranges voluntarily to
DUL etal.  It doesn't have the hardware purchase+management headaches
of port-25 blocking.

---

From: Walter Dnes <[email-masked]>
Date: Tue, 15 Jul 2003 00:01:57 -0400

On Sun, Jul 13, 2003 at 09:04:28AM -0400, Alan DeKok wrote

> be implemented by updating DNS for a domain, there *must* be a global

  ??? it requires updating records in a nameserver.  How does it differ
from "host -t MX 10.1.2.3" ?

---

From: Walter Dnes <[email-masked]>
Date: Tue, 15 Jul 2003 00:02:29 -0400

On Sun, Jul 13, 2003 at 08:54:49PM -0400, Yakov Shafranovich wrote
> Where in the DNS system would this data be stored?

  yar (yet another record), just like MX (or the proposed RMX).

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Jul 2003 14:46:17 +0200

Folks,

YS> This brings to mind a general issue, should IPv6 support be part of the
YS> requirements? 

Perhaps I am misunderstanding something, but I think this is like saying
that ethernet and ppp dial-up support should be part of the
requirements.

In other words, we are working at too high a level for the choice of
networking-level protocol to be relevant.

However, if anyone can explain how IPv6 details are relevant to Internet
email-related spam control mechanisms, please do.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Walter Dnes <[email-masked]>
Date: Sun, 20 Jul 2003 15:36:33 -0400

On Fri, Jul 18, 2003 at 02:46:17PM +0200, Dave Crocker wrote

> email-related spam control mechanisms, please do.

  Maybe a better way to put it is that any proposal should not break
when ported to an IPV6 environment.  DNSbls are going to be interesting.
IPV6 has only one address pointing to "self", i.e. ::1.  IPV4 has 2^24
addresses in the 127.0.0.0/8 loopback block.  This allows aggregators
like Osirusoft to return different answers for an IP address, depending
on which of several lists it may be in.  zz.countries.nerd.dk returns
127.0.X.Y where X * 256 + Y = numeric ISO country code of the country of
origin of the IP address.

  The current IPV4 decimal values of 127.X.Y.Z can be represented as
::FFFF:127.X.Y.Z under the legacy-support feature of IPV6.  What worries
me is that outfits with a vested interest in adoption of IPV6 may go out
of their way to disrupt legacy support for IPV4 sooner rather than
later.  And it is legacy support, make no mistake about it.

  I suggest using link-local 64-bit address space for DNSbl return
values.  This will minimize the chances of stepping on somebody else's
toes.  For backwards compatability, may I suggest ::7F:0:0:0 through
::7F:FF:FF:FF.  This will map exactly one-to-one with the space
::FFFF:127.0.0.0 through ::FFFF:127.255.255.255.  A comparison that uses
the 3 or 4 least-significant-bytes won't care whether the answer came
from an IPV6 machine or an IPV4 machine.