This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
build:lists [2018/05/28 02:48] SLUUG Administration [Tell Apache to use password protection] |
build:lists [2018/05/28 03:34] (current) SLUUG Administration [Logs] |
||
---|---|---|---|
Line 524: | Line 524: | ||
* We should probably SSL-require the administrative pages for mailman. | * We should probably SSL-require the administrative pages for mailman. | ||
- | + | * We need to test mailman with some of the majordomo archives from michelob. | |
- | * We need to test mailman with some of the majordomo archives from | + | |
- | michelob. | + | |
* We need to set up mailman to handle lists for all of sluug.org | * We need to set up mailman to handle lists for all of sluug.org | ||
+ | * /usr/local/mailman/bin/add_members should be run on a list of current subscribers to ANNOUNCE, DISCUSS, SYSADMIN, and STEERCOM. I'm not quite sure how passwords, if any, will be handled. | ||
+ | * We need to copy the archives from michelob to bud and index them via htdig. I'm not sure how htdig and/or apache will handle the compressed files as currently configured. | ||
- | * /usr/local/mailman/bin/add_members should be run on a list of current | + | === Spam Subscriptions === |
- | subscribers to ANNOUNCE, DISCUSS, SYSADMIN, and STEERCOM. I'm not quite | + | |
- | sure how passwords, if any, will be handled. | + | |
- | * We need to copy the archives from michelob to bud and index them via | + | In 2018, it was discovered that one or more criminals were using a |
- | htdig. I'm not sure how htdig and/or apache will handle the compressed files as currently configured. | + | bot network to make repeated subscription requests to multiple lists, |
+ | with the intent of SLUUG sending thousands of subscription confirmation | ||
+ | e-mails to one address, that would eventually change to the next target. | ||
+ | Looking in the logs, this had been happening for years, with SLUUG sending | ||
+ | over 80k spam confirmations. | ||
+ | This also taxed the SLUUG mail server when hundreds of e-mails were | ||
+ | rejected and sitting in the mail queue for retry. | ||
+ | In response, a local mod was made to ''subscribe.py'' | ||
+ | <code python> | ||
+ | sluug_sub_mod1_value = cgidata.getvalue('sluug_sub_mod1', '') | ||
+ | if not sluug_sub_mod1_value: | ||
+ | syslog('mischief', 'Subscribe w/o local mod form field as: %s: %s', email, remote) | ||
+ | results.append(_('Subscription failed due to internal error!')) | ||
+ | elif sluug_sub_mod1_value != 'sluug_sub_mod1-20180517': | ||
+ | syslog('mischief', 'Subscribe w/ wrong local mod form field value %s as: %s: %s', sluug_sub_mod1_value, email, remote) | ||
+ | results.append(_('Subscription failed due to internal error!')) | ||
+ | </code> | ||
- | GENERAL MAIL TODO: | + | Also modified the generic ''listinfo.html'' template and the customized |
+ | version for the announce list (no other customized versions needed changes) | ||
+ | to add: | ||
+ | <code html> | ||
+ | <input type="hidden" name="sluug_sub_mod1" value="sluug_sub_mod1-20180517"> | ||
+ | </code> | ||
- | * We need to get virtual users set up in some way. Craig and I discussed | + | The permanent fix to stop all spam subscriptions is to upgrade to a current |
- | this, and two options are postfix maps and a mysql database. We didn't | + | release of mailman that includes ''SUBSCRIBE_FORM_SECRET'' and probably other |
- | make any decisions. Two particular challenges will be copying existing | + | new features to combat the bots. |
- | passwords for POP3/IMAP access and mail filtering (procmail/maildrop/whatever). Once we get users set up, we'll need to migrate their mail spools. | + | |
- | * We need to get spamassassin working. We particularly need to take a | + | === GENERAL MAIL TODO: === |
- | look at the performance impact of scanning list mail. This should | + | |
- | probably be done incoming list mail only. | + | |
- | * We need to get some form of webmail up and running. I'm partial to | + | * We need to get virtual users set up in some way. Craig and I discussed this, and two options are postfix maps and a mysql database. We didn't make any decisions. Two particular challenges will be copying existing passwords for POP3/IMAP access and mail filtering (procmail/maildrop/whatever). Once we get users set up, we'll need to migrate their mail spools. |
- | Horde becauses it has a powerful interface and a ton of cool modules. I | + | * We need to get spamassassin working. We particularly need to take a look at the performance impact of scanning list mail. This should probably be done incoming list mail only. |
- | haven't used the password module, but it might be particularly useful | + | * We need to get some form of webmail up and running. I'm partial to Horde becauses it has a powerful interface and a ton of cool modules. I haven't used the password module, but it might be particularly useful for us. See http://www.horde.org/accounts/screenshots/accounts.png. If we use horde, we'll be using mysql, so that might be the way to go for virtual users. |
- | for us. See http://www.horde.org/accounts/screenshots/accounts.png. If | + | |
- | we use horde, we'll be using mysql, so that might be the way to go for | + | |
- | virtual users. | + | |
That should do it for now - enjoy the rest of the weekend. | That should do it for now - enjoy the rest of the weekend. | ||
Line 562: | Line 574: | ||
---- | ---- | ||
- | |||
====== Notes ====== | ====== Notes ====== | ||
Line 572: | Line 583: | ||
* vette - results of admin actions to deferred posts | * vette - results of admin actions to deferred posts | ||
* bounce - tracks bounces, so failing members can automatically be purged | * bounce - tracks bounces, so failing members can automatically be purged | ||
+ | * mischief - Detected attempts to use mailman that failed, including subscriptions by bots that were blocked. | ||
+ | * error - Problems. | ||
+ | * smtp - All mail activities? | ||
+ | * smtp-failure - All mail problems? | ||
TODO: We should move these to /var/log and put them under log rotation. | TODO: We should move these to /var/log and put them under log rotation. | ||
+ | See ''contrib/*redhat_fhs.patch'' for a source modification to change | ||
+ | log and data file locations. | ||
Important information about problems might also be in the Apache server logs. Currently in ''/var/log/apache2/''. | Important information about problems might also be in the Apache server logs. Currently in ''/var/log/apache2/''. | ||
- | |||
===== Problems seen ===== | ===== Problems seen ===== | ||