ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spam, defined, and permissions

2004-12-25 18:00:31
push the message storage to the user end (where it probably ought to
be)

Why is that?

1) Scaleability. There is far more aggregate processing power and
aggregate
disk space available within the user community to store messages than
within any of the ISPs own data centers.

While this may be true, 

I think it's almost CERTAINLY true, and probably by a LARGE factor.

...such an approach might *consume* more of these
resources (and bandwidth) than would rejection upstream. i.e. you'd have to
do a lot of figuring to convince me that n GB at end user is cheaper than m
GB further upstream, given that we know very little about the values of n,m
.

Rejection upstream saves sending the data through the Net but I think the 
evidence is NOT at all in that:

  1)  we can successfully define a universally agreeable standard and get it 
adopted in a timely way;

  2)  it doesn't suit recipients BETTER to give them accessible copies of ALL 
their mail, including the stuff that was quarantined/rejected (which means that 
in effect, one must (at least be prepared to) transfer the spam too anyway).

2) Cost. Both disk space and CPU cycles are probably cheaper at most
end-user machines, too... most users probably have cheap(er) IDE disk drives, >

Well, yes, but this (and the bandwidth) becomes an extra cost of mail
service. Is this what end-users want? Would they pay (perhaps more) for
something else? 

Right now, I think that they want to be rid of the annoyance of having to deal 
with spam, spoofing, viruses, worms, scams, and phishing.  We could spend 
another five years or ten years debating how to implement that in an ideal way 
(and it's a moving target!);  meanwhile the users get angry, legislators look 
at 
(usually stupid) legislative remedies, and halfassed stupid crap like SPF and 
other DNS-based "solutions" (that aren't, really) get implemented which mostly 
just screws things up further.  I'd rather see us come up with something that 
would make a major, visible improvement and do so quickly, and which users 
would 
feel like they had meaningful control over.  If we don't do it here, and soon, 
we'll end up coming up with the "nice" and elegant solution that the world has 
already passed by.

Also, see the point about *consumption* above. It's all
very well hypothesising about costs, but some consideration of potential
benefits would go well here. Remember that the MTS is supposed to offer
service to a very wide range of end-user hardware (and pockets).
  
Sure.

3) Responsibility. 

Obviously attractive to an ISP in certain circumstances, but it's not just
the ISP view we're considering here.

Right.

4) Control. 

Indeed, but this isn't an argument against user control being implemented
upstream.

Right again, but then (1) the user has to pay OTHER people and OTHER systems 
(at 
a higher cost, probably, than his own) to do (hopefully) what he needs;  and 
(2) 
we're likely to spend years defining a one-size-fits-all solution (to a 
moving-target problem) which will end up never converging on something that 
everyone can agree on (we've seen a lot of that going on here already).

It seems to me that your position amounts to saying that we (the community)
don't have a spam problem, end-users have a spam problem.  Is this right?

Certainly the BULK of the problem is the problem that end-users see, including 
getting their own machines infected and thus greatly contributing to the 
problem 
net-wide.  I don't think that the greater Net-wide spam problem has a PRAYER of 
being solved until we solve the problem at the end-user level (including 
notably 
the virus/worm/spambot/zombie problem).


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