I've been having this problem for a few days, and I am just trying to find out if anyone else here is experiencing a similar phenomenon (so that maybe I'll get lucky and talk to you and figure out what the story is):
- 1.0b5 + sendmail 8.9.1
- RH Linux 5.1 (if you need more info, it's also http://www2.acm.jhu.edu -- there's lots of stuff there)
There was some weirdness with permissions being set wrong with Linux + b5, but Barry issued a patch in about 2 seconds flat that cleared that one up. The current problem is that I have several lists set up, but if you send mail to them (like test@acm.jhu.edu), your mail is swallowed into a bottomless pit...it never sees the light of day again. If you look at /var/log/maillog, it claims the mail has been sent. Users have that they did get their monthly password reminder from Mailman itself, however.
I don't think this is really something misconfigured with sendmail on my end; this same setup was chugging right along with 1.0b4 until I tried to switch.
Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Money is the root of all good."
PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1
Corbett, i've been hoping to find a minute to look into this behavior - i may be able to get to it later today. In the meanwhile, please check for any relevant entries in your ~mailman/logs/errors log file, and if there are any, send copies to me.
And let me see if i understand correctly - you say that /var/log/maillog indicates that your sendmail sent the messages to the users, but the users never see them? This would suggest that the messages *really* foul up the receiving side - and that brings one possibilty to mind.
There is a known bug in some recent versions of sendmail (8.8.x for some x, and 8.9.0) such that the sendmail will core dump when attempting to deliver mailman's (or any 8-bit encoded) Mime-format digests in certain (somewhat uncommon) circumstances. The question then is, were the messages that never appeared in the users mailbox Mime digests? And if not, could you construct a repeatable test that at least reduces the likelihood that the problem is on the receiving ends? For that matter, might you happen to be running sendmail 8.8.x or 8.9.0? Your sendmail may be getting so far as negotiating the delivery and then failing partway through...
With the info available currently it's hard to know what of mailman to investigate on this end, since mailman evidently got the messages to your MTA.
Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #Ken & company:
More info...to correct myself earlier on the sendmail logs (and to be precise), I sent a test message (no MIME, just a 1 sentence text message) to one of our small lists (it's the list shown at http://www2.acm.jhu.edu/mailman/listinfo/tm).
Sending out that message generated the below entries in /var/log/maillog:
Aug 3 14:04:36 chimera sendmail[15085]: OAA15085: from=<cklempay@chimera.acm.jhu.edu>, size=657, class=0, pri=30657, nrcpts=1, msgid=<Pine.LNX.3.96.98080314042 5.15083A-100000@chimera.acm.jhu.edu>, proto=SMTP, relay=cklempay@localhost Aug 3 14:04:36 chimera sendmail[15086]: OAA15086: clone OAA15085, owner=tm-admin Aug 3 14:04:37 chimera sendmail[15086]: OAA15086: to=|"/home/mailman/mail/wrapper post tm", delay=00:00:01, xdelay=00:00:01, mailer=prog, stat=Sent
As for ~mailman/logs/errors...there is no such file in that directory (so no recorded errors, I guess).
I'm running sendmail 8.9.1. All of the previous messages I tried were simple text messages (with whole bodies of things like "Holler if ya hear me").
Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Money is the root of all good."
PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1
I've identified the reason for the problem corbett was having, and have a workaround.
The problem appears to be another linux-specific item, having to do with the apparent fact that effective gid's are not inherited by forked processes. I'd be curious to get the scoop on this from any linux gurus out there.
Corbett was seeing mail submissions completely disappearing - making it to the maillist, but never showing up, without any logged error messages. The failure was happening when the new delivery mechanism was attempting to place the messages on the outgoing queue. The data directory was writable by mailman, and the mail wrapper executable forks and execs the maillist script with the mailman effective group id. However, the delivery mechanism runs in a subsequently forked process of the maillist script - and apparently, forked processes (at least, forked scripts) in linux do *not* inherit the effective group id - contrary to the practice on other unices. Linux folk, is this correct?
The immediate workaround for those of you running mailman 1.0b5 under linux is to fiddle with the ownership of the ~mailman/data directory a bit: set the owner id to 'mail' (or whatever your mail process runs with), make sure the group id is 'mailman', and make sure that it enables user and group write.
The real question, though, is whether there is any way in linux to enable forked processes, even scripts, to inherit the effective gid of the forking script. Any obscure system call for that, or something, which requires only membership in the group, not root privileges, to run?
It might make sense for the installation mechanism to change the owner of the data dir to that of the mail system, as the workaround does - but that would sacrifice the ability to do that part of the installation process as a regular user - root privilege is needed to chown. So this solution does not seem ideal. There are other avenues, but we could need to get the last word on the way that (redhat 5.x) linux is supposed to be working, and what people normally to do achieve the kinds of things we're aiming for. Insight and suggestions are welcome!
Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #
participants (2)
-
Corbett J. Klempay -
Ken Manheimer