Greetings - I have been reading ASRG for approximately two months now and I
am alarmed at the direction the recent discussions have been taking. It
seems the list has deteriorated into a series of ad hominem attacks with
precious little useful discussion. I have limited experience with technical
discussions lists (thus the Subject line :) perhaps this is just a mandatory
phase that such lists go through.
As I haven't posted lately just some quick background. I am the System
Administrator for a small local ISP managing in the low several thousands
mailboxes. As several people have pointed out the margins in the ISP
business are *EXTREMELY* low leaving precious little excess resource to deal
with what I find an alarming and intractable problem that threatens our
business. I am *NOT* a Unix (Linux actually) guru, simply a frustrated and
overworked computer professional attempting to deal with an *VERY* resistant
problem. While I have the ability read documentation and install software
(most times :-/ ) I do not have the desire or ability to create my own
software, thus I am forced to use solutions that others provide...primarily
for free.
I will not attempt to divine Alan DeKok's motivations for his posts however
I do have to agree with his assertion that SMTP is fundamentally flawed in
its current incarnation. Many legitimately useful features used by innocent
parties are also abused by the spammers to deliver their crap. This, IMHO,
is the core of the problem. Folks don't want to give up the flawed features
that they legitimately use in order to deny their use to spammers. Unless
this position changes I do not see how this group can either solve or even
reduce the problem to manageable levels.
I have read some interesting proposals (RMX and Greylisting spring
immediately to mind) which is why I am still subscribed to the list. One
thing that I have found somewhat alarming in some of the proposals is the
amount of "state information" required to be maintained on the mail servers.
An example of this would be the triples (sender/receiver/transmitting IP
address) though I find this state information to be less troublesome as it
is self generating and has a limited lifetime. While there are serious
privacy issues with such things as sender whitelists my practical concern is
I *REALLY* don't want to be responsible for maintaining a backup of this
information when (*NOT* if) the mail server fails. I don't see maintaining
whitelist information/sender keys on the client machines as much of an
improvement. My user base consists primarily of casual home computer
users/small business owners who have *NO* conception of system
administration issues such as backup let alone how to accomplish such a
task. My approach to spam amelioration has taken the network abuse
approach. I am using rDNS on my servers and block approximately 75% of mail
connection attempts (on the order of 150,000 per day) How many of these are
"legitimate" connections I really couldn't tell you. I do know the amount
of spam that I receive (and I have several spam prone addresses, mostly
role accounts or addresses that appear on our website) has decreased though
the effectiveness of this measure is significantly less than it was a year
ago during our last attempt. Based on customer complaints my sense is that
our little session of DNS police has reformed the more responsive providers
and the customers whose correspondent's provider was less than cooperative
have cancelled. I did not take this step lightly, it was choice between
having an at least useful mail system and fielding customer complaints on
double digit delivery times. As part of our philosophy of being a good
Internet citizen we use virus scanning on all of our mail servers. While
this does reduce the possibility of our customers being a source of
infection it also carries a considerable burden in sending and receiving
email.
This last statement brings me to the features that I am looking for in an
anti-spam solution. The most important requirement is that the solution is
effective in the SMTP phase. Once my server has received the /n./n it has
committed considerable resource to attempt to deliver that message. The
second most important requirement is that the solution makes the
accept/reject decision based on firm, indisputable criteria...ie this server
*IS* who it says it is, this sender can receive the bounce should the
message prove undeliverable...basically the sending machine does not have to
lie to get me to accept the message. I will, most likely, be implementing
some DNSBL block lists, open proxies have the unfortunate characteristic of
having valid rDNS (maintained by the provider) and are my primary spam
source. I am also intrigued by DCC as the answer to the question "Has this
message been sent to 30,000,000 of my closest friends?" is apropos to an
accept/reject decision. I am not a fan of content filters as we, by policy,
provide an unfiltered internet connection. There are just too many problems
(again IMHO) with examining content to entrust the machine to make a
"fuzzy" decision. As I stated above the solution *MUST NOT* require
maintaining a lot (a judgment call admittedly) state information. When my
server fails I want to be able reload it with the current version of my MTA
(postfix, if you're curious), MDA (cyrus, again, if you're curious) and
virus scanner and be back down the road. One of the reasons I found
Greylisting to be interesting, despite maintaining state, is the that state
information is self generating. A couple of days after the catastrophic
failure most important state information would come back on its own. There
would be some pain involved, but that is a given after a critical machine
failure.
I apologize for the length of this post and my simplistic viewpoint, however
it is the only one I have. I am hoping that this post will provide the more
capable and more intelligent members of the list with an idea of the
requirements/desires of administrators that cannot or will not "roll their
own" solution. As a final thought we did actually consider stopping doing
email altogether. Solving or, at least, reducing the spam problem to a
nuisance level has become a "revenge thing" for me, for better or worse. I
am absolutely astounded that I have difficulties reliably running a few
thousands of mailboxes with more computing horsepower than it took to put a
man on the moon. There has to be a better way and my hope (which is still
there:) is that way will come from this group.
Regards
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg