Why does everyone want to over complicate the problem?
First 100 emails out or in are free, beyond that, there's a fee. If its too
expensive to spam, they'll stop. This, IMHO, is the only way to stop them.
Follow a telco billing model and "exchange" mail minutes. Its doable if the
ROI is there. Create a tiered service structure.
Adding more software, more hardware, and more components, won't stop it.
Cheers,
Martin
---
Martin Hannigan
hannigan(_at_)verisign(_dot_)com
Verisign, Inc.
-----Original Message-----
From: asrg-bounces(_at_)ietf(_dot_)org <asrg-bounces(_at_)ietf(_dot_)org>
To: asrg(_at_)ietf(_dot_)org <asrg(_at_)ietf(_dot_)org>
Sent: Thu Dec 23 16:34:46 2004
Subject: Re: [Asrg] Spam, defined, and permissions
But the problem with a goal of every end-user running a mail server is
that they're not generally prepared to be "always on"...
Let's consider an intermediate stage... where the user has a local POP3 mail
"server" which is ONLY used to feed mail to their E-mail client software.
That
mail server can be "fed" by a local POP3 client (perhaps running as a batch
process) which retrieves E-mail from the customer's ISP-provided POP3
mailboxes
and transfers it for further holding within their own private "mail server"
and
their own private mail boxes. (Note that in this case, they don't need to
worry
about directly receiving E-mail from network addresses, so such a private
server
will run just fine behind NAT, firewalls, or other ISP 'server'
restrictions).
Among other advantages, this allows the user to have essentially unlimited
local
E-mail addresses, and can create their own "quarantine" mailboxes (for
example)
and handle those however they like.
There are numerous freeware E-mail clients that are suitable for such use,
but
one which works (and works well in this sort of operation, as it turns out)
is
EMWAC.
...which can create various problems including bouncebacks,
Bouncebacks don't have to occur (and don't occur) in an operation like I'm
talking about.
...must keep their own servers functional which thus far tends to be very
difficult,
EMWAC is essentially about as problem-free as a program can be. Once you
get it
set up (which, admittedly, COULD be made easier) you pretty much can forget
about it. It just sits there and works.
...additionally must keep any domain mapping functional which only
complicates
matters further,
If your private "server" doesn't have to accept mail directly from sender
mail
servers on a demand basis, then domain mapping isn't an issue either. This
means that these can run even behind NAT and with a dynamic IP address.
...and must deal with all sorts of problems including spammers
and their ilk flooding their server into uselessness,
There is essentially zero additional risk of flooding compared to having
your
own mailbox at an ISP, if the mail server is not directly accessible from
the
outside. Certainly you COULD have your ISP-provided ('staging') mailbox(es)
overflow if some spammer shoves stuff into it faster than you can empty it,
but
that could happen even if you weren't running a local 'server'. And DDOS
attacks, of course, are likewise a danger no matter WHAT you're running
locally.
...managing backup servers, possibly load-balancing,
Don't be ridiculous, those are ISP-level issues but don't enter into things
for
individual private users.
...having to have roughly peak-usage bandwidth and resources or suffer the
consequences,
The "consequences" are not generally serious. At some point, stuff COULD
back
up to the sender (but that could always happen, anyhow, and good networks
have
to provide for that possibility).
etc etc etc.
But a mailbox via pop or imap is just an authentication, a lock and a
basically one or more file transfers, plus or minus, and is quite
forgiving of all kinds of subtleties.
Yes, and indeed that does not preclude transferring the mail upon receipt
into
another, private, entirely local mail server (and one that does not have to
deal
with resource limitations imposed by ISPs).
I think end-to-end for email was a nice idea in the far distant past
but it's become a dead dodo for the vast majority of customers who
would just as soon be CUSTOMERS of all those complexities I mention
rather than service providers.
Certainly there are a lot of clueless users out there, and most of those
don't
need more complexity. On the other hand, modern software design is heavily
based on hiding (and not necessarily eliminating) a lot of internal
complexity
so that clueless users can use their computers.
At any rate, I don't know that it really matters since whatever is
adopted to fight spam coming out of a forum such as this can be
utilized by, to quote one of Lily Tomlin's characters, Kings and
Queens right down to the Scum of the Earth.
Sure.
I guess the only major difference is that if we presume that anything
proposed must work in an end to end environment inclusive of, e.g.,
home users, then it would need to scale down to smaller per
transaction resources and a level of simplicity that people with very
limited interest can quickly and easily grasp (e.g., automatable to a
very high degree.)
Yes. But I don't see that as a huge problem.
Of course, then the PDP-11 and Atari/ST users will show up demanding
that their systems be taken into full account...
And they will be, possibly, but that doesn't mean that WE have to supply
their
software for them... and everything they're already (presumably happily)
using
today ought to still be able to work within the new framework.
I know, we'll wave that hand when we get to it.
Or they will. :-)
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg