GNHLUG> Org Web>InternetServer>ServerMail (revision r1.3)EditAttach

System (root) mail

We need to figure out what to do with system mail. This is mail sent to root, or any of the many aliases (e.g., postmaster, listmaster, webmaster) which forward to root.

All system mail is currently forwarding to me (BenScott), which I ain't thrilled about, but something needed to be done. If anyone else wants to join in and get the root mail forwarded to them as well, I'd appreciate it. Or a better idea. -- BenScott - 15 Oct 2006

Mailing List archives

Lost mail

Between the lates of Sat 14 and Thr 19 in Oct 2006, some mail may not have made it into the archives. Details. It should be possible to track down the lost mail in third-party archives and inject it back into Pipermail now that things are working (?) again. -- BenScott - 19 Oct 2006

Message splitting during archive rebuilds

There is some minor breakage in the list archives. As part of the ServerFromRogue[migration process]], the archives got rebuilt. During an archive rebuild, a very small percentage of messages get parsed incorrectly. Specifically, a line beginning with "From", preceded with a blank line, gets treated as a new message, regardless of any other surrounding syntax (or lack thereof). This means a handful of messages get broken into pieces. The parts after the "real" message dodn't have any valid headers, of course, so they get filed under the current month. It should be possible to rebuild the archives again, using a better pre-processor (like formail) to recognize messages. The details I'm unsure of.

Better archive software

Pipermail works, but it's simplistic and limited. I've seen much better archiving systems/UIs. It would be nice to use one of them. In particular, we would like something that spam-guards all email addresses (including those in body and non-standard headers), not just the From/To/Sender headers that get spam-guarded now. This would let us make the archives fully public again.

Spam

More sophisticated spam-filtering would be nice. We should look at doing things both in the MTA and in Mailman.

General techniques

  • It should be possible to have the MTA check to see if a post to a mailing list address is from a subscriber, and if not, reject said message during the SMTP transaction. That would be a huge benefit, I think.
  • RBLs
    • Someone else does the bulk of the work -- BruceDawson - 22 Feb 2006
    • Have a small footprint on the system -- BruceDawson - 22 Feb 2006
    • Catch 90% of the SPAM. -- BruceDawson - 22 Feb 2006
    • The lists are maintained by others -- BruceDawson - 22 Feb 2006
    • Some discriminate against dynamic and other large block of IPs. -- BruceDawson - 22 Feb 2006

Specific software

  • MailScanner
    • Easy to configure, modify configuration, very flexible. Auto-updates for ClamAV, RulesDuJour. Integrates SpamAssassin without separate daemon. Disarms spam, phishing, viruses, "active" HTML mail. Somewhat CPU intensive. I've never seen decent hardware CPU bound by it though. -- BillMcGonigle - 20 Feb 2006
    • Bill, what's "decent hardware"? -- BenScott - 15 Oct 2006
  • SpamAssassin
    • Easily configured, low maintenance, good results, low-to-zero false-positives. -- MikeLedoux - 21 Feb 2006

Discarding non-member list mail

We can solve the spam problem for mailing lists completely and easily by simply discarding (or better yet, rejecting during the SMTP conversation) all mail from non-list-members. After taking care of the mailman admin approval queues for a few months, I don't see this as being a problem. We get so little legit mail in these queues that I think I'm willing to call the once-every-other-month mis-posted message "acceptable losses". That would kill the gnhlug-jobs list, though. OTOH, that list doesn't appear to get any legit traffic, so maybe it's already dead. A web-based interface would be better anyway, I think. -- BenScott - 23 Feb 2006

The gnhlug-jobs list does get some legit traffic. We have had 9 legit messages so far in February, mixed in with over 100 garbage messages. I am not sure the list is worth keeping in current form, though, the high volume of spam is a PITA. -- MikeLedoux - 23 Feb 2006

MTA

We're currently running Sendmail. Maybe we should switch to something else?

Sendmail

  • Installed by default -- BillMcGonigle - 20 Feb 2006
  • Would be useful to relearn to use it since it is fairly ubiquitous. -- ColeTuininga - 21 Feb 2006
  • This is what we're using now, on liberty. -- BenScott - 23 Feb 2006
  • Limiting - hard to do handstands. Slow. Most people can only work in .mc -- BillMcGonigle - 20 Feb 2006
  • Cryptic to configure. -- ColeTuininga - 21 Feb 2006
    • While I fully agree that sendmail.cf is akin to assembly language, the .mc config file isn't too bad. -- BenScott - 23 Feb 2006

Postfix

  • Postfix appears to be the MTA of choice these days. -- BenScott - 15 Oct 2006
  • Resonably easy to configure for most anything you can think of. Support from most 3rd party packages (notably mailman). Fast. -- BillMcGonigle - 20 Feb 2006
  • Included with RHEL/CentOS. Supported. -- BenScott - 23 Feb 2006

exim

  • Highly configurable, configuration quite readable, easy to configure. -- ColeTuininga - 21 Feb 2006
    • Not a lot of 3rd party support; needs wrappers for some common tasks. -- BillMcGonigle - 20 Feb 2006
      • Bill - can you elaborate on these? -- ColeTuininga - 21 Feb 2006
  • Not as widely known, fewer admins tend to be familiar with it. -- ColeTuininga - 21 Feb 2006
  • Not included with or supported by CentOS. -- BenScott - 23 Feb 2006

qmail

  • Bizzare patch-acceptance policy and license. Good installs typically require lots of 3rd party patches of variable quality. -- BillMcGonigle - 20 Feb 2006
  • Not included with or supported by CentOS. -- BenScott - 23 Feb 2006
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2006-10-19 - BenScott
 

All content is Copyright © 1999-2024 by, and the property of, the contributing authors.
Questions, comments, or concerns? Contact GNHLUG.
All use of this site subject to our Legal Notice (includes Terms of Service).