Subject: draft-danisch-dns-rr-smtp-02.txt

From: Robert Elz <[email-masked]>
Date: Tue, 03 Jun 2003 20:11:07 +0700

DNS people may want to take a look at

	draft-danisch-dns-rr-smtp-02.txt

and make some comments.   In particular...

      +---+---+---+---+---+---+---+---+
      | N |    Entry Type Code  (4)   |
      +---+---+---+---+---+---+---+---+
      |  Encoded and Compressed DNS   |
      /  Name as described in RFC1035 /
      +---+---+---+---+---+---+---+---+

is going to be worthy of some comment I suspect (and from a quick
glance, probably more).

I gave up on careful reading at ...

   The suggested method is to let the DNS server for the sender domain
   provide informations about which IP addresses are authorized to use
   the domain within a sender's address.

which I cannot find any possible way to implement.   That is, I have no idea
at all how I'd specify which IP addresses are authorised to send e-mail
claiming to be from munnari.oz.au - as that set is more or less, the
IP address where I happen to be this week, and can be anything.

What's more, usually, wherever I am, I use whatever is the local mail
relay (check this message, you don't find it coming from anywhere near
munnari.oz.au - but it is also not forged, I promise...).   If there is
none, I will send directly from my laptop, but using the local relay allows
for it to queue and retry sending mail, while not requiring my laptop
to remain active.

I simply will not, ever, relay all my mail back to Australia to be sent
back (quite often, to wherever I happen to be).   That's the only way I
can imagine making the scheme in this doc work.

What's more, to assist in reducing, as the claim is that this will do,
everyone has to do it - it is no good just some small fraction of sites
saying "I know where email from my domain name must come from" even allowing
for the small chance that they're correct in that assessment.
If there aren't enough people implementing this, no-one is going to
waste time attempting to verify it.   If verification is attempted,
it is useful only if mail is permitted only on success - which means
everyone has to install RMX records and keep them up to date somehow.

Forget it.

kre

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 3 Jun 2003 15:44:38 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

G'Day,

> and make some comments.   In particular...
...
> is going to be worthy of some comment I suspect (and from a quick

Maybe you could elaborate this a little bit and tell me
what exactly you're talking about, because  I'm not a fortune
teller.

> IP address where I happen to be this week, and can be anything.

Maybe you should have read the whole draft carefully.

Or maybe you should have read something in the ASRG IRTF group.

The problem that is to be solved is the arbitrary forging of 
mails. Currently, it is possible to send mail with any sender domain
from any IP address. That's a complete lack of security. That's the
way spam works.

And by the way, you are not required to have an RMX record at
all. Or you can give a 0.0.0.0/0 permission, thus allowing any
IP address on the planet. But since people urgently need to stop
spam, they might reject mails from domains who authorize just anyone
to abuse it.

To give you a solution to your problem:

- Use a dyndns entry
- Write a entry of the type host:your.dyndns.domain in your
  RMX and your problem is solved.

> munnari.oz.au - but it is also not forged, I promise...). 

That's exactly the problem. You "promise" it is not forged, but
there is no technical way to determine it, because there is no
technical difference. From the technical point of view, this mail
is indistinguishable from forged e-mail, even if you promise. 
And that's the problem RMX is going to solve the easiest and cheapest
way.

Just answer a question: How do you *receive* e-mail
when you're on the road?

> can imagine making the scheme in this doc work.

- You're doing this for incoming e-mail:

  munnari.oz.au           MX      60 mail-gate.cs.mu.oz.au
  munnari.oz.au           MX      10 munnari.oz.au
  munnari.oz.au           MX      30 mulga.cs.mu.oz.au

  So why is it a problem for outgoing e-mail?

- Get a second relay on the continent of your choice.

- Use a DynDNS entry

- Use a wide RMX entry

- Don't use an RMX entry at all.

There are plenty of ways to handle it. 

> everyone has to install RMX records and keep them up to date somehow.

Wrong.

Hotmail, AOL, Yahoo, T-Online,etc. are in severe trouble due to the 
extreme amount of spam abusing their sender domains. Once
these big providers start to have RMX records, Spammers will 
move to abuse other domains without RMX records. Domain owners
will receive complaints. I received tons of complaints because some
spammer abused danisch.de for about half a year, and that's why I
developed RMX. So every domain owner who's domain is abused will
be happy to volunteer to use RMX.

Wait until some spammer chooses your domain for abuse, you will
be quite happy to have RMX. 

So all it takes is the big providers Hotmail, AOL and Yahoo
to initiate the avalanche. 

regards
Hadmut

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 3 Jun 2003 15:35:33 -0700 (PDT)

On namedroppers, Robert Elz wrote:
> and make some comments.

Here's a couple of quick comments:

This looks similar to the Jim Miller / Paul Vixie "Repudiating MAIL
FROM" proposal, only using a new RR type instead of overloading MX;
see for example

  <http://groups.google.com/groups?selm=20020602011637.CE9FC28EDD%40as.vix.com&output=gplain>

Section 5.5.3 specifies that the domain name in a type "host" entry is
compressed.  It should specify that it is not compressed; see
draft-ietf-dnsext-unknown-rrs-05 for the reasons why.

The meaning of the exclamation mark that occurs in some of the zone
file syntax examples needs to be defined in the text.
-- 
Andreas Gustafsson, [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 04 Jun 2003 00:30:55 -0500

I've looked at the draft. It's the most-complete of the variants.

The discussion text is appropriate for a general draft but most of it
should probably be chopped from the final.

|   This memo suggests a new DNS RR type to provide a very simple
|   light-weight authentication scheme for the domain part of the

It's an authorization scheme, not authentication

|   simple and robust protection against e-mail fraud and especially
|   spam.

It offers protection against unauthorized use of a mail domain. I'd
strongly suggest dropping any reference to spam, except as an example of
the kind of mail that often uses unauthorized mail domains. Although it's
certain to have some impact on spam, it's going to be very easy for
spammers to get around the filter, so its a dead-end for that specific
objective. However, it will always work as an anti-forgery device if the
sender and receiver both use it.

|   For any domain name there should not exist more than a single RMX
|   entry.

I'd suggest using one entry per RR.

You should also change the zone-file shorthand to numbers instead of
strings. It will be simpler to map a decimal value in a zone file to a
numeric value in the message.

| 5.3.  Hostname (Type 3)

As was already pointed out, you can't use compression with new RRs.

I'd add another entry as an alternate to the "host" type, which would be
a plain "domain name" type. Essentially, a receiver would need to issue a
pair of reverse and forward lookups, and if the host had a domain name in
the specified domain, then it would be allowed. Some folks are in highly
distributed environments, and this would keep them from having to add
multiple hosts or netblocks to cover their entire domain. Note that
issuing a reverse PTR lookup followed by a forward A lookup would be
necessary to prevent forgeries, since it's really easy to spoof PTR
resource records.

| 6.  Message Headers

My guess is if you're going to specify headers, you need to specify that
any such headers in messages received from external sources are to be
ignored or removed. That's really something for the SMTP folks to deal
with, but my guess is you'll get some pushback.

I'd trim most of the text from section 10 down.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 4 Jun 2003 08:43:20 -0400

I generally agree with the previous comments on this draft.  In addition, I
have one smaller nit that caught my eye:

5.3.4.  Additional Records

   In order to avoid the need of a second query to resolve the given
   host name, a DNS server should enclose the A record for that domain
   name in the additional section of the additional section of the DNS
   reply, if the server happens to be authoritative.

I think the "a DNS server should enclose..."  should be replace with a
"SHOULD" or (better in my opinion) "MAY".  If an A/AAAA RRset is to be
placed in the additional section, this needs to be clearly defined, as it is
now talking about how responses are generated and what a resolver could
expect.  Personally, I favor "MAY".  This type of rule would require a code
change (not major), but also might be mis-interrpreted by older caching
servers somewhere in the resolution proces.  It is no major feat for a
resolver to do another query to get the A RR pointed to by this response.

Scott

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 4 Jun 2003 01:07:42 +0200

> draft-ietf-dnsext-unknown-rrs-05 for the reasons why.

Good hint, thanks.

Since RMX records tend to get rather large, choosing compression is
not just a matter of taste. Following your draft and its
argumentation, there will never ever be a new RR type with
compression. This compression scheme smells broken.

Astonishingly, my tests in my local network did not reveal that
problem, although an older bind9 was involved. 

I'll think about that problem. 

Unfortunately, there is no usable documentation of bind9 and
ISC does not provide support. I did not figure out how to 
store a DNS name correctly without compression. Maybe it will
end up in storing simply a string or in using a different compression 
scheme. 

> file syntax examples needs to be defined in the text.

Another good hint, thanks. The exlamation mark has the same meaning as
in APL records, it is the symbol for the negation flag. 

regards
Hadmut

---

From: Dean Anderson <[email-masked]>
Date: Wed, 4 Jun 2003 16:04:06 -0400 (EDT)

General comments
================

Senders of email from a domain are not, in general, attached to an IP
address. They may use any IP address from any service provider they
please.  For example, I have customers which have leased lines from Av8
Internet, but have their email outsourced to Earthlink. Earthlink does not
provide them with relay services. So Av8 provides them with relays
services. The result is that their email, from their domain (otherwise
hosted at Earthlink) comes from our servers.  Earthlink also allow them to
use <username>@earthlink.net. So email from those addresses may also
originate from our server.  Limitations on the IP addresses that may be
used by users, and thus on the industry of Email Outsourcing, and for
private use, tend to subdivide the internet, and seem to violate the ISOC
Code of Conduct sections 4 and 14.

Dr. Claude Shannon, one of the founders of the science of Information
Theory, proved that it is impossible to prove the non-existance of a
covert channel. In terms of spam, this means that it is impossible to
construct a protocol that cannot be abused, since one cannot prove that it
is impossible (the channel can't exist) to send abuse (a covert channel).
No protocol can ever be constructed that is spam-free.  Radical
anti-spammers often try to couch their arguments as though the spammers
are "outsiders" who have been let in. This isn't true. All abusers are the
customer of some ISP, somewhere. There are no outsiders.  The spammers are
in fact authorized users of some ISP that are authorized to send email.
They remain authorized to send email until they lose service with that
ISP.  Once this is understood, it is completely obvious even without the
formality of Shannon's theorem that protocols such as this will have no
effect whatsoever.

It goes without saying that the DNS protocol is itself not secure, and
can't be used for any type of authorization or authentication scheme.

Therefore, I think this proposal will have no effect on the problem of
spam control, and leads to a gratuitous change to the DNS protocol.

Specific Comments
==================

Section 10.1.5

This section asserts that open relays are a "main problem of spam
defense".  Having operated open relays for many years, I have substantial
operational experience to refute this claim. Our open relays are typically
only abused by radical antispammers, sometimes with overt threats. In at
least one case, an abuse admin (Chris Neill) was fired (according to his
own description posted on spaml) for abusing our open relay "to teach me a
lesson".

Use of an open relay (or a closed relays) includes the connecting clients'
IP address in the Recieved: header. This header cannot be altered by the
client.  Use of an Open relay does not hide the identity of the sender.
Use of an open relay does not alter the property of a user's anonymity.
Open relays don't ever "make things worse".

The section also contains the false statement: "Once the administrative
persons refuse to solve the problem, they can be identified as spammers
and held responsible."  The spammer is the person who sent the spam. It is
not the person who operates the relay or the person who operates the
router. The spammer sent the spam. No one else did.  No one else is
responsible for spam.  Open relay is the only way to offer SMTP service
(as defined in IETF STD 10) to clients outside ones IP address.  None of
the alleged harms of open relay have ever withstood close scrutiny.
Provably false statements like the ones found in Section 10.1.5 should not
be propogated in RFCs.

Section 7 of the ISOC Code of Conduct requires members to "Only offer or
claim to offer opinions or services that lie within the member's actual
knowlege or competence". May I ask what direct, current, and relevent
experience you have operating open relays?

Dean Anderson
President, Av8 Internet, Inc

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Jun 2003 01:37:05 +0200

> spam control, and leads to a gratuitous change to the DNS protocol.
..
>> this is simply a low hanging fruit exercise, the cost of deployment is low
>> and the leverage is significant.
>
> The cost of altering the worlds DNS servers is usually considered high.

If the world's DNS servers are compatible with d-i-dnsext-unknown-rrs,
no changes to them are required to support RMX.  Other systems (e.g.,
DNSSEC) are contingent on d-i-dnsext-unknown-rrs, so I don't think
there is much practical merit to this argument against RMX.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 04 Jun 2003 10:49:15 -0400

>resolver to do another query to get the A RR pointed to by this response.

I take to opposite position, NO SPECIAL PROCESSING.

There is no advantage to having this processing except to sometimes
save on network delay at the cost of more complicated authoritative server,
and resolver.

Additional section processing should only be used to assist in DNS
operation not application lookup.
Please remove this section it will only delay the deployment of this
RR type and authoritative and recursive servers that know about this will
take a long time to get deployed, while many existing servers can
support this type via the unknown-rr type support.

For more background see the discussion on namedroppers on including KEY
RR's in additional section.
http://psg.com/lists/namedroppers/namedroppers.2003/msg00235.html

         Olafur

---

From: Dean Anderson <[email-masked]>
Date: Wed, 4 Jun 2003 22:02:51 -0400 (EDT)

> there is much practical merit to this argument against RMX.

Except that, unless I am mistaken, dnsext-unknown-rrs is just a draft.

		--Dean

---

From: [email-masked]
Date: Thu, 05 Jun 2003 13:48:27 +1000

> Except that, unless I am mistaken, dnsext-unknown-rrs is just a draft.

	Compression is not allowed by RFC 1034.  dnsext-unknown-rrs
	just reinforces it.
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 18:22:17 +0700

Date:        Tue, 3 Jun 2003 15:44:38 +0200
    From:        Hadmut Danisch <[email-masked]>
    Message-ID:  <[email-masked]>

  | Maybe you could elaborate this a little bit and tell me
  | what exactly you're talking about, because  I'm not a fortune
  | teller.

First, apologies - my message wasn't really for you, it was for the
namedroppers mailing list, I just added your name as a courtesy 'cc'
(also to make it easier for others to reply to where it would do some good).

You've already been told that the problem I was referring to was the
use of name compression, and to respond to a later message from you, yes,
that means that DNS name compression can never be used in any future
RR.   That's just the nature of the method, the DNS, and the way it
was specified, and there's no rational way to change that now (no-one
can deploy a different compression scheme as there's no way to expect
anyone would be able to understand it).

  | Or maybe you should have read something in the ASRG IRTF group.

I had no idea it existed, and from what I have been told, no desire
whatever to have any contact with that at all.

  | The problem that is to be solved is the arbitrary forging of 
  | mails.

We already have a solution to that which actually works.   Signed mail.

If I sign my mail, then it is possible to verify that i really did send
it, and if you want to prefer only signed mail, or rank mail as "signed
therefore probably good", "unsigned so we don't know", and "appears to
be signed, but forged, so almost certainly bad", then by all means,
go ahead.

Your problem is that you can't manage to get people to actually use
this method, so you're attempting to impose a bogus inferior
attempt to achieve similar results upon them, without consent.

  | That's exactly the problem. You "promise" it is not forged, but
  | there is no technical way to determine it, because there is no
  | technical difference.

In that message there wasn't, and in this one there isn't, but if I
signed it, there would be.   And that's easy (there was a time I had
my mailer set up so I could easily sign mail, then I upgraded systems,
etc, and didn't bother keeping it all up to date - but that would be
easily fixed if there was any real point to it).

  | Just answer a question: How do you *receive* e-mail
  | when you're on the road?

I have it sent to my mailbox, and yes, that means to Australia.
But there's very little alternative to that.   The same is true
of my physical mail, it all goes to a mailbox in Australia as
well.   But that doesn't stop me dropping mail in a letterbox,
anywhere in the world, with my Australian address on it as a
return address.   Remember that e-mail was (and is) intended to
be the electronic analog of paper mail (memos anyway).  Do
you really expect that anyone would endorse a scheme where
letters could only be posted from specially approved mail boxes
(or that any posted elsewhere would gain a "probably forged"
imprint upon it)?

Anyone who takes any mail I have sent, and suggests that that mail
is likely to be a forgery is opening themselves to a slander suit -
or if they do it in writing, libel instead.

  | - You're doing this for incoming e-mail:
  |   So why is it a problem for outgoing e-mail?

Because I have no option for incoming mail.   It is the nature of mail
that it get delivered to a particular mailbox.   It remains there until
I get the opportunity to fetch it (unaffected by loss of connectivity).
If senders can't reach my mailbox, they, or some relay, queues the mail
and tries again.

With sending mail, I want to be able to send it any time - including
when I can't reach my mailbox (in particular when I can't reach my
mailbox - I want to be able to report that to someone - they might not
be able to reply instantly, but they can get the problem fixed).

  | Hotmail, AOL, Yahoo, T-Online,etc. are in severe trouble due to the 
  | extreme amount of spam abusing their sender domains.

Quite likely.   But...

  | Once these big providers start to have RMX records,

Those big providers (not as sure of AOL) are the very ones for whom
this scheme can't really work.   For munnari.oz.au where I am, in
practice, just about the only user of the domain, I could probably
find some way to handle the problem.   But there are millions (I
assume) of users of hotmail, and they aren't all going to always
want to send their outgoing mail via hotmail - they use that as
a convenient mailbox, and (fairly) stable and anonymous address.
They send from anywhere.

  | Wait until some spammer chooses your domain for abuse, you will
  | be quite happy to have RMX. 

Already been there (more than once).   And no, I will not be using RMX
or anything like it.

kre

ps: spam is just e-mail, there is not, and cannot be, a technical
solution to spam.   Even if you can prove who is sending the mail,
(or who isn't) by locking down everything, spam will still continue
to be sent, as long as doing so benefits the sender more than it
costs them.   The real problem we have is the mis-use of mailing
lists (mis-use of personal data).   Fix that, and spam will go away,
at least as much as being a problem, as there will be no way for
lists of people who don't want the mail to be collected.  But the
fix cannot be technical, it needs to be social/political - that is,
we have to get to the stage where the political will is to fix the
problem, and that gets serious enough to overcome the mailing list
lobby.   The more we do technically to reduce the impact of spam,
the longer that will take - the best thing we can do to rid ourselves
of spam, is not to attempt to control it at all.