Subject: Re: [Asrg] Willfull and intentional misunderstandings

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 10 May 2003 22:28:38 -0400

>From: Mike Rubel <[email-masked]>
>
>On Fri, 9 May 2003, Yakov Shafranovich wrote:
> > Additionally the question of slave servers poses a tremendous problem not
> > just in regard to this issue, but in regard to all anti-spam solutions. In
> > theory if a computer has been taken over, what prevents the trojan/virus
> > from doing the following:
> > 1. Emailing other users on the Internet directly.
> > 2. Monitoring local SMTP traffic and finding out what SMTP server is used
> > by the user. Then using that SMTP server for sending spam. RMX/rDNS will
> > not help here since the email will come from a permitted IP range. SSL/TLS
> > will not help since the trojan can capture the password used.
>
>Hi Yakov!
>
>I believe RMX and other RMX-like proposals will help in the slave server
>case.  The spammer can still use the slave to send spam, but if he wants
>to send it using slave owner's identity, the messages must go out thru the
>real outbound mail servers listed in the RMX records or they will be
>rejected as forgeries.
>
>Assume the outbound mail servers are well-secured relative to the slaves
>(which are probably just desktop machines on home cable modems).  The mail
>server admins can use rate-limiters which detect attempts by a user to
>send a lot of messages at once and react appropriately.
>
>If the server admins are not careful and have not installed rate-limiters,
>then the spam gets through and the domain loses trust (by which I mean
>Bayesian spam filters become more likely to reject MAIL FROM: it).  So the
>admins have an incentive to be careful and install the limiters.
>
>Mike

So are you implying that having rate limiters for users (combined with RMX) 
is the only way to solve this problem? But lets say that the slave computer 
in question belongs to a customer who is permitted to send large amounts of 
emails (like www.ietf.org). In that case limiters will not help either 
since the user is authorized to send large amounts of emails. However, I 
would tend to think that this would be an uncommon case.

Additionally, limiting user's email might draw some negative feedback from 
the users. I remember coming across a new report that HotMail has been 
limiting their users to 100 messages per day. I am wondering if anyone 
present knows if there has been any negative backlash from the users over 
that limit? On a paid account this might be a bigger issue, since someone 
who is paying for email might feel more entitled to have no limits placed 
on that access.

P.S. If Hotmail saw a need to limit outbound messages, then that supports 
the assertion that free email providers are being actively user by spammers. 

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

---

From: Mike Rubel <[email-masked]>
Date: Sat, 10 May 2003 21:00:37 -0700 (PDT)

Hi again, Yakov,

ys> So are you implying that having rate limiters for users (combined with
ys> RMX)  is the only way to solve this problem?

I only meant that RMX-like systems have the potential to help in the
slave-server case.  Wasn't implying anything more general than that or
maligning other proposals.

> But lets say that the slave computer in question belongs to a customer
> who is permitted to send large amounts of emails (like www.ietf.org). In
> that case limiters will not help either since the user is authorized to
> send large amounts of emails. However, I would tend to think that this
> would be an uncommon case.
[ ... ]
> the users.

Hmm, perhaps "rate limiter" was too strong a word.  I only meant that RMX
gives admins the ability to deploy a safety valve, when and where they
want to.  As a user, I would appreciate such a thing, just as I appreciate
it when my credit card company double-checks before approving an
unusually-large purchase.  Nobody's proposing that we start imposing some 
arbitrary limits on people's ability to send legitimate email.

Mike