??changed: -Note: for an overview of how mail are _sent from_ Savannah, please check InternalMailSystem. Note: for an overview of how mail are sent _from_ Savannah, please check InternalMailSystem.
??changed: - There are no static Mailman aliases; instead, is looks at '/var/mailman/lists/list_name/domains/' and check for files that represent the domain of the list, such as 'gnu.org', -'nongnu.org', 'mail.freesoftware.fsf.org', 'fsfeurope.org', 'fsf.org', 'gnupress.org', 'nevrax.org', 'prep.ai.mit.edu'. There are no static Mailman aliases; instead, is looks at '/var/lib/mailman/lists/list_name/domains/' and check for files that represent the domain of the list, such as 'gnu.org', 'nongnu.org', and the like. ??changed: - * there is some Exim code to take those files into account (I was the code, but maybe it's not in use anymore) * there is some Exim code to take those files into account ??changed: - Archives are updated every 2 hours (as of May 2007). Archives are updated every 30 minutes (?) as of May 2011. ??changed: - * private archives are managed by Mailman: /var/mailman/archives/private/list_name.mbox/list_name.mbox (use the 'arch' command to manage them; look at the --wipe command) * private archives are managed by Mailman: /var/lib/mailman/archives/private/list_name.mbox/list_name.mbox (use the 'arch' command to manage them; look at the --wipe command) ??changed: -This is an effort from [email protected] to reduce the disk I/O on this already loaded machine. Spiders tend to put lists.gnu.org to its knees :/ This is an effort from [email protected] to reduce the disk I/O on this already loaded machine. Spiders tend to put lists.gnu.org to its knees, unfortunately. ??changed: - All this is to bypass the fact [email protected] won't agree with sharing access to the Savannah database - which is how *forge is supposed to work these days. The cron job runs on the vcs-noshell host, file /etc/cron.d/sv. The script being run is named sv_mailman. ??changed: - lists.gnu.org makes a series of checks that will reject mail from, say, '[email protected]' because this is apparently not a valid e-mail. E-mail validation is performed against at Mailman, and eventually falls-back against fencepost (Unix users and the shares /com/mailer/aliases). lists.gnu.org makes a series of checks that will reject mail from, say, '[email protected]' because this is apparently not a valid e-mail. E-mail validation eventually falls-back against fencepost (Unix users and the shares /com/mailer/aliases). ??changed: - Outdated information - - At a point, the checks also rejected mail between 2 mailing lists, so we could not use a mailing list as a valid sender. [Now it seems that works again.] - - To bypass the list2list restriction, "savannah-bounces" was somehow whitelisted - but while it should have received the bounces and other erroneous mails, this e-mail name clashes with Mailman's *listname*-bounce naming convention, and currently that e-mail even rejects traffic with error '550 Unknown user'. - - We tried having savannah's IP whitelisted but that didn't work either because there's an intermediate machine/IP/hop (lists.gnu or mp.gnu, I think). - -Anti spam - - Mail can be forwarded to [email protected] which, using the Mailman mail interface, can pipeline your list with a conservatively-configured SpamAssassin. - - Cf. ListHelperAntiSpam - Antispam Mail can be forwarded to [email protected] which, using the Mailman mail interface, can pipeline your list with a conservatively-configured spamassassin, cf. ListHelperAntiSpam -- forwarded from http://savannah.gnu.org/maintenance/MailSystem#[email protected]/maintenance
