Re: Subscribers not receiving emails - new setup

You left the digest aliases in, but anyway...

Try one more test for me, and tell me what happens (via the list so others
may learn from this experience too).  First let me "assUme" you have an
alias for nobody that looks like this;
nobody:/dev/null
or
nobody:root

Comment out the majordomo portions of your aliases file.
#majordomo: "|/usr/lib/majordomo/wrapper majordomo"
#majordomo-owner: owner-majordomo
#owner-majordomo: dliston


Now lets examine line by line what is happening through the aliases file.

test: "|/usr/lib/majordomo/wrapper resend -l test test-outgoing,nobody"

Messages to [email protected] are received by sendmail and looked up in
the password and/or aliases file for delivery/rewrite information.  Test
messages are piped through the majordomo wrapper into the resend script
using the listname "test" as an argument to resend, and specifying new
recipients of test-outgoing and nobody on the local machine.  This means
that test-outgoing and nobody are also looked up in the password and
aliases files for delivery/rewrite information.  If nobody:/dev/null is
an entry in the aliases file, mail to the nobody address is redirected
to the bitbucket and that "copy" is never seen again.  The reason we want
to keep this address in the recipient list, is to prevent sendmail from
advertising the actual delivery address of test-outgoing in the message's
header information.

test-outgoing: :include:/var/lib/majordomo/lists/test

This alias can be reached directly as test-outoing@ my.domain.com or through
the test@ my.domain.com which processes test messages and forwards their
output to this alias.  At the point the message reaches this alias, sendmail
will expand the :include: file for a new list of recipients of this message.
This file must be readable by sendmail and majordomo for smooth operation.
This alias needs to be protected from spammers, or you expose all the members
of the list with a single address.

test-owner: owner-test

Like the other redirections, test-owner is sent/redirected to owner-test on
the local machine.  This could be a fully qualified address if necessary too.
This address is only created to support users who cannot remember owner-test.

owner-test: dliston

The owner-<anyalias> is a hidden sendmail feature that sendmail uses to send
notifications of errors/problems when it has trouble delivering to <anyalias>.
In the case above, I chose a contact/notification address of a human that is
responsible for my test mailing list.  In most cases, this is the same human
that is responsible for all my mailing lists and majordomo itself too.

test-approval: owner-test
This address is the default address majordomo will punt to when a list needs
attention from a human.  I aim this address at the list owner alias which in
turn is aimed at a human mailbox.

Lastly, I am going to "assUme" that the <mailto:....> urls listed in your
aliases below are a result of your email client, and not actually in the
/etc/aliases file.  When dealing with mailing lists, it is crucial that
you only use pure ASCII text (not HTML or RTF) to deal with mailing lists.
The alternative, is to pre-process messages to convert them to plain text
or modify configurations to expect and accept fat bloated messages that are
not compatible with every other mail reader on the planet.

Now that you know what happens and why in the aliases (so far), I need to
warn you, that majordomo has been disabled, and the test we are performing
is specifically sendmail related.  But before we start that, I need you to
check two more sendmail settings.

Does the sendmail.cf contain Tmajordomo?
Does /etc/mail/trusted-users contain majordomo?

If one of the above is true, you are all set to test.  If neither is true,
but you added one, you must restart sendmail.

If you modify any line in your /etc/aliases file, you must rebuild the
binary version of the file with "newaliases" or "sendmail -bi" as root.

If cald7786 at bellsouth dot net is in the /var/lib/majordomo/lists/test
file and test.config only allows members to post to the list, you should
be able to send to every member by addressing a message to test at your
dot domain from your bellsouth account.

Regardless how test.config is set up addressing a message to test-outgoing
at your domain from anywhere should deliver your message to all test members.

Finally, here is the test.  Send a message from any account you have either
on or off of the system running majordomo, to test-outgoing at the domain
name that has an mx pointed at the majordomo server.  If the majordomo
server is named moveit, and your domain is domain.com, the address to write
a test message to is test-outgoing@ moveit.domain.com.

If you have no typos in your aliases file, and pure ascii text in your test
membership file owned by majordomo with 644 permission, and each line of
the file contains nothing more than a simple email address, the message
"should" be delivered to everyone in that file.  /var/log/maillog should
be able to validate messages going out to the recipients/members.  SIDENOTE:
all membership filenames must be in lower case, not upper or even mixed is
allowed.

IF/WHEN this works, you can reintroduce the majordomo portion of it.  Write
a test message to test@ your.domain instead of test-outgoing.  Does it still
work?  I just installed majordomo 1.94.5 via RPM on a Fedora 8 machine and
all is fine.  Then again, I know how to interpret bounce messages, headers,
and log files.

When you are ready to test the "test" list again, do this first.  Rename
the test.config file to t.config (assuming you don't have a list called
t), and send a message to majordomo with a blank subject and just this one
word in the message body with no blank lines;
lists

This will make majordomo examine all files in the /var/lib/majordomo/lists
directory and create default config files for each list that does not already
have one.

More comments to your specific questions/comments insterted "inline".

Dan Liston

cald7786 wrote:
> test: "|/usr/lib/majordomo/wrapper resend -l test test-outgoing,nobody"
> test-outgoing: :include:/var/lib/majordomo/lists/test

These are the only aliases to worry about for now.

>  
> 
> However, I'm still the only user receiving the emails.
> 
>  
> 
> The list file for "test" is owned by majordomo.
> 
>  
> 
> When I send a message to the list, if reports in /var/lib/majordomo/log:
> 
> Jul 17 16:04:05 moveit-listsrv.domain majordomo[12517] {"User" 
> username@domain <mailto:username@domain>} help

This error is NOT a result of sending a message to your list, this one
indicates a message to majordomo that had no commands, so the help file
was sent.

This should mean that majordomo sent the help file to username@domain.  As
long as sendmail knows how to deliver to username@domain, you should have
received the help file, not a copy of the message you sent.  Also, keep in
mind that majordomo only logs errors, not successes.  To see successful
distribution of your list, you must examine the /var/log/maillog file for
a line containing several or all of the addresses in your list membership
file.

> 
>  What linux/unix are you running your mail server on? *2.6.9-5.ELsmp*
> 
>  What MTA does your mailserver run? *sendmail-8.13.1-2*
> 
>  Is your majordomo installed on the same or a separate host? *Same host*
> 
>  What version of majordomo are you running? *1.94.5* 
> 
>  Did you install majordomo yourself?  *Rpm file*
> 
>  What was the output result of executing `./wrapper config-test`? 
> *"Nothing found bad"*

All of the above seems reasonable.  Nothing raises any red flags.

I do need clarification however, that the log entry above is not a cut
and paste, but modified for public consumption?  If it is cut&paste, I
have serious doubts about your aliases file.