Difference between revisions of "E-mail"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
Line 69: Line 69:
 
=== SPAM Blacklist ===
 
=== SPAM Blacklist ===
  
There are many blacklists for known spammers. We should use them! On Feb 26, 2015 maurik included the www.spamhaus.org blacklist following instructions  [http://en.linuxreviews.org/HOWTO_Stop_spam_using_Postfix HOWTO Stop spam using postfix ] and [https://www.spamhaus.org/zen Spamhaus Zen], spamassasin configuration from [https://wiki.apache.org/spamassassin/DnsBlocklists DnsBlocklists]. It is not clear if we are already using these automatically.
+
There are many blacklists for known spammers. We should use them! On Feb 26, 2015 maurik included the www.spamhaus.org blacklist following instructions  [http://en.linuxreviews.org/HOWTO_Stop_spam_using_Postfix HOWTO Stop spam using postfix ] and [https://www.spamhaus.org/zen Spamhaus Zen], spamassasin configuration from [https://wiki.apache.org/spamassassin/DnsBlocklists DnsBlocklists]. We should be using this, but we are not.
 +
 
 +
You can check if an ip is listed in the block list by following the recipe at: [http://daemonforums.org/showthread.php?t=302 Check using dig]:
 +
<pre>
 +
take IP address a.b.c.d and reverse and add zen.spamhaus.org, then do a dig on that, i.e.:
 +
dig d.c.b.a.zen.spamhaus.org
 +
If it returns a 127.0.0.x it is a confirmed spammer
 +
</pre>
  
 
== GNU Mailman ==
 
== GNU Mailman ==

Revision as of 01:46, 27 February 2015

This is the set of programs that service NPG e-mail.

The order of operations for starting mail by hand is as follows:

Dovecot, Spamassassin, Postfix, Mailman.

And to safely stop the mail system, stop the services in this order:

Mailman, Postfix, Spamassassin, Dovecot.

The reason for this order is we stop recieving mail from other servers once postfix is down, stop processing incoming/outgoing mail with spamassassin because there's no more incoming/outgoing mail, and then we stop users from being able to get their mail and change things with dovecot. This allows us to take the mail system down and not bounce or lose any, since the servers trying to send us mail simply wait until we're receiving again.

Postfix

Centralized set of programs to send/recieve mail, as well as put recieved mail through spam/virus filters. The RPM is pretty good in that it automatically puts entries for some of the below programs in the appropriate configuration files. Sometimes it's necessary to un-comment them, though.

Configuration is: /etc/postfix/main.cf

Noteworthy Variations on standard setup

main.cfg

# LIMITS
#
# The maximal size in bytes of a message, including envelope information.
# Default is 10 MiB.
message_size_limit = 51200000

For authentication, the previous (before 11/4/2014) setup used the Cyrus SASL module, which was not configured correctly. It would look for a database that did not exist, and it would request authentication methods (AUTH CRAM-MD5 DIGEST-MD5 PLAIN LOGIN GSSAP) most of which would not work. This messed up mail from Apple Yosemite systems, causing fail2ban to ban the ip. We switched to Dovecot SASL module on 11/4/2014, which seems to behave correctly. Lines in mail.cfg that were changed:

# Enabling cyrus sasl
############################# Switch to Dovecot 11/4/2014 - Maurik
#smtpd_sasl_path = smtpd

# Enabling dovecot sasl
smtpd_sasl_type = dovecot
########################### Switch 11/4/2014 - Maurik -- make sure Dovecot is setup to put auth in /var/spool/postfix/private/auth
smtpd_sasl_path = private/auth

Note that this also required a change in the /etc/dovecot.conf file.

mynetworks = 10.0.0.0/24, 127.0.0.0/8, 10.8.16.0/24, 132.177.88.0/22 hash:/etc/postfix/nis-peers

master.cfg

#

spamassassin unix -     n       n       -       -       pipe
  user=spamd    argv=/usr/local/bin/postfixfilter -f ${sender} ${recipient}

Dovecot

We run dovecot as our mail server. We're using a pretty much default setup, for ease of administration. The dovecot website has all necessary documention, and most of the system is fairly self-explanatory. The only thing that's weird is we have the sieve plugin, so that we can have and process sieve scripts for filtering.

SpamAssassin

Postfix uses SpamAssassin to filter e-mail. Needs an entry in /etc/postfix/master.cf and Procmail configuration

Presently, we only mark spam with some header flags, and by prepending "[SPAM] " to the subject of spammy messages. This allows the user's "sieve" script to figure out what to do with the email marked as spam. It can be discarded or stored in a junk mail folder, depending on the user's setup. See the SpamAssassin page for more info.

SPAM Blacklist

There are many blacklists for known spammers. We should use them! On Feb 26, 2015 maurik included the www.spamhaus.org blacklist following instructions HOWTO Stop spam using postfix and Spamhaus Zen, spamassasin configuration from DnsBlocklists. We should be using this, but we are not.

You can check if an ip is listed in the block list by following the recipe at: Check using dig:

take IP address a.b.c.d and reverse and add zen.spamhaus.org, then do a dig on that, i.e.:
dig d.c.b.a.zen.spamhaus.org
If it returns a 127.0.0.x it is a confirmed spammer

GNU Mailman

Manages mailing lists. Currently, we have three mailing lists. "Mailman" is a list used internally by the service. "Npg-admins" goes to us, the admins. "Npg-users" should go to all the users who have an account on our systems, if it's kept up to date.

In the event of strange errors with mailman (say, from rebuilding einstein), you should set STEALTH_MODE = 0 in /usr/lib/mailman/scripts/driver so that you can see errors in the web interface. This allows you to find strange errors like writing to /var/log/mailman/error, or any traceback information.

If you're having any permissions errors, you should (as true root, not sudo) run /usr/lib/mailman/bin/check_perms. If it gives any errors, run it with the -f flag to fix permissions automatically. This should take care of everything for you.

Web interface on einstein
More info