Sam Varshavchik wrote on 07/09/2008 12:26 PM:
> All evidence says that Courier simply does not receive this message. 
> You have not mentioned how you go about sending mail -- from your 
> desktop's PC email client, by running sendmail from the command line, 
> from another server, etc… You'll need to start looking at the logs 
> from that end.
I have sent test messages from several accounts, all with precisely the 
same results.  In each case I have sent the messages from a thunderbird 
client on a personal machine in my home office.  The courier server 
(manawiz.com, aka alohadharma.org, aka allthingslocal.com, aka a few 
other things) is in a hosted facility in a different state.  The 
originating mail server accounts have been:  1) my account on 
manawiz.com, accessed via imap in thunderbird to courierimap on the 
server, 2) my account at gmail accessed through pop from thunderbird, 3) 
my account at my company accessed through imap from thunderbird to an 
exchange server at my company, and 4) my wife's account on manawiz.com 
also from her thunderbird on her machine using imap to courierimap on 
the server.

I strongly doubt all of these clients and/or originating servers treat 
mail to [EMAIL PROTECTED] any differently than mail to 
[EMAIL PROTECTED] It is clear that the dot-courier 
delivery mechanism is called in both cases as cmlm is reached.  It is 
also clear that dot-courier binds DEFAULT to subscribe when mail is sent 
to sanghas-subscribe, but does not bind DEFAULT to help when mail is 
sent to sanghas-help (but what the environment does look like in the 
sanghas-help case is not clear at all).  Mail to sanghas-subscribe is 
logged as incoming by courier while mail to sanghas-help is not.  It 
seems the issue must be somewhere in courier from the point of receipt 
to the point of delivery via dot-courier to cmlm.

I will try to narrow this down further.

> The subscription request contains headers from the email message at 
> the very end, that should show the subscription address.
For mail sent to sanghas-subscribe all headers are included in the 
message to the list owner including from and subject, but for a request 
made through webmlm the only header included in the message to the list 
owner is a single Received:.  This provides no useful information, and 
thus makes it impossible for the moderator to decide whether or not to 
accept the new member, rendering webmlm not usable as it stands for this 
list.

I'm either going to patch webmlm to generate more headers if I can 
figure it out or, being a java guy, write my own front end using a 
servlet (jsp) and javamail to generate and send subscription mail, using 
the subject header to contain at least a brief description of the person 
who is asking for membership in the list.  If I can find a way to patch 
cmlm to also send along the message body I'll do that too and provide 
for a full message on the web form.

> As far as list traffic goes, messages get archived upon receipt by 
> couriermlm.
And they are not getting archived.  This is either another symptom of 
the same core problem or another problem.

One possibility occurred to me looking at cmlm.C.  The archive is 
treated differently for moderated vs. unmoderated lists.  This list is 
moderated wrt to subscriptions (SUBSCRIBE=mod), but unmoderated wrt 
posting by subscribed members (POST=subscribe).  If somehow the logic in 
each of the two places where cmlm conditionally writes the archive 
decides we are in the case where it should not do the write, e.g. 
because one place tests for posting moderation and the other for 
subscribe moderation, then the precise problem observed would arise.  
I'm still trying to sort out all the logic to fully consider that or 
similar things.

Another remote possibility that occurred to me concerned ownership and 
access privileges.  The model in the cmlm doc seems to assume 
[EMAIL PROTECTED], while my case is just [EMAIL PROTECTED] where list is a 
system user who is not the person who moderates the list.  list in this 
case is sanghas and the list moderator is suga.  The dot-courier files 
are all in /home/sanghas, the cmlm list dir is in 
/home/sanghas/sanghas-list, and all of these files and directories are 
owned by the sanghas system user.  I had one problem because debian 
defaults the shell for system users to /bin/false, but I fixed that and 
changed it to /bin/bash.  So one possibility seemed that somehow cmlm 
wanted to be suga instead of sanghas when storing the archive.  As the 
archive is generated with owner-only write privileges by cmlm create and 
I have not changed that, suga cannot write to it.  However, how would 
cmlm even know the list owner is suga?  The only config that says this 
is the contents of .courier-owner in /home/sanghas, which is 
/home/suga/Maildir, and I doubt that cmlm parses that to figure out that 
suga is the real owner.  It must view sanghas as the list owner so 
everything should be fine here.

> mailman shows one list subscription for [EMAIL PROTECTED], and another 
> one for [EMAIL PROTECTED] When you switched, you probably 
> reconfigured your mail client configuration from one to the other 
> address.
>
> You can go ahead and unsubscribe one of the two addresses, by yourself.

Mea culpa.  My mail client delivers both addresses to the same inbox.  I 
haven't used alltihinglocal.com for a few years, and having had a stable 
courier implementation have been only receiving messages on this list 
during that time.  I completely forgot this subscription was originally 
for that old address.  Thanks for figuring this out.  I've fixed it.

Chuck


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to