(RMX) Re: Scope, and a preliminary list of issues

On Thu, Oct 02, 2003 at 10:57:40AM -0400, Alan DeKok wrote:

> For now, I would like to have the author of each proposal to post a
> 1-2 sentence response to each of these issues. 


OK, here are my RMX responses:


> 	I.1. Proposed design for addressing issues related to EHLO

RMX does not deal with HELO and EHLO. 


> 	I.2. Proposed design for addressing issues related to MAIL
          FROM

Lightweight verification of the given address, either domain part
only or full address.

Should we mention the "From:" header line?





> 	II.1. Do (or should) the designs require DNS protocol changes

Not exactly a "protocol" change, but a new RR type. However, the
latest RMX draft will contain a proposal about encoding RMX in TXT
records to eliminate the need to introduce a new RR type. (I'm not
happy with that, but the new RR type might be too costly...)


> 	II.2. What entities in the network have to implement these
          proposals

I'd split II.2 into two or more distinct questions:

Who has to buy/write/install new software?

  - The receiving MTA (to do the RMX lookup)
  - Maybe the sending MTA (for the new experimental RMX methods)
  - Maybe DNS service providers depending on their individual 
    methods to keep zone tables up to date.

Who has to change configurations, rules etc.?

  - DNS zone table maintainers / service providers

  - MTA maintainers (e.g. should it query RMX or not? which
    other MTAs should it trust without querying RMX?)



> 	II.3. Do we have existing implementations of proposals
> 	      (MTA, MUA, etc)


I have an implementation of an earlier version of the 
draft (i.e. a plugin for bind9 and a milter module for sendmail).
It's not up to date, but a proof of concept. Will not be much
work to update it to the current draft once RMX gets finished.
Implementation available at http://www.danisch.de/software/rmx/




> 	III.1. What is the cost of deploying the proposals
> 	       (time, effort, $$)


Uh, what a question. How should I estimate this?

Per receiving end user 
  No costs

Per e-mail sender
  Depends on what it takes him to get mentioned in the RMX records
  (e.g. might require to get a DynDNS account)

Per DNS zone table
  Depends on what it takes to initialy configurate it and keep
  it up to date (manually or automatically)

Per MTA (those connected to the world)
  install new software

Per message delivery
  No costs for sender

  An RMX lookup, possibly further DNS lookups (and subsequent work,
  see my separate posting) per incoming message.

... (anything forgotten?)









> 	III.2. What is the impact of the proposals on mailing lists
> 	       i.e. Does the behaviour of sender or receiver change?

No impact if the mailing list is setup properly.
Huge impact if the mailing list is no setup properly.

What I want to say: Most mailing list handle messages properly,
i. e. they keep the original sender in the From: header and
insert their own envelope sender address (such as
[email protected]). This will work perfectly under RMX as
long as the list maintainer keeps his own RMX records
appropriate, which can be presumed.

There are some broken mailing lists where the original envelope
sender is used for redistribution. These lists will fail unless
all senders mention the processor in their RMX records. I don't
see this as a flaw of RMX, but of broken list processors. If we
keep this door open, any spammer could pretend to be a list
processor redistributing a message with your sender address.



> 	III.3. What is the impact of the proposals on roaming users
> 	       i.e. Does the behaviour of sender or receiver
> 	change?

Impact on receiving mail:

   No impact. They have to receive using something other than
   SMTP anyway (such as pop/imap/uucp).

Impact on sending mail:

   Yes, if they are delivering by SMTP to the world (which they
   should not do in my eyes). They have to manage to somehow
   update the RMX records or what the RMX records reference.

   The RMX draft addresses this special issue of road warriors. 
   My special proposal for these users is to have a DynDNS
   account which is updated on every connect and to have a
   fixed RMX entry referencing the DynDNS name.

   A second proposal (from my point of view the better one, but
   much more expensive) is to make mail protocols bidirectional. 
   If someone receives messages by pop/imap/uucp from some
   provider, he should deliver the same way. This would in 
   common eliminate SMTP traffic from dynamically assigned 
   IP addresses.



> 	IV.1. What part of the spam problem do these proposals
          address

Forgery of (envelope) sender address only. Message content and
quantity (bulk or not) are completely ignored.



> 	IV.2. How can spammers work around these proposals

- Not forging addresses (i.e. use their own address)
- Use addresses of domains without RMX records of with too 
  loose records (like 0.0.0.0/0), depends on whether the
  receiver is willing to accept such mails.
- DNS poisoning/spoofing
- modifying zone tables (e.g. by breaking into DNS servers)
- modifying MTA software (e.g. by breaking into relays)



> 	IV.3. What is the cost to spammers of working around these
> 	      proposals

Costs will be low in the beginning, but will grow the more and
more RMX become common, if the spammer is using *any* sender
address.

Costs for spammer will be much higher if they try to use 
particular addresses (hotmail/yahoo/aol/...)




> 	IV.4. How much of an impact do these proposals have on
          spam

Spammers will be forced to use sender addresses of domains they
have to access to or who's owner allow abuse. Consequences are
to be discussed.



> 	IV.5. Does the cost the implementing the proposals justify
> 	      the effort?



Yeah, since the costs are still low compared to the costs caused by
spam. People do pay much higher costs for content filtering to 
get rid of the rubbish.






regards
Hadmut