ietf-asrg
[Top] [All Lists]

Re: [Asrg] seeking comments on new RMX article

2003-05-06 00:31:19
At 07:48 PM 5/5/03 -0600, Vernon Schryver wrote:
From: David Maxwell <david(_at_)crlf(_dot_)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(_at_)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(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg