Subject: Re: [Asrg] Spam, defined, and permissions

From: [email-masked]
Date: Sat, 25 Dec 2004 02:48:25 +0000 (GMT)

> On 23/12/04 03:56 +0000, [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 24 Dec 2004 22:24:38 -0500 (EST)

> 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).

How much of that is due to you quoting only the first line of a
paragraph and making the rest look like they were written by one
person up the stack?

> just worded your comment badly, but anyhow I'm not sure what you meant maybe.

As far as the smtp protocol is concerned, the email headers are
treated just like the email body: part of the DATA segment.  The
transactional stuff that occurs earlier is EHLO, MAIL FROM, RCPT TO,
and stuff like that.

> reducing the likelihood that such mail would ever be delivered and read) would 

In this universe, discouraging spammers doesn't seem to cause them to
send less spam.

> easily enough host simple POP3 servers.  

Oh, great.  Yet another way for them to serve as zombies for spammers.

Seth