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

From: "Hannigan, Martin" <[email-masked]>
Date: Sun, 2 Jan 2005 20:19:53 -0500

Hmmm.. Depends. If you're buying bandwidth at $50US per 1mbps, the
aggregated cost of actual bandwidth is negligible. (The bigger nets are
buying this low, and lower). 

The tier 2 markets are more likely to be measurably impacted, but this is
where most originates,

In order to correctly calculate cost of spam, you need to cost the
collateral damage as wll ie call center, people resource, etc.

-M

---
Martin Hannigan
[email-masked]
Verisign, Inc.

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Sun Jan 02 17:07:27 2005
Subject: [Asrg] Re: Spam, defined, and permissions, and SICS

>> First off, if the E-mail is stored at the recipient end (where it
> makes sense to keep it, and process it, since that's where the bulk
> of the processing and storage resources are),

> Then it has already consumed last-mile bandwidth, 

True enough.

> ...which can be the most expensive part of the process, 

Well, in some cases, yes.  I'd argue that the most expensive part of the
process 
is the time of the recipient, having to deal with the spam.

> ...and is often the limiting factor.

Again, on dialups, maybe.  Spam bandwidth is a pretty small percentage of
(say) 
a cable connection, or a DSL line, or other more modern forms of
connection.... 
even compared to other typical uses like graphically-rich Web sites,
streaming 
audio, or streaming video.

>> Typical spam messages (once you strip the HTML garbage out of them)

> Who strips the HTML?  

I think that the best way is for the recipient's machine to do that, since I

believe that's where the recipient will have the greatest control over the 
process, where the processor and storage resources are most available, etc
etc.

Obviously there ARE other places where it could be done, but I'm not
convinced 
that it's ultimately worth the loss of recipient control and additional
general 
process complexity to do it further upstream.

> Do ISPs reject email with HTML?  

Within the context of a user-specified, fine-grained permissions system
(where 
individual expanded rights and trusts can be assigned to given senders by
the 
recipients) then sure, I wouldn't see a problem with that.  Obviously it's
not 
something that you'd do arbitrarily or unilaterally.  Power tools can be 
dangerous if they're abused or misused.

> In that case, why can't they reject other email that looks like spam
(however 
that's defined, preferably user-definably)?

I think they probably COULD.  Again, the issues include (1) whether the 
recipient has adequate and finely-enough-grained control over the process,
(2) 
can specify different rules depending upon who the sender is, and (3) the 
recipient should have the ability to go back (at a future date and time) and

look at 'quarantined' mail that they later decide they might want to
reconsider. 
There should be a simple, straightforward process that they can invoke to
use 
quarantined mail (or delivered mail, for that matter) as a template for
types of 
mail they do (or don't!) want to receive in the future from the same sender.

Generally, item (3) works to the disadvantage of ISPs, since usually they
don't 
want to archive quarantined/spam mail.... they tend to moan and complain
about 
even holding the mail the user WANTS but just hasn't gotten around to
collecting 
yet.  But as long as the user's hard drive is big enough, item (3) isn't
usually 
a big problem if it's kept on the recipient's own system.

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

> But is considerably trickier if you have dynamic IP, 

Oh, it's a little harder, but certainly not a big deal if there's adequate 
software support for it.  A lot of that can be made pretty much transparent.
And, alternatively, a user process can poll (POP3 or http: or otherwise) a 
temporary storage site somewhere else on the Net at times of their
choosing... 
and then transfer the mail to their OWN local POP3 server.

As long as the reception of E-mails is multithreaded and happens in the 
background, so that users don't have to WAIT while it's coming in, I don't
think 
that even dialup bandwidth is likely to be a huge issue (as long as,
clearly, 
the machine is online enough that everything comes in and is there by the
time 
the user is ready to read it!)

> ...or you want to have your machine online only when you want, 

Perhaps it's just because I've been in the computer business as long as I
have, 
but I think it's truly bizarre for people to turn computers off other than
"when 
I want to use it".  It's like those folks who carefully pack away their
blender 
into its box back to the top shelf of a kitchen cabinet... and thus end up
using 
it on (predictably) only on rare occasions.  You get much more use (and
value) 
out of a computer if it's available all the time, and ready NOW when you
want to 
check something on it.  (Not to mention, of course, those of us who listen
to 
streaming radio and such during much or even all of the time we're online).

> ...or you just don't want to eat the power bill to do what should be your 
ISP's job.

Portable computers use relatively little power.  If you can afford to buy
the 
computer, you ought to not have a problem with the comparatively small
amount of 
power it uses.  And of course, if you're living in the part of the USA where
you 
are heating your homes this time of the year (and especially if you're using

electric heat to do so!) then the incremental energy cost to you to run your

computer 24/7 is essentially zero... because the electricity it uses would 
OTHERWISE be going into your heating strips, so you're paying for it, one
way or 
the other.

>> But even if you don't have a fulltime POP3 server, it's fairly
> trivial to have a small background process running (as I do here)
> which empties POP3 mailboxes every minute or two.

> Which still assumes you have a machine always on with a full-time
connection.

Sure.  But that's NOT particularly difficult or costly, anymore, in the
overall 
scheme of things.

>> But then too, it's TRULY difficult for me to feel terribly
> sympathetic to an ISP who charges $80 a month for high-speed
> connectivity and then grouses about devoting even $0.25 (total, not
> per month) for 250Mb (peak!) of mirrored disk space at a POP3 server
> to hold that customer's mail.

> You've never run an ISP and priced storage, have you?

If the customer is paying for it, hundreds of times over, and willing to do
so, 
it's ridiculous for the ISP to want not to let him have it.

[snip]

>>> That doesn't work: the spammer will get a shill to sign up with your
>> ISP and claim he _wants_ the spam.

>> That's ONLY a problem if the decision is made by the ISP and applies to
all 
> recipients.

> Allowing users to write their own filters leads to annoying problems.

Annoying for the ISP, perhaps, and that's a good reason for the filtering to
be 
done at the recipient's end, where they see the value in the filtering and
where 
they feel more in control of the process.

> Setting up systems to safely allow users to choose their own filters
tends to be expensive, and is a non-trivial issue.  

I disagree;  again, it's more complicated if the ISP is trying to do it, but
if 
the process is done in the recipient's mail client (or something reasonably
well 
linked to that, perhaps a plugin or something) there's nothing that says it
has 
to be difficult, cumbersome, or costly.

Good applications programmers solve FAR more difficult applications design 
problems every day.  Something like this is HARDLY rocket science.

> It's not so bad for a small ISP with clueful users; but I wouldn't want to

even think about AOL's customer support issue if they tried it.

Dunno, they decided to provide anti-spyware, anti-virus software to their 
customers.  Yahoo provides spam filtering, and theirs works reasonably well
and 
presumably hasn't been a support nightmare.

A lot depends on how the filtering is presented to the customer, and that's
a 
matter of good application design.  But again, it's hardly like it's 
theoretically a challenging problem to solve. 

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

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

---

From: "Hannigan, Martin" <[email-masked]>
Date: Mon, 3 Jan 2005 02:10:26 -0500

Statistics?

-M<

--
Martin Hannigan                         (c) 617-388-2663
VeriSign, Inc.                          (w) 703-948-7018
Network Engineer IV                       Operations & Infrastructure
[email-masked]

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Devdas Bhagat
> Sent: Monday, January 03, 2005 1:10 AM
> To: [email-masked]
> Subject: Re: [Asrg] Re: Spam, defined, and permissions, and SICS
> 
> 
> On 03/01/05 01:07 +0000, [email-masked] wrote:
> > Well, in some cases, yes.  I'd argue that the most expensive part of
> > the process is the time of the recipient, having to deal 
> with the spam.
> 
> Hint: Spam is a global problem. The recipient's time might be 
> expensive
> in the USA, but it sure isn't expensive in India. On the other hand,
> bandwidth is far more expensive. When your average recipient makes 200
> USD/month, and the cost of recieving spam is half that for significant
> spam volumes, the fiscal mathematics suddenly leverages in favour of 
> stopping the spam at the edge.
> 
> Devdas Bhagat
>