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

From: [email-masked]
Date: Fri, 24 Dec 2004 00:34:46 +0000 (GMT)

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Fri, 24 Dec 2004 18:50:48 -0500

How is this any different than just having an imap/pop (particularly
pop) account at an ISP?

Put another way, could you re-state the problem this is trying to
solve.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*