Re: [Asrg] seeking comments on new RMX article

Scott Nelson <scott@spamwolf.com> Tue, 06 May 2003 07:31 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10504 for <asrg-archive@odin.ietf.org>; Tue, 6 May 2003 03:31:19 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h467deG23681 for asrg-archive@odin.ietf.org; Tue, 6 May 2003 03:39:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467de823678 for <asrg-web-archive@optimus.ietf.org>; Tue, 6 May 2003 03:39:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10486; Tue, 6 May 2003 03:30:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CwwX-0003xb-00; Tue, 06 May 2003 03:32:53 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CwwW-0003xV-00; Tue, 06 May 2003 03:32:52 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467bM823177; Tue, 6 May 2003 03:37:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467OY822325 for <asrg@optimus.ietf.org>; Tue, 6 May 2003 03:24:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10363 for <asrg@ietf.org>; Tue, 6 May 2003 03:15:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cwhg-0003tT-00 for asrg@ietf.org; Tue, 06 May 2003 03:17:32 -0400
Received: from adsl-66-120-64-133.dsl.snfc21.pacbell.net ([66.120.64.133] helo=magic1.org) by ietf-mx with smtp (Exim 4.12) id 19Cwha-0003tM-00 for asrg@ietf.org; Tue, 06 May 2003 03:17:26 -0400
Message-Id: <aT5vaIe86J8qbrFBE02@x>
To: asrg@ietf.org
From: Scott Nelson <scott@spamwolf.com>
Subject: Re: [Asrg] seeking comments on new RMX article
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 06 May 2003 00:18:40 -0700

At 07:48 PM 5/5/03 -0600, Vernon Schryver wrote:
>> From: David Maxwell <david@crlf.net>
>
>> ...
>> You have one more piece of information - "The sending domain is valid,
>> correct, and claims that this host is a valid host to source mail."
>>
>> The current SpamAssassin applies negative scores for certain patterns.
>> Unfortunately, most of the patterns it uses today can be forged by
>> spammers, making them useless. If the RMX 'bit' appears as a header
>> inserted by my local MTA, my filter can give it a negative score, with
>> confidence.
>
>That is mistaken.  Spammers can continue to use Hotmail and Yahoo drop
>boxes and to forge AOL's domain name while abusing open proxies on
>large dynamically addressed cable-modem and DSL networks that have at
>least one AOL, Hotmail, or Yahoo user.  
>

With RMX, if a spammer finds an open relay on AOL then they can 
forge email that looks like it comes from AOL.

Compare that with the non-RMX case where they can forge the domain
example.com and send it through that same relay in AOL.

In the first case, we all pay for receiving the spam, 
AOL pays for sending the spam, 
AOL must deal with complaints about the IP in their network sending spam, 
AOL must deal with complaints about their domain is sending spam, 
and AOL must handle all the bounces that the spam run generates.  

In the second case, we all pay for receiving the spam, 
AOL pays for sending the spam, 
AOL must deal with complaints because their IP is sending spam,
but example.com has to deal with the complaints about their domain 
sending spam, 
and example.com must handle all the bounces that the spam run generates.  

If example.com is an IDSN line, the bounces alone might be enough to 
take out their network.  But they can't do anything until AOL 
decides to fix the problem.  Example.com can't do anything about it.


So to me this looks like a win for RMX, not a tie.

The cynical might point out that it looks better for AOL in the
second case, so why would they adopt RMX?  Note though, that
in case two AOL wouldn't fair any worse if they had an RMX record,
and example.com would have done a lot better if example.com did.


>Because those networks are
>dynamically addressed, an ISP with users on networks that allows third
>party sending (including AOL, Yahoo, and Hotmail) must set their RMX
>'bits' to say "authorized" for all addresses in such a network.  Thus,
>the hardest to filter spam can have good RMX bits.
>

They could set their policy anyway they want,
but I think it's more likely that they would provide relays that
only their users could use, and set their RMX records to point
to only those relays.  The clueless wouldn't be able to handle
sending mail directly, and there won't be that many who want 
to send as example@AOL from within the AOL IP space, 
but refuse to use AOL relays to do that.  Some perhaps,
but I doubt AOL would care that much about them.


>The only fix is to prohibit sending from any mail systems but those
>of the ISP that owns the IP address.  However, if you want to enforce
>that rule, you don't need any new RMX or other bits.  You need only
>compare reverse DNS and envelope sender domain names.  
>
Doesn't follow.


>(Yes, reverse DNS can be faked, but that can be reasonably reliably 
> detected by doing an extra forward lookup of the reverse name.)
>(Yes, in some
>cases you must do a little more than just comparing the PTR and A RRs,
>such as fetching all PTR RRs or all A RRs for the PTR name.)
>

Reverse DNS is controlled by the IP.
If they have an rDNS, you would do about as well by skipping
the rDNS and using the HELO to do a forward look up.
Of course, having rDNS is also a sign of clue, 
and many spammers are lacking in that which makes the mere presence
of rDNS a good test.

>
>(This has nothing to do with my claim that to keep their users, Yahoo,
>Hotmail, and AOL must mark every IP address on the net as "authorized.")
>
They don't have to, but they might want to.
(Though why they would go to the trouble of providing one that's
 pointless instead of just not supporting it is a bit of a reach IMO.)

I don't see it in AOL's case, since they have nothing to lose by
continuing to provide mail relays for their customers, 
but Hotmail might since they don't provide them.
Then again, they might prefer it if people had to use their web
interface to send email.  But hey - their domain, their choice.
Setting a broad RMX means you have to deal with more complaints
and more bounces - they might think it's worth it.


>
>>                                                          When I say
>> _eliminate_, I mean users employing RMX checks will not have to read
>> these spams anymore, and if deployment becomes widespread enough,
>> spammers won't bother sending them anymore.
>
>How widespread enough is enough?  My guess is 80%, but if you prefer
>90% or 50%, I won't argue.  How long will it take to reach that level?
>If it is 10 years, will your ISP deploy this decade?  If 1,000,000
>users get it in the next year, would it be worthwhile for you to check
>RMX bits?  1,000,000 users are about 0.2% of the Internet, so only
>0.2% of legitimate mail would have it.
>

I imagine the amount of time it takes to deploy would depend a lot
on how much real benefit and real cost is associated.
Neither the RMX proposal or the DMP proposal is workable without
some changes to DNS, and DNS changes tend to be slow in coming.
(Didn't Vixie start championing SRV records over 5 years ago?)


When it comes to sending, I think David's premise is flawed.
When new technology has come out in the past,
spammers seem to adapt by sending just as much spam the old way, 
and also sending more a new way that beats the technology.
I think it's more likely spammers will continue to send forged spams,
even if 90% of internet automatically blocks them.


>> ...
>> It eliminates some types of spam. If we had an applicable method that
>> eliminated each type of spam, should we not apply them all - and instead
>> look for a single solution?
>
>Again, how does it eliminate any spam?  In practice, what spam would
>it eliminate that does not already have a mismatch between reverse
>DNS and envelope sender domain?
>

I think a better question is:
"Does it have a better false positive or false negative rate than
 reverse DNS and envelope sender domain?"

And I think it would have a better false positive rate /and/ a better 
false negative rate then reverse DNS + envelope sender domain.
Lots of spam has forged headers and envelopes.  Some spam even
has forged rDNS.  Both would catch the first part, but only
RMX would catch the last.



>
>> ...
>> Today, as a domain owner, I have no way of telling people 'Mail from my
>> domain will only come from these IPs. Any other source is a forgery.'
>
>Wouldn't be simpler to tell everyone to compare your sender domain name
>with your reverse DNS?
>

rDNS does not support multiple domains.
with rDNS, if you have two vanity domains you need two IP addresses.
if you run an email service you might host hundreds of domains
per IP.  So, yes, if you're one of those people it's a lot simpler,
because you couldn't support rDNS at all.


Scott Nelson <scott@spamwolf.com>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg