|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
To prevent the addition of a footer to messages, from the main mailman administration page for the list, I clicked on [Non-digest options] The text below appeared in the "Footer added to mail sent to regular list members" field.
_______________________________________________
%(real_name)s mailing list
%(real_name)s@%(host_name)s
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
The information listed has the following meaning.
msg_footer (nondigest): Footer added to mail sent to regular list membersText appended to the bottom of every immediately-delivery message. This text can include Python format strings which are resolved against list attributes. The list of substitutions allowed are:
real_name- The `pretty' name of the list; usually the list name with capitalization.list_name- The name by which the list is identified in URLs, where case is significant. (For backwards compability,_internal_nameis equivalent.)host_name- The fully qualified domain name that the list server runs on.web_page_url- The base URL for Mailman. This can be appended with, e.g.listinfo/%(internal_name)sto yield the listinfo page for the mailing list.description- The brief description of the mailing list.info- The full description of the mailing list.cgiext- The extension added to CGI scripts.
Since the list owner did not want any footer being sent with messages, I removed all of the text from that field.
I also went to the digest options page and for the "Header added to every digest" field, I removed all of the text in that field.
References:
By default, most email clients don't display the message headers, but if you view the message headers for a message, you will see the "sender" header that Mailman adds. Viewing Message Headers in Outlook 2002 explains how to view those headers in Outlook
References:
| Address: | 65.54.246.87 |
| Record Created: | Sat Aug 12 12:30:09 2006 GMT |
| Record Updated: | Fri Jun 1 19:30:05 2007 GMT |
| Additional Information: | [ Updated via: Spam 'o Matic ] Received: from bay0-omc1-s15.bay0.hotmail.com (bay0-omc1-s15.bay0.hotmail.com [65.54.246.87]) by desperado.sorbs.net (Postfix) with ESMTP id F0C6311466 for <[email]>; Sat, 02 Jun 2007 05:14:49 +1000 (EST) |
| Currently active and flagged to be published in DNS | |
I've been using SORBS as a blocklist for quite awhile, but I have encountered problems many times due to the fact that AOL, Hotmail, EarthLink, and email servers from some other large Internet Service Providers (ISPs) tend to get on the SORBS list frequently and stay there for a long time. I've contacted AOL and EarthLink support previously when I found one or more of their email servers were on the SORBS blocklist. I've found that, though the support personnel with which I communicated understand that their company employs blocklists or other means of blocking spam, they never seem to understand that other email providers may employ similar means. I've never been successful in getting the support personnel I've communicated with at AOL or EarthLink to take any action and usually it doesn't appear that they even understand the problem; I usually just get canned responses about how to stop their service from blocking email rather than any response indicating that they understand the problem is with email going from their systems to other systems (See SORBS Blocking AOL and EarthLink Servers and Report of SORBS listing to EarthLink).
I've found reports by others using SORBS of similar problems with email from Hotmail addresses (see Hotmail on sorbs?!?).
I understand that SORBS policy charging server owners to remove systems does drastically lessen the chances that systems will be removed quickly. I've considered removing the SORBS list from the blocklists I employ to reduce the deluge of spam in users' mailboxes, but it does block thousands of spam messages daily on my server, so I haven't taken that step yet. Usually, I add the sender's email address to the /etc/mail/access list used by Sendmail to keep email from particular senders being checked against the blocklists I employ.
In this case, though, I don't want any email addressed to the mailing list to be checked against a blocklist to preclude this problem. The Mailman mailing list software won't allow any email to the mailing list unless the "from" address is for a member of the mailing list, so I don't need the additional blocklist check.
Fortunately Sendmail, which is the software that handles email on the server, does allow you to specify that email to particular "to" addresses will always be accepted and won't be checked against DNSBL's. You can allow email to a particular address to bypass the blocklist checks by editing /etc/mail/access. Place a line similar to the following in that file:
To:jsmith@example.com OKThe line above would ensure that email addressed to jsmith@example.com would not be checked against any blocklists employed on the email server.
After editing /etc/mail/access, you need to recreate the access database with a command similar to the following:
makemap hash /etc/mail/access </etc/mail/accessOnce I added the mailing list address, I was able to send email to that address from the Hotmail account without worrying that the Hotmail email server used to transmit the messages might be on the SORBS blocklist or another blocklist I'm employing to limit spam.
References:
newaliases.
## book_nook mailing list
book_nook: "|/var/mailman/mail/mailman post book_nook"
book_nook-admin: "|/var/mailman/mail/mailman admin book_nook"
book_nook-bounces: "|/var/mailman/mail/mailman bounces book_nook"
book_nook-confirm: "|/var/mailman/mail/mailman confirm book_nook"
book_nook-join: "|/var/mailman/mail/mailman join book_nook"
book_nook-leave: "|/var/mailman/mail/mailman leave book_nook"
book_nook-owner: "|/var/mailman/mail/mailman owner book_nook"
book_nook-request: "|/var/mailman/mail/mailman request book_nook"
book_nook-subscribe: "|/var/mailman/mail/mailman subscribe book_nook"
book_nook-unsubscribe: "|/var/mailman/mail/mailman unsubscribe book_nook"
I then added an email address to the list with the option to send a welcome message checked. But the welcome message was never sent. After doing a little checking, I discovered I needed to create a crontab entry for mailman 1 .
On my RedHat Linux system, the file to be submitted for the cronjob is /var/mailman/cron/crontab.in, but may be in /usr/local/mailman/cron on other systems 2
At the end of the crontab.in file, I saw the following lines:
# At 3:27am every night, regenerate the gzip'd archive file. Only
# turn this on if the internal archiver is used and
# GZIP_ARCHIVE_TXT_FILES is false in mm_cfg.py
27 3 * * * /usr/bin/python -S /var/mailman/cron/nightly_gzip
There was no GZIP_ARCHIVE_TXT_FILES entry in /var/mailman/Mailman/mm_cfg.py, so I commented out the entry in crontab.in. Since I don't need to gate news from a news server to mail, I also commented out the entry for that function by putting a "#" in front of it.
# Every 5 mins, try to gate news to mail. You can comment this one out
# if you don't want to allow gating, or don't have any going on right now,
# or want to exclusively use a callback strategy instead of polling.
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S /var/mailman/cron/gate_news
I then submitted the cronjob for mailman with
crontab -u mailman /var/mailman/cron/crontab.in.
References:
