[Mailman-Developers] Mailman not delivering the mail

John Viega viega@list.org
Sat, 6 Jun 1998 06:25:28 -0700


On Fri, Jun 05, 1998 at 02:50:02PM -0400, Michael McLay wrote:
> 
> The subscribe script execute and the Web page that is returned says
> a message will be sent to the subscriber, but no message arrives.
> I think something is wrong with gid or uid.  

If something is wrong w/ the gid, it should get logged to your system
maillog before the scripts ever get run, so it is more likely
something wrong with file permissions.  From an earlier post I'm
wondering if you perhaps ran make install as root, and if that might
not end up causing problems?

Assuming the program actually trys to deliver the message, it will
hopefully throw an error.  However, it probably won't do so where you
can get a trace, since the delivery code opens a pipe to the delivery
code to avoid smtp hanging hanging mailman.  So I'd add debug code to
the deliver script and the contact_transport script that log stderr to
a file, so you can see if any file problems are making it up to the
Python level.

> The debugging code that was added shows that the script is being
> executed as nobody. Am I correct in assuming that the mailer won't
> send out a message from nobody because nobody is not a trusted user?

No, that should not be the case.  Trusted user status means that if
you set the sender via -f when calling sendmail directly, sendmail
will allow that.  Otherwise, it will put in a header saying: 
"Warning: user nobody set sender to 'blah' using -f".

Since we don't even directly call Sendmail, we don't have to worry
about trusted user status.


> 
>   uid   65534   (nobody)
>   euid  65534   (nobody)
>   gid   55	(mailman)
>   egid  50	(wwwcgi)  - a group set up for cgi scripts.
> 
> I also was curious about the wwwcgi egid.  This is the gid setting
> used inside the httpd configuration, but when the subscribe cgi script 
> create the data/pending_subscriptions.db the group is set to mailman.

Right.  All of the files should be created as belonging to group
mailman.  The httpd and smtpd each run with different gids.  To let
them modify files in group mailman, yet keep them accessable by the
mailman user, we have setgid wrapper scripts (written in C for
portability).

> I'm confused about what the settings of all these things should be.  

Your settings look right.  Again, if they were wrong, you wouldn't
even get to the Python; the C wrapper would log to your system mail
log.

> I also found the layers used to send out the mail messages to be 
> puzzling.  Why the trip from maillist -> MailList -> mm_deliver ->
> Deliverer - > DeliverToUser -> mm_utils -> DeliverToUser.  Why so much 
> indirection? 

I don't understand why you're mixing methods, classes and files here.
The path is just: maillist.DeliverToUser -> mm_utils.DeliverToUser.

.DeliverToUser() is a method in maillist for delivering mail.
However, sometimes mail gets delivered that is not associated with any
particular list (and thus there will be no list object).  Thefore,
mailman.DeliverToUser() makes a call out to the utils module.
Duplicating the code in both places would lead to maintainance
problems.

Now if you're wondering why the functionality in mm_deliver is not
just brought into maillist.py, that's done intentionally to keep
related functionality together, in as small a unit as necessary.  I
find single flat files with tons of functionality tend to develop into
spaghetti rather quickly.