I figured out the issue by backtracing what did work, rather than chasing ghosts. Since migrated mailing lists worked fine, I created a new mailing list on my old server which is still operational for exactly this kind of reason. I migrated it's information over. While the main mailing list directory didn't work, when I moved over it's .courier files, everything started to work. I traced it down to the editor I had used to create the original .courier files on the new machine had inserted a hidden character that linux was picking up as part of the directory filename. The way I created the .courier files on the old machine didn't have this issue obviously. Even though this occurred to me as a possibility, editing the file didn't seem to get rid of this hidden character in this case (at least via the methods I originally used), so I didn't think this was still a possibility, hence coming to this list.
Such is life. Thank you all. Arthur Sam Varshavchik <[email protected]> wrote: > Arthur Moyer writes: > > > Here is me sending a new message to the list: > > > > Aug 13 19:02:17 localhost courieresmtpd: started,ip=[::ffff:127.0.0.1] > > Aug 13 19:02:17 localhost imapd: Connection, ip=[::ffff:127.0.0.1] > > Aug 13 19:02:17 localhost imapd: LOGIN, user=lordart, ip=[::ffff:127.0.0.1], > > port=[55184], protocol=IMAP > > Aug 13 19:02:17 localhost courierd: newmsg,id=0054210B.4A849B79.00000DF1: > dns; > > m.redacted.com ([::ffff:127.0.0.1]) > > Aug 13 19:02:17 localhost courierd: > > > started,id=0054210B.4A849B79.00000DF1,from=<[email protected]>,module=local,host=alias!philosophy-help!1!1!/etc/courier/aliasdir!!,addr=<alias> > > So you're delivering to an alias that's set up in the Courier alias default > directory. > > The Courier alias default is considered to be an ordinary mail account, > owned by the courier userid and groupid. That explains why you have to screw > around with mode 777. This is considered to be an ordinary account, that's > owned by the courier uid and gid. Since you've created all directories and > files there using a different userid and groupid, you have to use mode 777, > because you couldn't figure out why you were getting permission errors, so > you copped out and chmoded everything to 777. > > Solution: change the ownership of all files to the courier user and group > id, change all couriermlm cron jobs to run as the courier user and group id, > and restore sane permissions on all directories and files. > > > Here is the contents of omniphil: (Please note I manually subbed my own > > address to see if that was the issue. None of the subscribe email requests > > have ever been delivered to the mlm that I can tell) > > OmniGameServer:/home/MailLists/omniphil# ls -al > > total 260 > > drwxrwxrwx 9 root root 4096 2009-08-13 10:33 . > > drwxrwxrwx 9 root root 4096 2009-08-13 10:50 .. > > -rwxrwxrwx 1 root root 358 2009-08-12 11:58 adminrequest.tmpl > > ⦠and everything in here is now owned by root. Sigh⦠> > You can't really any meaningful investigation here, until some sanity gets > restored. > > Run 'couriermlm export' to export/salvage this mailing list's subscriber > list. > > Move this directory aside. As the courier user, run 'couriermlm create' to > recreate this mailing list directory, 'couriermlm import' to import the > saved subscriber list. Finally, cp all the .tmp files from the saved mailing > list directory into the new one (not cp -p). > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
