[Mailman-Users] Confirmation and sent messages not
vancleef at lostwells.net
vancleef at lostwells.net
Mon Feb 26 05:37:43 CET 2007
The esteemed Mark Sapiro has said:
> Jason Luck wrote:
> >Why is the default in DaemonPortOptions set for 127.0.0.1 as opposed to a
> >broader range? It would seem most folks would want to be able to external
> >mail through their box and from what I'm learning would require the
> >127.0.0.1 to be changed. Also by changing this...does one open themselve
> >up to security issues?
> These are good questions, but they are Sendmail questions. There are
> whole books (e.g. the 'bat' book) devoted to Sendmail, and I haven't
> read any of them.
> The important thing is to not be an open relay - i.e. only accept mail
> from outside for local delivery; do not accept mail from outside to be
> relayed to another outside location; only accept 'outside delivery'
> mail from the localhost.
> I would think that the default Sendmail configuration would not be an
> open relay, but I don't know. There are various services, e.g.,
> <http://www.abuse.net/relay.html>, that will test to see if your
> server is an open relay.
Speaking from the vantage point of a sendmail user, I think virtually
all of the issues involving sendmail+Mailman are basic sendmail
In short, that means that if sendmail+Mailman are not working
properly, odds are that sendmail is not working properly with a simple
MUA like elm or mutt. Test your configuration for both incoming mail
from the Internet backbone and outgoing mail to it. If your Mailman
installation is going to take mail to listname at domain.com, then set up
a local user account as username at domain.com and use it to check out
your sendmail installation.
Once you have your sendmail working properly, Mailman is a very simple
drop-in. The defaults in the distribution Defaults.py are correct for
a simple sendmail configuration; you don't have to override anything
One step that you do have to perform, that I do not see in Barry
Warsaw's otherwise-excellent Mailman build-install manual is the need
to add the Mailman address pipes to the sendmail aliases file, and run
newaliases. This has to be done for each list. The aliases list that
Mailman generates when you create a list is correct for sendmail; just
copy it into the aliases file and run newaliases.
Barry's manual does include a comprehensive and clear how-to on adding
smrsh (sendmail restricted shell) for Mailman. However, you also have
to your main.mc file and recompile.
Don't try to manage sendmail by editing the .cf files. Use the .mc
(and .m4) files for everything.
You absolutly need to have the O'Reilly book "Sendmail," commonly
referred to as the "bat book" because it has a picture of a bat on the
cover. The recent O'Reilly "Sendmail 8.13 Companion" is another
must-have, and is valuable not only for the 8.13 references, but for a
lot of information that clarifies thing about sendmail in general.
The bat book is 1200 pages of information and nothing if not
Additional resources are the Sendmail FAQ and the Usenet newsgroup
comp.mail.sendmail. You'll get answers there AFTER you summarize your
researches in the bat book and the FAQ.
On relaying: the distribution sendmail sources should compile with all
relaying disabled. If you are running a Solaris system with the Sun
sendmail distribution, you have to change the DOMAIN statements in
both main.mc and subsidiary.mc to
For reasons known only to $DEITIES, Sun distributes sendmail with
relaying enabled. On any other installation, the bat book has a
comprehensive section (several pages) on relaying, and it will tell
you exactly what to check and how to turn on the relaying you need, if
Virtually everything I've covered above is covered in the sendmail
literature in copious detail.
One additional comment that I haven't seen clearly outlined in any
documentation, except perhaps the O'Reilly book DNS and BIND 5th
edition (2006) is that sendmail is DNS-intensive. If you are running
Mailman lists, you should have, at minimum, a caching DNS server on
your local network. This is both a performance and a netiquette
issue. In short, don't flood somebody else's DNS with your Mailman
lookups, flood your own. For best performance, put a DNS server of
some sort on the same box that is running Mailman.
More information about the Mailman-Users