Subject: [Asrg] Problems with RMX

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 6 May 2003 15:16:17 -0400

1. It requires changes to DNS

The idea behind RMX can be implemented without changes to DNS, however.  For
example, via MX records, as already mentioned, or via some specially coded A
record (see http://www.bondedsender.org/#dns-info).

2. Too many control points.  There are just too many domain names and too
many domain name servers for the presence of an RMX record to mean much.
Yes, it reduces the forged header problem, but it's just too easy to set up
your own domain name server that it will mean little in the way of
controlling spam.

Presumably this is what Dave Crocker meant when he said:

> However, the belief that it would have been useful under those
> circumstances is based on the view that the administrator of the
> timesharing system was independent of the person running the
> applications AND that administrator could be expected to be trustworthy.
>
> And therein lies the same, serious problem with RMX.

3. What do you do when there is no RMX record?

My proposal, for _any_ authentication scheme, is to bridge the gap with a
"mandatory" challenge-response system.  If you disagree with that, what is
your proposal for how mail from non-RMX systems should be handled.

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

---

From: Michael Rubel <[email-masked]>
Date: Tue, 6 May 2003 13:07:05 -0700 (PDT)

KH> The idea behind RMX can be implemented without changes to DNS, however.
KH> For example, via MX records, as already mentioned, or via some specially
KH> coded A record (see http://www.bondedsender.org/#dns-info).

Ken,

If I'm understanding the article at this link correctly, the way bonded
sender works is to certify certain IP addresses as non-spammer, and
then to provide a mechanism to report violations--in which case, the
"bonded" status of the sender's IP address is revoked.

This is not the idea behind RMX at all!  In particular, the presence of
RMX records does not imply that a domain is not spamming--only that the
messages you have received "from" it are not forged.  Also, RMX does not
require a trusted third party, and has finer granularity (by domain
name, not by IP address).  Please see Hadmut's draft or my page (link at
bottom) for more details.

RMX is designed to be an anti-forgery device, not an anti-spam device.
However, removing the ability to make email appear to come from a
trusted (or otherwise unlikely-to-be-blacklisted) source would remove
one of the spammers' more potent obfuscation weapons, and therefore make
spam easier to detect and filter.

If you'd like to discuss the bonded-sender concept further, or if I've
messed it up, please let me know.

> your own domain name server that it will mean little in the way of

This is not really a limitation.  Does it make more sense in the context
I've just described?

> your proposal for how mail from non-RMX systems should be handled.

Actually, my article explains RMX as a three-way handshake--that is, a
challenge-response.  See:

http://www.mikerubel.org/computers/rmx_records/#dns

or read the whole article at:

http://www.mikerubel.org/computers/rmx_records/

Mike

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 06 May 2003 16:31:17 -0400

"Ken Hirsch" <[email-masked]> wrote:
> example, via MX records, as already mentioned,

  Which overloads the meaning of MX records.

  There is currently no requirement that originating MTA's for a
domain are the same as recipient MTA's for that domain.  Many systems
have them on different machines.

  RMX permits such behaviour to continue.  Overloading MX records
forbids that behaviour.

> your own domain name server that it will mean little in the way of

  It's one more hoop that spammers have to jump through before they
can send spam.  It's one more way of tracing spammers, once they have
sent spam.

> 3. What do you do when there is no RMX record?

  This question has already been answered multiple times.

> your proposal for how mail from non-RMX systems should be handled.

  The answer is "no worse, and no better, than it is today."

  Alan DeKok.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 6 May 2003 16:58:33 -0400

From: "Michael Rubel" <[email-masked]>
> messages you have received "from" it are not forged.

Yes, I understand that the meaning of the RMX record is different.  My
only point is that you can accomplish the same purpose without having to
invent a new resource record type.  All you need is a convention about
the meaning of the records.

[...]
> This is not really a limitation.  Does it make more sense in the context

I understand it.  I just think that it has very little worth because of
that.

> Actually, my article explains RMX as a three-way handshake--that is, a

That's fine, but you still need to say what should happen when there is
no RMX record.  Since deployment could take many years, this is
important.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg