Subject: RE: pros and cons of RMX (Re: [Asrg] Declaration to the world)

From: "Jonathan Wilkins" <[email-masked]>
Date: Thu, 6 Mar 2003 18:06:45 -0800

I don't have a favorite solution yet.  I think it's too early 
for that.  I personally agree with Brad Templeton and favor 
solutions that require as few changes as necessary to the rest
of the internet infrastructure and SMTP semantics.  

The reason I've been so vocal about the RMX proposal is that
I find it to be really objectionable since it requires a lot
of effort from a lot of people for no particular gain.  It's 
just another step in an arms race that has minimal long term
benefits.

I do agree wholeheartedly with you that there will not be one 
single solution.  It will take a lot of effort from a lot of 
people.  It will take a lot of code, much of which won't work,
but which will bring us closer to understanding what _will_ 
work.  I just think that it's worth discarding certain approaches 
which don't stand up to scrutiny rather than spending a huge 
amount of resources to prove empirically that they don't work.

That's how security research works.  People propose systems.
Then everyone attacks them.  Whatever's left standing wins.
I hope that no one is taking my comments too personally, but
I don't believe in sugar coating technical arguments.  If
something's weak, I believe that everyone should at least be
aware of the weakness.

						Jonathan

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Thursday, March 06, 2003 5:26 PM
To: Jonathan Wilkins; Hallam-Baker, Phillip; Chris Lewis; ietf anti-spam
research group

> No it's not rhetoric.  It's a statement of fact.  DNS alone
> doesn't solve this problem.  If you want RMX to work, you need
> to do one of the following:
> 1. patch the DNS protocol
> 2. patch DNS servers to keep track of multiple bogus responses 
>    and inform the SMTP server
>    (what you're going to do when this happens is unclear.  Since
>    they're UDP and spoofable, surely you're not proposing that 
>    all data from that IP be dropped)
>    See any IDS list for details on the hazards of automated
>    filtering.
> 3. Add a NIDS that watches for lots of unasked for DNS replies
>    and communicates with your SMTP server.
> 
> If you're doing this much to compensate for a broken protocol, 
> you ought to re-evaluate the cost-benefit equation.

Perhaps we might get further if you just told us all your pet 
theory rather than making us all wait till you have attacked
everything else.

You might find that we don't consider your pet theory to be
incompatible or in competition.

You appear to have the same problem Bruce Schneier had with security
before he wrote secrets and lies. The perfect is the enemy of the 
good. Security is risk control, not risk elimination.

Spam is an infestation, we are not going to find a magic bullet.
We are going to have to fight a long war on many fronts. We shall
fight them with filters, we shall fight them with authenticated
mail, we shall fight them in the legislatures and in the court 
room. We shall never surrender but if the Internet shall last a 
thousand years it shall be said of us that this was our finnest
hour.

		Phill

	Phill 

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

---

From: wayne <[email-masked]>
Date: 06 Mar 2003 23:51:14 -0600

> just another step in an arms race that has minimal long term

Well, I'm not certain what your definition of "a lot of effort" or "a
lot of people", but domain specific DNSBLs can be implemented very
easily.

Just for kicks, I've implemented a domain specific DNSBL for my
midwestcs.com domain.  To find out if the IP address is, in my
opinion, acceptable to send mail claiming to be from the midwestcs.com
domain, you need to use the smtp-out.midwestcs.com DNSBL.  That is, if
the IP address is w.x.y.z, you would query
z.y.x.w.smtp-out.midwestcs.com just like any other blacklist.  If it
returns 127.0.0.1, it should be rejected.  If the A record is not
found, it should be accepted.

I created this domain specific DNSBL by adding the following lines to
my zone file:

; default entry: reject
*.smtp-out      IN      A       127.0.0.1
; acceptable sending IP addresses
234.212.222.206.smtp-out        IN      CNAME   OK
237.212.222.206.smtp-out        IN      CNAME   OK
; just in case
OK      IN      TXT     OK

The next step is to use this black list.  Just because it was easy for
me, I hacked on SpamAssassin to check for domain specific DNSBLs.  I
did this by adding the following fuction to EvalTests.pm:

sub check_dsdnsbl {
  my ($self, $set) = @_;

  my $from = $self->get ('Reply-To:addr');
  if (!defined $from || $from !~ /\@\S+/) {
    $from = $self->get ('From:addr');
  }
  return 0 unless ($from =~ /\@(\S+)/);
  $from = $1;

  dbg ("checking domain specific DNSBL for $from", "rbl", -1);

  return check_rbl( $self, $set, "smtp-out.$from", 1 );
}

I also had to add the following to my local.cf file:

# check domain specific DNSBL
header RCVD_IN_DSDNSBL		rbleval:check_dsdnsbl('smtp-out')
describe RCVD_IN_DSDNSBL	Received via Domain Specific DNSBL of sender
tflags RCVD_IN_DSDNSBL          net
score RCVD_IN_DSDNSBL           1.0

Ok, as of tonight, anyone in the world can find out if an IP address
should be sending you email claiming they are from my domain, and any
domain in the world will be checked by me for the same thing.  This
isn't much, but it is a start.

I suspect it would be about as much work to add this check to a
sendmail.cf file, but about 10 years ago I decided that hacking on
sendmail.cf files was less fun than pounding my fingers with a
hammer.  Someone who enjoys this kind of thing would need to do that.

It shouldn't be hard to add this kind of check to any MTA that already
supports DNSBLs, such as exim.

Oh!  Before anyone adds the above code to their SpamAssassin, that my
copy of SA has fixes for the DNSBL checks.  SA's DNSBL checks are
pretty bogus because the check from the originating end of the receive
chain, which of course can be completely faked.  To the best of my
knowledge, this is still broken in the just released 2.50 version.

Anyway, consider this a "proof of concept".  I welcome any comments or
suggestions about it.

-wayne

---

From: [email-masked]
Date: Thu, 6 Mar 2003 20:11:34 -0800 (PST)

How is this going to work for [email-masked] email?

Lets say I run this code to check your dnsbl. Now you send email to asrg, 
responding to this post, my MTA receives it and goes to your domain 
specific dnsbl, it sees that you support it and checks ip address of the 
ietf mail server and that ip is not in your dnsbl, so your email is rejected.
(Damn, And I really wanted to read your reply! :)

---

From: wayne <[email-masked]>
Date: 07 Mar 2003 00:11:53 -0600

> ietf mail server and that ip is not in your dnsbl, so your email is rejected.

Ah, the email that you are replying to didn't come from my domain, it
came from ietf.org and and a From_ address of [email-masked].  If you
had implemented the check, you would have found that ietf.org doesn't
have a domain specific blacklist, and therefore you should accept
email from [email-masked].

My message to the ASRG list was received by my machine just fine.

> (Damn, And I really wanted to read your reply! :)

Yeah, sure you did.  ;->

-wayne

---

From: [email-masked]
Date: Thu, 6 Mar 2003 20:41:51 -0800 (PST)

Ok, you're right - ietf are good with technology and set FROM in the mail 
transmission to mailing list (which actually causes some spam filters to 
think email is forged), but there are mail lists and forwarding systems 
that do not do this and set FROM to the original sender.