Re: [Asrg] seeking comments on new RMX article

Vernon Schryver <vjs@calcite.rhyolite.com> Tue, 06 May 2003 02:12 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 WAA24585 for <asrg-archive@odin.ietf.org>; Mon, 5 May 2003 22:12:27 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h462KgC24215 for asrg-archive@odin.ietf.org; Mon, 5 May 2003 22:20:42 -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 h462KR824212 for <asrg-web-archive@optimus.ietf.org>; Mon, 5 May 2003 22:20:27 -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 WAA24565; Mon, 5 May 2003 22:11:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Crxj-0002fy-00; Mon, 05 May 2003 22:13:47 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Crxi-0002fv-00; Mon, 05 May 2003 22:13:46 -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 h461tF822580; Mon, 5 May 2003 21:55:15 -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 h461sq822535 for <asrg@optimus.ietf.org>; Mon, 5 May 2003 21:54:52 -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 VAA24197 for <asrg@ietf.org>; Mon, 5 May 2003 21:46:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CrYy-0002aF-00 for asrg@ietf.org; Mon, 05 May 2003 21:48:12 -0400
Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 19CrYr-0002aC-00 for asrg@ietf.org; Mon, 05 May 2003 21:48:06 -0400
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h461mSbr029489 for asrg@ietf.org env-from <vjs>; Mon, 5 May 2003 19:48:28 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305060148.h461mSbr029489@calcite.rhyolite.com>
To: asrg@ietf.org
Subject: Re: [Asrg] seeking comments on new RMX article
References: <20030505225545.GA23068@mail>
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: Mon, 05 May 2003 19:48:28 -0600

> 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.  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.

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.  (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.)

(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.")


>                                                          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.


> ...
> In the same way that asking a canvasser at your door to show you an ID
> badge won't protect you from badge-forgers, or unsavory organizations,
> it is a miminal (common-sense) first step you can take to verify their
> identity (with the extent of effort you're willing to make).

If only 0.2% of canvassers or your incoming email have an ID, would
you bother checking?


> > of incoming mail.  At first, all mail with an RMX tag would be from
> > people and SMTP clients that don't send spam.  They will often already
> > be white-listed, and they certainly won't care many other signs of
>
> Where's the Internet-wide white list of non-spammers I can get?

Could you whitelist your regular correspondents and cover most of
your incoming mail?  I bet you could, and immediately have better
protection than any scheme like RMX could have until it reached 80%.
And when do you figure that will be?


> An advantage of RMX is that it is decentralized.

Yes, but what matters is how much spam it affects.


> ...
> 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?


> ...
> 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?


]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]


] From: Michael Rubel <asrg@mikerubel.org>

] ...
] RMX gives senders a mechanism to prevent others from credibly
] misappropriating their names, and it does so at minimal implementation
] cost--especially to recipients (I hope that "use_rmx" will become a single
] configuration flag in MTAs, on by default).  It doesn't introduce any new
] protocols or break the vast majority of existing installations (I suppose
] there will always be some, but even the most vehement critic must concede 
] that RMX is remarkably non-disruptive given its potential utility).

Do you run sendmail with more than 10,000 messages/day and if so, do
you turn on IDENT?  My guess is if you answer the first "yes," then
you answer the second "no," because you don't like the costs (especially
delays) of IDENT given its near uselessness against spam or other abuse.
Since the worst spammers (proxy abuses) can have good RMX bits, why
would you bother with extra DNS chatter to get RMX bits?

It looks like your message came from CalTech.  Has CalTech never had
a spammer or an open relay?  Are you confident that you know and will
continue to know the IP addresses of CalTechs outgoing mail servers?
If you fail to authorize the right address, the RMX idea would have
your mail bounce.  If you configured the RMX bits for mikerubel.org
to authorize all 65534 addresses in 131.215.0.0/16, you'd be vulnerable
to any spammer or open relay at CalTech.  (Never mind that I can't
find an A or MX RR for mikerubel.org just now, so by RMX-like thinking,
your message should have been rejected.)

] In some cases, organizations wishing to implement RMX will need to make
] changes to accommodate their traveling or remote members, so that those
] members are able to send mail via the official mail servers.  A wide
] variety of common techniques (SMTP-AUTH, VPN, stunnel, webmail) are
] already available and widely used specifically for this purpose, and
] organizations will be free to make the changes on their own schedules and
] terms.
] ...

So you would prohbit sendmail mail except from the mail systems of
the sending domain?  If so, why bother with RMX?  Why not just enforce
matches between reverse DNS and sending domain?


Vernon Schryver    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg