At 4:58 PM -0400 7/21/01, Philip Guenther is rumored to have typed:
This just involves the mailspool, not .procmailrcs, right?
It _should,_ yes, although I have to admit I didn't even think about that
aspect of the problem. The RaQ3 lease is new enough that I've only started
moving domains over to it, and only discovered the problem after being a jerk
and not backing up the existing procmail (my three-year-old would have been
smarter than to pull a stunt like that). I had not added _any_ .procmailrc
files before the upgrade, so I honestly cannot say for certain. I'll be
testing that out tomorrow, though.
(Over the last couple of days, I have become terribly frustrated with the
RaQ; practically nothing is where you'd expect it to be, and what the
cobalt-users list calls the "secret sauce" is poured everywhere. If your
intention was to obfuscate linux, this is exactly what you'd come up with.)
On that
assumption, is there a regular pattern to where the mailspool
symlinks point that could be coded up in C and dropped into procmail's
src/authenticate.c file?
Yes, I think so. That is, they all point to /home/spool/mail, although
they do it in the most difficult way possible
(/home/sites/site7/../../spool/mail/username, for example). There are no
links that point anywhere except /home/spool/mail/ in /var/spool/mail/,
however.
I _thought_ maybe the original procmail binary was simply compiled with
/home/spool/mail as the MAILSPOOLDIR directory; but I got a copy of the
original from another RaQ user (one thing about cookie-cutter machines, they
really _are_ interchangable), and that doesn't seem to be the case. The admin
user receives mail at /var/spool/mail/admin, while the other GUI-created
users with the links get their mail at /home/spool/mail. And a grep of the
binary shows /var but not /home. Yippee.
I'm going to be sticking with their special 3.13.1 while I research this;
I really hope it won't cause problems with Smartlist 3.15, which I absolutely
_must_ install tomorrow (after a good night's sleep). But at least using the
"stock" 3.13.1, the domains that have been moved can get their email, so I'm
considerably less stressed than I was this afternoon.
If not, do you know whether the other mail applications, like the pop3
and imap daemons, use dotlocking? If they do, do they put the dotlocks
in the ostensible mailspool directory, or do they dotlock the 'real' path?
That I don't know, either, but will add it to all the research I need to
do. I'd like to understand what these people did to the poor OS, and
specifically track through how they are handling the mail through procmail.
Charlie
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail