Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

problems with BLU mail?



Just to revisit this after this weekend. On Monday morning, the
outgoing queue had well over 2000 messages in it yet, everything was
running fine on Sunday. I restarted postfix a few times and deleted a
bunch of messages on the postfix mailq that had a bad address. It took
almost the whole day to clear out the mailman queue. I assume that the
2000 messages included a lot of the password reminders, as well as
normal list traffic. 

 On Fri, 29 Dec 2006 15:49:48 -0500 Tom Metro quoth:

> Something that might be more easily obtained than a donated server, and
> would also address the spam problem, is getting spam filtering services
> donated. Some provider, like Brightmail, might welcome the opportunity
> to get some publicity with a tech community in exchange for providing
> filtering services.  
That's a  good idea. Tom, could you contact someone on this. 
JABR are you cool with it??

> However, it isn't clear to me why you need to run tools like
> SpamAssassin, and mailscanner on a machine used exclusively for
> processing list messages. Assuming all of the lists reject senders who
> aren't subscribers, that should take care of most of it. (A Postfix
> policy server could be created to reject such emails during the SMTP
> transaction - even before mailman gets the message.) Running
> SpamAssassin on what makes it past that point would be a nice
> enhancement, and shouldn't add much overhead.  
We have admin email addresses (such as JABR and me), the various 
webmasters. But, even with lists, each list is managed differently.
Nearly all of our lists reject mail from non-subscribers, but much of
that mail tends to stack up in the pending request queues for each
list. One of the more difficult is officers because we want non-members
to post to it, but because of SPAM I've even closed that one. 
 
> If the machine handles more than just mailing lists, then maybe general
> mail should be split to a different server (an option I think you
> mentioned). It may make sense to have Gmail host mail for the few
> volunteers that have @blu.org addresses. (I know JABR experimented with
> Gmail hosting for a blu.org subdomain.) If you did that, the top-level
> list aliases might even get spam filtered by Gmail before being
> forwarded to list at olduvai.blu.org. (olduvai.blu.org could then be
> firewalled to only accept connections from Gmail's servers.)  
This is certainly possible. 

> Do any of the hosted lists accept attachments? If not, why check for
> viruses? Why not just use a simple Postfix rule to reject everything
> with a binary attachment?  
Most lists should not accept binary attachments except for digital 
signatures. I am seeing WIND accept some junk. 

I like the idea of a 3rd party prescreening BLU email for a number of 
reasons:
1. We (BLU and BUG) do have a limit on traffic. I'm not sure what the 
agggregate is, but at one point, BUG was chanrge a couple of hundred 
bucks for excessive bandwidth. 

2. The reduced traffic would allow our servers to better serve the
lists and the web sites. 


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org