On 23/12/04 03:56 +0000, gep2(_at_)terabites(_dot_)com wrote:
<snip>
Your MUA is breakling threads and quoting. Please fix.
Sorry you don't like my MUA... but I do. Likewise, sorry you don't like my
quoting style... but I don't much care for the stuff that other programs
generate (like at the top line of this reply) either. Inevitably, after
editing
quotes and removing extraneous stuff, and quoting several levels back, it
becomes nearly impossible to maintain integrity of "who said what" (and in
fact,
it rarely doesn't much matter WHO said something anyhow... I'm quoting and
referring to IDEAS, if you really care _who_ said what you can refer back to
the
archives if you want to).
Typical spam messages (once you strip the HTML garbage out of them) tend to
be 1K-5K bytes long. So even if they were all 5K, you're talking about
storing something like 200,000 spam E-mail messages (for however long the
user bothers to keep them before they finally purge them, either actively
or by simple timeout) for about ONE DOLLAR.
I however, would be looking at the network costs of accepting that data
in the first place. If you say that a message on disk is 5K and the
transactional overhead is 1K, you are looking at an increase of 5 times
the traffic by volume for spam.
I have NO idea how you made THAT leap of logic. TYPICAL [text-type!] spam
messages (in my experience, anyhow) have LARGER [full!] headers than the spam
body itself (the main exception is spams which use text-as-image and
attachments
to conceal the message content from content-based antispam filters). Maybe you
just worded your comment badly, but anyhow I'm not sure what you meant maybe.
Now consider that you are speaking of stripping a 15KB mail to 5KB, implying
that you will be accepting that 15K of traffic in the first place.
Are you talking about my proposal of discarding the HTML-burdened alternative
attachment for mail from non-whitelisted senders?
Obviously, yes, at some point (if you're accepting/retrieving the mail) you're
going to be using incoming bandwidth to retrieve it.
And for any non trivial mail server, you are looking at massively
expanding CPU capacity to deal with the traffic volume (hint, mail
servers are optimised for disk and memory access, not CPU).
I fully agree that one of the goals should be to reduce total aggregate
bandwidth wasted by spammers. Discouraging them from sending large,
HTML-burdened, and/or attachment-laden mails on an unsolicited basis (by
reducing the likelihood that such mail would ever be delivered and read) would
help to achieve that.
So what's with all this crap about it being so onerous to "accept and store"
this stuff?
The store part is bad enough. The accept part is where the really scary
and costly things happen.
Agreed. The bandwidth probably costs more than the disk storage costs (and the
disk storage costs are 'recyclable' whereas the bandwidth cost, whatever it is,
isn't recovered for reuse next week/month/year).
To draw an analogy to information security, your ideal goal is to
prevent malicious traffic from getting in as far down the stack as
possible. You do not want to allow traffic in and hope that malicious
traffic is caught and rejected by your IPS, you want the firewall at the
edge to stop it. Apply the same logic.
I agree that, ideally speaking, one would like to truncate unwanted mail as
many
hops as possible back in the direction of the sender. The real question is
whether that is as (a) practical, (b) incrementally implementable, and (c)
cost-effective given the added complexity.
As for TEMPORARY E-mail storage (say at a POP3 server), mind you that it is
the ISPs themselves who create that monster by trying to discourage users
from setting up their own POP3 servers (which in fact is extremely simple
to do, if you have a machine which is online and running essentially all
the time).
The "running all the time" is what /users/ down't want to do.
SOME users would like to do that (*I* would, for example), so it's ludicrous to
generalize like you're trying to do. Those users with cable or DSL
"constant-on" connections, and whose systems are up essentially full-time,
could
easily enough host simple POP3 servers.
Agreed that not everybody wants to do that, but anyhow it's fairly silly for
ISPs to cry about how it's so hard/difficult/costly for them to provide
adequate
POP3 services for their customers, and in the same breath tell (okay, maybe
more
advanced) users who _are_ willing to take that on that they are FORBIDDEN from
doing so.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg