|
|
| Author |
Message |
veek
|
|
Grex E-mail?
|
Feb 3 13:26 UTC 2010 |
This item has been erased.
|
| 40 responses total. |
veek
|
|
response 1 of 40:
|
Feb 3 13:33 UTC 2010 |
This response has been erased.
|
veek
|
|
response 2 of 40:
|
Feb 3 18:02 UTC 2010 |
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..
|
veek
|
|
response 3 of 40:
|
Feb 3 18:13 UTC 2010 |
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???
|
unicorn
|
|
response 4 of 40:
|
Feb 5 11:02 UTC 2010 |
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.
|
veek
|
|
response 5 of 40:
|
Feb 5 13:10 UTC 2010 |
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!
|
tonster
|
|
response 6 of 40:
|
Feb 5 13:50 UTC 2010 |
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.
|
veek
|
|
response 7 of 40:
|
Feb 5 14:39 UTC 2010 |
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.
|
tonster
|
|
response 8 of 40:
|
Feb 5 14:49 UTC 2010 |
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.
|