Subject: [Asrg] Spam Flitering vs. Spam Rejection

From: "Justin B. Newman" <[email-masked]>
Date: Fri, 9 May 2003 23:08:57 -0500

Greetings,

I write today as the CEO of a small, independent ISP that provides 
dialup services, majordomo hosting, as well as POP-3 hosting.  We 
have customers that make use of all possible combinations of the 
above services.  As such, I have several interests in reducing the 
flow of spam:

1.) Customers don't like it.  Even more, customers like having less of it.
2.) I personally don't like it.
3.) It makes my customers' legitimate mailing lists (purely opt-in, 
typically discussion lists) go through weird hoops to get mail 
delivered.
4.) It forces me to take a specific interest in my customer's mailing 
list content.  I must pay enough attention to turn down their 
business / disconnect their account when they engage in spamming or 
... just as bad ... make my gut tell me that they will.  (Getting 
blacklisted is the kind of thing we have nightmares about. 
Therefore, we must sometimes turn down possibly legitimate business 
in a "protectionist interest.")  Often, I'd really rather not know 
what my customers use their mailing list for.  (Customer privacy.)
5.) Bandwidth / server utilization costs.

I'm sure there are some more reasons I'm not thinking about.  We had 
more tornados here in Kansas last night, so my brain's perhaps a bit 
fried.

As I see it, spam can (theoretically) be dealt with in several ways:

1.) We as folks running outbound SMTP services can assure that our 
servers can't send spam.
2.) We as folks running inbound SMTP services can reject spam at the 
point of entry.
3.) We as folks delivering mail to customer's POP/IMAP accounts can 
initially accept the spam, then filter it out for the customer.
4.) Customers can filter the spam out themselves.
5.) Combinations and varients of the above.
6.) Laws can deter folks from spamming.

I'm sure there are more ways.

Having discussed spam with many other independent ISPs, I can say 
that we are all concerned about the problem.  The most common 
response is a combination of all of the above mechanisms.  Here's 
what appears to be most common:

1.) Open relays are taboo.
2.) Port 25 blocking.  (Not universal.  Controversial.)
3.) Limited rejection.  (Very limited.)
4.) Filtering:
- SpamAssassin-style filtering seems to be the most common.  The 
theory is (as most of you likely know), that we give mail "points" 
for various characteristics.  This includes blacklist checking, 
content analysis, header validations of various sorts.  If RMX (or 
similar) were to happen, most of us would likely initially deploy it 
here.  Valid RMX = -1 point.  Invalid RMX = +1 point.  No RMX = no 
change.  (Or whatever.)  There is some threshold (posibly 
configurable by the customer)
5.) Providing customer tools: POSTINI and C/R systems seem to be the 
most common.
6.) Various schemes for authenticating "authorized" mailers.

#6 seems to be most problematic.  Clearly the "travelling salesman" 
problem is not minor.  We [Binhost] deal with it by providing POP 
before SMTP services on our SSL-enabled ports.  Our dialup customers 
are authorized to utilize our SMTP server by the RADIUS server.  Many 
independent ISPs [Binhost included] offer nationwide dialup by 
contracting the service of a wholesale dialup provider, such as 
Worldcom or Q*West.  The general industry practice is to add the 
entire national network IP range to your SMTP-server's "relay from 
these IPs" list.  [Binhost refused to do this for obvious reasons.]

All of this said.  Now you know a little about me, how I operate, and 
how I look at spam.

When I look at RMX, C/R, Vixie's proposal, etc, I look at it from the 
point of view of, "how would this fit into my filtering scheme?" 
While I know that filtering does not really deal with the bandwidth 
or server utilization issues (perhaps it does deal with mail storage 
space issues)  it seems [to me] to be:

a.) the easiest method to implement (I don't have to touch my SMTP 
server or my SSL-ized SMTP server)
b.) the least method apt to reject "legit"  mail (multiple rules as 
opposed to a single "lithmus" test)
c.) the easiest spam fighting method to update and change
d.) the best method for dealing with phased rollouts and 
semi/non-standard kinds of things. [See item b.]

(semi/non-standard kinds of things?  Example: Rejecting mail for 
which there is no / a bad reverse on the MX.  Why is this 
controversial?  Because a _lot_ of legitimate servers (particularly 
in government and education namespaces) fail this test.)

My comment on RMX, etc., is: Let's standardize it and put it into 
use.  It's _one more tool_ for me to use when filtering.  It may not 
be a full solution, but ... it'll help me help my users.  At the end 
of the day, that's where it's at for me.

Yours,

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