Jason Luck wrote:

...

...

SMTPHOST...in mm_cfg.py...no info on DELIVERY_MODULE = 'SMTPDirect' MTA = 'Manual' SMTPHOST = 'localhost' SMTPPORT = 0 # default from smtplib SENDMAIL_CMD = '/usr/lib/sendmail'

If the above are actually indented, this is bad. They shouldn't be.

Is this from mm_cfg.py or Defaults.py?

Actually the text listed above on SMTP which was in section 4 of 3.14 FAQ is not listed in my mm_cfg.py...not there at all. Is this a problem?

No. That bit in the FAQ is just a listing of the defaults from Defaults.py and these should be OK.

...

...

6. Locks

Can't find any locks folder under a mailman directory

It's somewhere? Is there a setting for LOCK_DIR in mm_cfg.py?

There is no setting for LOCK_DIR in the mm_cfg.py. I perform a locate on either LOCK or LOCK_DIR and the only LOCK I can find deal with items in an selinux area.

LOCK_DIR is not a directory, it is a Python name set in Defaults.py and possibly overridden in mm_cfg.py. Thus, you won't find it with locate, but you might find it with grep.

If this is a RedHat FHS compliant installation, you will probably find them in /var/locks/, but if you check the setting for LOCK_DIR in Defaults.py (since it isn't in mm_cfg.py) you should find it. See <http://mail.python.org/pipermail/mailman-developers/2004-October/017343.html> for more on RedHat FHS.

Within the Mailman directory there is a LockFile.py, LockFile.pyc and LockFile.pyo

This is the Mailman module that deals with locking and locks. It is not the locks themselves, but locks aren't your problem anyway.

Here is what the smtp-failure log is saying...

more smtp-failure

Feb 21 18:30:00 2007 (6645) Low level smtp error: (-2, 'Name or service not known'), msgid: <mailman.0.1172099747.6557.test@falconfootball.org>

See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.014.htp> and <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.073.htp>.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Jason Luck wrote:

Also...I just found a discussion on the mailman archives of...

Low level smtp error.

And I wonder why you didn't find FAQ 6.14 which addresses your problem specifically.

telnet localhost 25

...from the mailman box. I just tried that command from the mailman box and received the following...which I'm guessing is potentially a source of my problem.

localhost/25: Name or service not known

Yes, it is the problem. You can't resolve the name 'localhost'.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Jason Luck wrote:

I didn't know enough to look into the specific log files that gave me the information until I had started this thread. 6.14 looks helpful. But I looked in resolv.conf and have the following:

; generated by /sbin/dhclient-script search localdomain nameserver 24.25.5.60 nameserver 24.25.5.61

...the nameserver info is for my domain...is the search localdomain the issue?

I think the issue was the lack of a 'localhost' entry in /etc/hosts. When you added that, did anything change? Can you now 'telnet localhost 25'?

If Mailman still can't send, have the log messages changed in smtp-failure?

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Jason Luck wrote:

...but...I'm not able to...

(a) receive any email when posted to a list I'm subscribed to. (b) and there is not record in the archives of these messages. (c) I've checked the following logs...maillog, smtp, smtp-failure and they are not posting anything.

It seems as though the messages may have left my external email, but never reached my local MTA or mailman?

That's right. The delay notice below says it was unable to connect to an SMTP server at falconfootball.org. Is your MTA at falconfootball.org listening for connects on port 25 from the outside?

Listed below is a message I received from my business email side...

The original message was received at Fri, 23 Feb 2007 12:34:05 -0500 from localhost.localdomain [127.0.0.1]

----- Transcript of session follows ----- <test@falconfootball.org>... Deferred: Connection refused by falconfootball.org. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old <snip>

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Jason Luck wrote:

grep "Port" sendmail.cf

O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA #O ClientPortOptions=Family=inet, Address=0.0.0.0

I don't know sendmail configuration, but it seems you've only told it to listen on the local loopback port 127.0.0.1

netstat -na |grep ":25 "

tcp 0 0 127.0.0.1:25 0.0.0.0:*
LISTEN

And netstat confirms that. You should also see something like

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

You should be able to telnet to port 25 of this host from outside. You can't (or at least I can't - I get a refusal to my connect negotiation).

and in the etc/hosts file

IPAddress Hosts Alias 127.0.0.1 localhost [##.###.##.##] falconfootball.org

Not relevant. This only directs connects to falconfootball.org from this machine to the given IP address. It has no effect on what's listening on this machine for connects from the outside.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Jason Luck wrote:

Thanks for the response, unfortunately my limited knowledge on these matters leaves me at a dead end. Not sure how to change any of these items or where to go from here.

You fix it in your sendmail configuration by telling sendmail to listen for port 25 connects from anywhere. I can't tell you how to do that because I don't know.

Perhaps you can read some sendmail documentation or ask on a sendmail list.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Fri, 23 Feb 2007 vancleef@lostwells.net wrote:

The esteemed Mark Sapiro has said:

...

Jason Luck wrote:

...

Thanks for the response, unfortunately my limited knowledge on these matters leaves me at a dead end. Not sure how to change any of these items or where to go from here.

You fix it in your sendmail configuration by telling sendmail to listen for port 25 connects from anywhere. I can't tell you how to do that because I don't know.

Perhaps you can read some sendmail documentation or ask on a sendmail list.

I'll chime in with some quick observations (I run sendmail 8.13.8 on Solaris 9).

The two first places I'd look are:

1. The tcp-ip services file (/etc/inet/services on Solaris) needs a line that says: smtp 25/tcp mail

2. There needs to be a sendmail -bd daemon running. That is the one that listens for incoming smtp.

I don't see anything specific to port 25 in the .cf files.

I would also check any router/firewall between your sendmail client machine to make sure that incoming port 25 traffic is not being blocked; also any ipfilter setup.

Hank

Looks like I have it up and working. Just received one of my first test messages all the way through. I think there were a number of things wrong, not the least of which was that I had the DaemonPortOptions set for the loopback and so it was in no way looking for external mail as I understand it now. I made the changes listed in some sendmail lists and although the changes took affect seemingly in the files based on time stamp changes when I ran netstat I saw no difference in what sendmail was listening to. I did all of the restarts on the networking and mailman but it didn't seem like it was working.

So...I did a full shutdown and restart of the entire system.

And...all is working seemingly. In fact as I type this message it looks like two test messages from earlier today have just hit.

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?

Mark and Hank, thanks for all of the help!

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 configuration issues.

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@domain.com, then set up a local user account as username@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 in mm_cfg.py.

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 add FEATURE(smrsh, /usr/lib/smrsh)dnl 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 comprehensive.

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 DOMAIN(`solaris-antispam')dnl 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 any.

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.

Hank

The esteemed Barry Warsaw has said:

Thanks Hank. I haven't used Sendmail in 20 years, so if there is
some specific text you'd like to see added (or preferably a patch to
the latex file), please feel free to send it directly to me and I'll
push up a doc update.

Barry (and Mark)

Just to acknowledge your note. I am installing Mailman on a Solaris 10 cold O/S install, and am right at the point in the install manual where I have to configure sendmail to work with Mailman. This is the fourth or fifth time I've gone through the process, so as they say in the automotive trades, I'm "able to make flat rate."

Since you guys aren't working with either Sendmail or Solaris, I think it would be best for me to walk through and record the entire process, and give that to you as a basis for inclusion where and however you want to use it.

I'll note that the sendmail.org faq on setting up virtual domains is broken, and while the bat book covers doing it, the discussion is not complete. I think that including the relevant part of the main.mc file, as well as the configuration of the local-domain-name file (known as the "cw file"), to give the novice admin. all of what is needed to set up a virtual domain system might be wise. That would save you guys from having to answer FAQ questions constantly.

Mark, I still owe you a how-to on moving an existing list to a new host. Your notes on my first stab at it made clear that I was overcomplicating things.

Hank

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 27, 2007, at 10:44 PM, vancleef@lostwells.net wrote:

Since you guys aren't working with either Sendmail or Solaris, I think it would be best for me to walk through and record the entire process, and give that to you as a basis for inclusion where and however you want to use it.

Sounds great Hank, thanks.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRe8EOHEjvBPtnXfVAQLlSwP/Yy0m8Imse1G/caR4nHNXOo+TN7FKdEAf IaE7HRIO6Z9e1c0WE0RiaHwpaLWNsBe8ME33sTBv5p9yT5XceL2VTRZz8ZXvCrKX xlCvDKQfNCtXX4Hk3Ezv861QUDJcKJDI3cLV3s1w8uMI43i1ManDwBcC/IEQn9SN hjz2M6Jr33c= =rkmC -----END PGP SIGNATURE-----

Mailman, in its default configuration, readily integrates with a properly-configured sendmail installation.

The discussion below gives specific file locations for a Solaris 9 installation. Solaris 10 locates the sendmail control file sources in /etc/mail/cf rather than /usr/lib/mail/cf. Locations of the sendmail executable and ancillary files are compile-time options for sendmail, so you will need to determine file locations for your specific installation. In our discussion, we also assume that the sendmail MTA that communicates with the Internet backbone and Mailman are installed on the same node (same hardware box).

Steps required for a Mailman-sendmail integration:

1. Enable smrsh. Creating the directory links was covered in the previous installation step. In addition, assure that the link to the smrsh program is declared in main.mc. (/usr/lib/mail/cf/main.mc on a Solaris 9 system).

FEATURE(smrsh, /usr/lib/smrsh)dnl

2. For each list that you create, you need to add a set of alias pipes to the aliases file (typically /etc/mail/aliases) and run the newaliases program (/usr/sbin/newaliases). If you are following this guide for an initial Mailman installation, you will not be creating lists until later steps. Mailman will give you the alias information when you create a list. Additionaly, the $(prefix)/bin/genaliases script will generate all of aliases needed for all lists that have been created to stdout. These are in the correct format for the sendmail aliases file.

3. Set up sendmail masquerading to correspond to the Mailman configuration. For example, if your installation is on a machine known as myhost.mydomain.net and you create a list to receive mail at mylist@mydomain.net, you will need to masquerade as mydomain.net. You will also need to masquerade the sending envelope as well.
   In its simplest form, the statements in main.mc for doing this are:

MASQUERADE_AS(mydomain.net')dnl FEATURE(masquerade_envelope')dnl

4. Add the masquerade address to /etc/mail/local-host-names. For the example above, the local-host-names file must have:

mydomain.net

The above four items cover the basics needed to integrate Mailman with a simple sendmail installation. Except for the need to enable smrsh and to install piping aliases, virtually everything surrounding a Mailman installation supported by the sendmail MTA is specific to sendmail, and some of the above is abstracted from sendmail documentation.

This documentation includes:

The README included in the sendmail source distribution from http://www.sendmail.org/

Costales, Bryan: "Sendmail," 3rd edition, O'Reilly, 2002 This is commonly referred to as the "bat book."

Costales, Bryan: "Sendmail 8.13 Companion," O'Reilly, 2006

Additional resources are the web site and sendmail faq at: http://www.sendmail.org/ Usenet newsgroup comp.mail.sendmail

For convenience, we include comments here on sendmail configuration considerations that often come up on the mailman-users list.
References are to Costales, "Sendmail".

A general guiding principle when working with sendmail is to "keep it simple." In particular, configure and test your sendmail installation thoroughly, with user accounts running simple MUA's such as elm or mutt, before expecting sendmail to work with Mailman. Virtually all of the problems users encounter with sendmail are visible to simple MUA testing.

In particular, do ALL of your sendmail configuration through the M4 macro files, rather than attempting to read and edit the .cf files.
Since your M4 files will quickly become site-specific, we recommend copying the the full M4 setup to a local directory, and managing the configuration from there. This will prevent a sendmail upgrade from overlaying your site's configuration, something that has historically been a problem to Solaris users, where a sendmail upgrade is included in a patch cluster.

Management of sendmail .cf files through the M4 files is discussed in "Sendmail" chapter 4.

Virtual Domain handling: This refers to the case where a server at mydomain.net handles mail for otherdomain.com. The authoritative DNS for otherdomain.com is set with A and/or MX records pointing to the same IP as that for mydomain.net.

Handling this in sendmail is straightforward. Masquerading is covered in detail in "Sendmail" section 4.4, pp160ff. However, the discussion does not give a complete main.mc file masquerading configuration, which we include here for convenience:

MASQUERADE_AS(mydomain.net')dnl FEATURE(masquerade_entire_domain')dnl FEATURE(limited_masquerade')dnl LOCAL_DOMAIN(mydomain.net otherdomain.com')dnl MASQUERADE_DOMAIN(`mydomain.net')dnl

In short, you include all of the domain names you are handling, but only specify masquerading for domains where you need a nodename removed from the canonical name.

You also need to add the additional domain(s) to /etc/mail/local-host-names; each domain name on a separate line.

Note that "local-host-names" is actually optional feature for adding names to the class $=w in the .cf file convention. It is typically defined (by default) in cfhead.m4 (on Solaris 9, /usr/lib/mail/m4/cfhead.m4) define(confCW_FILE', MAIL_SETTINGS_DIR`'local-host-names')

For test, a simple local MUA should be able to send and receive mail from any of the domain names at your host. Make sure that the "host name this list prefers for email" on the main options page is correct for the masquerading you have set up.

Note that the list outgoing mail envelope is added by sendmail, and is not a Mailman function.

Relaying: Once upon a time, sendmail allowed significant relaying by default. Recent and current versions default to "no relaying at all." "Sendmail," section 4.5, pp164ff, discuss sendmail relaying in detail.

Solaris users should be aware that the Sun Solaris sendmail distributions have relaying enabled by default. For almost all installations, this should be corrected by changing the main.mc DOMAIN statement to: DOMAIN(`solaris-antispam')dnl

On non-Solaris systems, the usual DOMAIN statement is: DOMAIN(`generic')dnl

Jason Luck wrote:

When I look in my /etc/hosts file...I have no entries.

So I just added...

127.0.0.1 localhost

...and restarted the network.

That should help.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan