This item text has been erased.

40 responses total.

This response has been erased.

okay, so apologies for the constant change in status. I think there is 
a very reliable and hassle free way to ensure E-mail and I'm willing to 
do most of the work (take me about 3 months because I know next to 
nothing about e-mail [postfix]).

It works like this: veek creates a white-list of people he wants to 
receive mail from; this file is only readable by the mail-server 
(postfix). Every time the mail-server receives a mail (the whole mail 
is not downloaded, just the e-mail-address), it checks to see if the 
sender is in the white-list of the user. If yes, the mail is delivered. 
Since it's very difficult for a spammer or a troll to know who your 
contacts are, he cannot send you junk-email as grandmaX@yahoo.com.

Incoming SPAM from random spammers will/should drop to 0. Outgoing SPAM 
will be rate-limited to 5 emails/day AND only for validated users. In 
fact, you can create groups of users with different email quotas - so, 
someone who creates 500 accounts and tries to send 10x emails.. that 
won't work. 

The policyserver.perl script uses a Unix Domain socket, so you won't 
have any denial-of-service problems - only Postfix will be able to 
communicate with the policyserver.
---------------

Please consider this carefully and let me know if you are okay with the 
concept of white-listing and keeping your contacts sekret. If you tell 
evil-troll that grandmaX@yahoo.com emails you, then he could forge 
email as grandmaX and waste our bandwidth by flooding you with junk. I 
try to solve this problem by permitting the user to turn ON/OFF their 
INCOMING and of course, once you know who initiated the flood you can 
kick him out by removing him from the permitted email users list.

The worst case scenario I envision is that Grex which has no mail, will 
start having very flaky mail.. 

For staff: http://www.postfix.org/SMTPD_POLICY_README.html
Also check out Postgrey, and the sample Perl code at the bottom of that 
link.

Basically after MAIL FROM: RCPT TO:, postfix contacts the policy-server 
script and sends it data gathered.. your script has to read the users-
whitelist (kept in a special directory) and tell Postfix if the mail is 
OK/REJECT. When it reads the Wlist, it can also read the first line to 
see  what the users in/out mail-rate is and check a timestamp..

The trouble comes with local mail ('mail' - which is written directly 
to the queue-file). I spoke to the Postfix guys and what they say is 
that, just restrict mail to root/etc and force users to use SMTP - so 
both IN/OUT get processed by policyserver.

The are I know nothing about is: bounced messages etc (postmaster, 
MAILER-DAEMON) and how to prevent spoofing of that?? but they say it's 
okay can be done (the client IP is passed :) ) but spoofing via troll-
boy on Grex???

I think that mechanism might be useable in some way on grex, but I'm not
so sure a white list in the simplest sense is the way to go.  I've done
some experimenting with a white list on grex on a second account using
procmail, and found that there were a number of things I had to deal
with that your suggested solution would need to take into account.  For
one, I didn't do it on my primary account (unicorn) because I felt that
a staff account should be able to receive mail from anywhere.

For another, I wanted to be able to receive mail from anyone I sent
mail to without having to go through the extra step of adding them to my
whitelist.  I think most people would consider that to be a real hassle.
My solution was to have procmail check for the From address in three
places: my address book (mutt mail aliases file), a special whitelist
file, and my sent mail folder.

Another problem I ran into was that if I subscribed to any mailing
lists, the From address might be anyone on the list, and not only would
it be an unnecessary burder to add the whole member list of that mailing
list to your white list, it may not even be possible to obtain that list
for all lists you might subscribe to, not to mention that the member
list is likely to keep changing as new people subscribe and others
unsubscribe.  My solution to this was to find something else in the
headers, put there by the list server itself, to filter on.  This
wouldn't be doable with your solution because those headers aren't
available until the entire e-mail has been accepted, since the entire
message, both headers and body, is received at the same time, during the
DATA portion of the SMTP transaction.  I'd hate to tell people they
can't use grex mail to subscribe to mailing lists.

That's not to say that we couldn't solve much of our spam problem using
Postfix SMTP access policy delegation in some way.  I'm just not sure
whitelisting is the way to go if we want to keep e-mail useful for
everyone that wants to use it.

Hey Chuck :) thanks for replying - I thought that this was going to die 
a cold clammy death *glares at the lazier members of the pack*

1. My whitelist format is something like so:
10mails/day 5emailsSent timestampOfFirstMailSent ON/OFF *
xyz@yahoo.com
grandmaX@yahoo.com

if OFF, reject everything; if ON process whitelist. The * is for those 
guys that want everything (greedy hogs). The first line is admin 
created.. so.. if you want everything just give yourself a *

Solves both the mailing-list problem and the staff-get-all-mail thing. 
'course chad, bless his heart, could spam the heck out of you.. but for 
that stage2.

2. You need SASL (SMTP auth) for mail being generated on cyberspace 
because wonder-boy is bound to try: mail from: mary; rcpt to:remmers.

So essentially I see: policyserver.pl (1/2 days wrk for a competent 
perl programmer [not me]) 2hrs for suid-user-whitelist-thingy, a SASL 
map-file-generator to map, email to login and password-thingies (maybe 
we can avoid this because the email is the same as the login anyways).

3. The rest of ze time for horrible screw ups and testing (the way I 
code, which is seldom, there will be no shortage of bugs). Actually I'd 
be very grateful if someone else coded this baby for me :P because I'll 
never live-down any big screw ups.. my reputation is umm.. not very 
sterling in such respects.
------
Anyway, this is like a long-term plan.. if everyone is okay with the 
idea of white-listing (WE HAVE 0 MAIL right now for crying out loud! I 
can't believe ppl are quibbling about not receiving enough mail! 
*glares at Chuck and shoots fiery flames*) Ahem! anyway.. so in 
principle.. would this be okay :p Please! .. Pretty please! I require 
cool email! I'll test on Linux.. 3 months.. there may be no Grex in 
that time so you may never have to make that decision!

I could also host grex mail like I do m-net's and there's be no work
involved and, while not setup for this whitelist stuff, I've not had
much trouble with spam or viruses...same sasl-auth is required to send
mail.  The only thing that's special that'd be required is people would
need to create their accounts via a web script, though a shell method
could probably be created. I just haven't worked on that on m-net.

well.. it's a cool offer, but.. what if you install a nasty password 
logger and we get the law suits. Sue me, I'm a pauper (and long 
distance doesn't work all that great anyway) but *ahem* certain fat-
cats within range of the toasty flames.. aren't quite likely to err.. 
purr.. :p

Anyway, the hard part is not perl and the policyserver.. it's getting 
SASL to work with our password file. basically from what I could make 
of it, there's plain text SASL (sent over encrypted TLS/SSL) so the 
server(Postfix, saslauthd) sees your plain-text password.. and then it 
authenticates using PAM - it sounds very complicated.. too many daemons 
in-between for Daltenus to toy with, but it's secure.

the easy way is maintain a separate mail-passwd file that postfix can 
read.. but i'm not so keen on this.. the first method allows ppl to 
really use cyberspace for email from anywhere with bandwidth limiting 
quotas (size field is also sent).. but it looks scary.

resp:7: I don't see that as being any different really than any other
root on m-net or grex.  anyone could install a password logger, hell
anyone could send spam or email from grex or mnet as anyone for that
matter.

Everything you're discussing seems like a ton of work for little or no
real benefit for most users.

I'll be doing most of the work initially.. how much time can staff 
spare once it's ready to install - 2hrs?? How much time to maintain/
month?? It's not like we are on a clock here.. right now we have 0 mail.
with the new proposal.. given certain reasonable conditions.. spam=0 
and internal-spam=0 (cdalten type hosing) that's still subject to my 
own limited knowledge on the subject!!

basically, all i'm asking you to quantify right away is: how much time 
can staff spare for maintaining mail and installation of the new 
proposal?? (once the proposal is ready)

I'm okay with your proposal(as a lay user) if you can swing it, but 
until then is this okay???

  
veek - i;ve been reading htis .. wans;t gong to die a cold clammy death
but i ;m not a coder so about al i could do is cheer from the siddelines.
  
however ... i thik it woud be well wirth trying ... expecially since
yo ovlunteered and this a a volunterer system. enthusiaasm and will adn
teh sense of accoplishment really go a long way.
  
and besides, you;ll be a better coder afterwords with someting else to 
show for yourself, which is a GoodThing (tm) imo.
  

also one one of my other accoutns, i can try it out in my dumb-user mode.
  

hey TS, dank you. Purrl makes most things easy :) :) *groan* now if 
only my flu would disappear.. i fell sick *duh*

  
on qustoin/statemnt at lsat night;'s baord meeting was that if this were
to be iplemented, that it wouild be -system wide- w/o exception.
  
a complete and toatl filt er for -everyone- is not necesarily good.
 
 other sites have individually configaurable filtering in addition to the
segregation of wht the 'system' thinks is spam/etc. 
  
if that arrangement is avaialble with what you prppoose, i could suppport
it. it might mean two mailboxes, one: spam from system filter + pserosonaly 
filtered and, two:  email that passed both sets of filters.
  

reaction(s)?
  

veeks suggesting some totally custom-written filter solution that would
be configurable for each individual user, basically with whitelists
and/or blacklists of users to allow to email you.  My thought is that
this is something that's custom made and could be a pain to troubleshoot
on a system that already has a hard time getting things fixed.  Once
it's implemented and veek says 'it works for me!' I question who will
track down issues where people say 'i'm not getting my email!' and 'how
do I set this up?'.

Isn't this already built into postfix?

the ability to do it is, but he's talking about writing a custom filter
to do parts of it with the policyd functionality.  at least, that's how
I understand what he's talking about doing.

Re #12: yup it's system-wide but configurable on a user basis. There's 
no system-wide blacklisting and 2 inboxes.. instead, anyone not in your 
white-list is REJECT-ed UNLESS staff has given you permissions to get 
ALL mail.. in which case you can have 2 inboxes and blacklisting.

Re #13: we could always turn it off and go back to no mail if it's too 
much of a pain. I'm okay with anything so long as we get mail.. it's up 
to you guys to decide what you'd like to try. If the board is willing 
to migrate email to tonsters box.. that would be the easiest and 
quickest. I don't think the current proposal is more complicated than 
installing postgrey/policyd.. worst comes to worst we shut it down.

What I would like is an option to to put an e-mail address in a filter  
while reading e-mail. It shouldn't require setting up a separate filter 
file. 

  
one way to do that .. even now .. is  ctrl-z (suspend) add whtaever
to your filter and tehn   fg  (go back to previous activity) and
contimue apace .   however, separate filter files, white/black i
strognly suspect are necessary no matter what ... but i could be wroing.
  

TS, this solution is not meant to be perfect. It's just meant to turn a 
totally imperfect solution into something that is slightly better.

What whitelisting implies is that: If a stranger (good or bad) tries to 
contact you on cyberspace it will be bounced because we have no way of 
telling for sure if he's good or bad. There are ways to give you more 
control and permit strangers to contact you - like getting him to add 
himself to your whitelist, prior to mailing you, the way Jan has done 
(via the web).
http://unixpapa.com/white.cgi Which is why I wanted a more personal web-
URL.

If we permit blacklisting, we'd still need SASL for outbound so it 
would stop/rate-limit SPAM originating from Grex BUT it does nothing 
for incoming SPAM which could fill our mail queue??

Re #18: how about a script that does all that for me? Anyway, I didn't mean
that there isn't a filter file - there has to be - but that I don't have to
do the writing to it. 

that you could :) basically it should be possible to parse your Pine? 
address-book for email addresses and just dump everything into sekret 
whitelist. The reason I'm emphasizing this is because you got to 
understand one thing.. if you receive mail from ID: 'wife@yahoo.com' 
AND if someone who dislikes you gets hold of this email-ID, well he 
could fake mail and hose your INBOX. If there is a quota implemented on 
messages received/day (there will be) then legit mail will bounce as a 
result.

  
yeh, well, the risk of taht spam is someting we'd ahve to live with.
  
imo, extermenly low probablility, 

Are there any further comments or discussion of this proposed whitelisting
solution?

  
i iike veek;s ideas --- fwiw. creating an ooption is hte only bugaboo
that could arise, imo.
  

Whitelisting is not necessary.  Grex should simply do away with the 
mail server altogether.  It is clearly not necessary for Grex to offer 
free email anymore.

It's not /necessary/ for us to do anything.

Okay, so what would be some services to offer that Grex users would
appreciate?  

In my opinion, even though e-mail is available elsewhere, it is still
very handy for communicating with staff and others when on Grex without
the need to go elsewhere to send a message. Having people go elsewhere
to do things is apt to mean they get in the habit of not using Grex for
anything.

  
re 25 . sorry richard , your blineders are too tight ... grex actualyy
does need to offer email. it is not necesary, howeer, for yo to suggest
sttrangling grex services ... and grex,.

I'd be curious to know why grex NEEDS to offer email.  m-net survived
for several years without offering email and few people complained.  I
brought it back up a few weeks ago and so far over 60 people have signed
up, so there is a desire to have an address, but I don't think it's an
essential component.  That said, I agree it's a nice thing to offer and
that's why I've offered to host email similarly.  veek has offered
another method, which while it's not the method I'd use, I can't fault
him for wanting to do it that way and it's another option.

perhaps grex could simply eliminate offsite email.  Maintain email for 
communicating betweem users of this site only.  surely ts that is the 
only need for grex to offer email to communicate with its users.  
please do tell for what other purpose grex must offer email?

1. Guy who wants to learn UNIX, check mail headers, telnet port 25, 
type commands, and try the various Postfix commands.
2. DIY guy has a bunch of friends in the DIY community that he wants to 
keep in touch with BUT doesn't want to create a Yahoo account - he 
invites them over to Grex and uses party, bbs and.. grex mail to keep 
in touch.
3. Free publicity for Grex. People exchange email ID's all the time and 
that clues other ppl in.

  
re 31 .. not only what veek said, grex is a safe site for captive nations.
  

resp:32 That's simply not true.  If a foreign power wants to get root on
grex and read the emails of one of their nationals, they'll find a way.

The reality is that Grex doesn't *need* to offer email.  But we've managed
to scale it back enough that it's a relatively low-bandwidth thing and I'm
not sure I see any harm in having it available as an opt-in (which it
basically is now).  As far as whitelists go, I believe the current spam
assassin configuration already allows for that, no?

Spamassasin would entail accepting the whole email and then white-
listing it, unless you use a system-whitelist. Also, what about 
outbound flood? The postfix-policyserver thingy rejects much earlier in 
the game (just after the connection is opened and after the rcpt to) I 
vaguely remember ppl saying that email was turned off because SPAM was 
taking up bandwidth (and we were using spamassasin back then). 

So.. the current status is that we have full mail access (send to 
Yahoo, receive from Yahoo, send local email), but ppl have to ask for 
it? Who do they have to contact for e-mail to be enabled? Staff? 
staff@grex.org??

Again, all this is because if we invite a few ppl in here (once 
everything is ready).. I don't want them to bump into problems. 
Basically a lot of this (mysql, mail) just needs to be clarified.. The 
website: http://cyberspace.org/email.xhtml doesn't explicitly state that
people need to ask for email.. it just states:
------------
Grex provides free email accounts to anyone who wants one. This service 
is made available in the spirit of improving everyone's ability to 
communicate with others.

Once you have a Grex account, your Email address is either 
accountname@grex.org or accountname@cyberspace.org. You may use 
whichever address you prefer.

Grex does not support POP mail or Web-based mail.
<SNIP>
Once you have connected by telnet and logged in, you can use any of the 
mail clients available on Grex. Currently, we support pine, elm, and 
mail.
--------

Yes, I'm using a short whitelist right now with spamassassin.  And a
very short blacklist.  As to whether it works, it's hard to say right
now.  I still get spam which spamassassin almost always throws out
correctly.

Then we should update the web pages.

I don't think that we want a system-wide whitelist or a system-wide
blacklist.  It'd be better to leave what gets tossed out to the
individual.  That's just my opinion, though.

Most corporate spam software just puts potential spam in a separate
location and informs the user so they can decide if it's a false
positive.  If the user doesn't rescue the message in a certain amount of
time, it gets nuked.  Of course, I have no idea how much egregious spam
is deleted before that point.

Definitely the web pages need updating (it's a never-ending job, I'm
sure).  We need to have them be in line with what we are offering and
with our policies.  Making it easier for new users to find what they
need would help if it isn't obvious already.

Having easy to follow instructions for beginners is a great idea.  I
think Grex offered some sort of help manual in the past.  Perhaps, in
addition to the web page updates, that manual needs updating?

Here's an on-line spamassassin configuration generator for users:

   http://www.yrex.com/spam/spamconfig.php 

I don't know how useful that is, but it might help (or it might let
people shoot themselves in the foot more easily).

Oh, and from what I've read about spamassassin whitelisting, it doesn't
reject e-mails from people not in the whitelist per se, it gives e-mails
from the whitelist addresses a very low spam score (-100) so that it is
unlikely they will be marked as spam.  Thus, e-mails still go through
the usual spam filtering.

Can't you folks say "yes-no list" instead of conjuring up racial images?

Heh.  Read the man page.  Of course the word assassin is in there too, so
that conjures up other images, I'm sure.  

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss