ietf-asrg
[Top] [All Lists]

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

2005-01-02 18:15:17
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


<Prev in Thread] Current Thread [Next in Thread>