ietf-asrg
[Top] [All Lists]

[Asrg] Spam Flitering vs. Spam Rejection

2003-05-09 21:08:53
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>
  • [Asrg] Spam Flitering vs. Spam Rejection, Justin B. Newman <=