At 19:25 2003-04-12 -0500, Tom Ainscough did say:
(Keep in mind that when I say, "my root" I mean the lowest directory level
that I can access via FTP.--i.e. my "/" directory. I have no telnet access.)
Your '/' directory is meaningless to us, since there is no indication that
your ftp is chrooted or what (and if so, whether it's actually chrooted to
your user dir or somewhere else). If that '/' dir you are referring to is
simply your user home dir, then it's your home dir.
For instance, all of the following dirs are meaningless without an
understanding of where that 'root' is:
/.procmailrc
/mail/.procmailrc
/mail/ainscough.com/.procmailrc
/mail/ainscough.com/tom/.procmailrc
/mail/tom/.procmailrc
/etc/.procmailrc
/etc/procmailrc/.procmailrc
As someone has already pointed out, /etc/*DOT*procmailrc isn't valid (even
assuming that the /etc/ you refer to is the system /etc). Additionally,
that file needs to be owned by root, not joe user.
I'll add to that: /etc/procmailrc/ really should be /etc/procmailrcs/ for
procmail to care what is in it, and it neither looks for .procmailrc there,
or any specific file without having been invoked to run a specific file by
name.
If your ftp root really is the SYSTEM ROOT, then amongst all of the above,
there is no reference to your home dir, which is the ONE place that a user
owned rcfile should be placed. You should at least try there. Or, is it
possible that your ISP has you set up without your own homedir? That would
be queer, but I guess it is possible.
A read of the manpage would tell you the appropriate places to put the
~/.procmailrc or /etc/procmailrc file - no need to gum up your filesystem
with files that don't do anything useful.
:0:
* ^X-Spam-Flag: YES
!spam(_at_)ainscough(_dot_)com
I'm not sure it was pointed out previously or not, but if the mail to this
spam(_at_)ainscough(_dot_)com address passes through the SAME rcfile, you're just
begging for a mail loop. I suggest you take a look at the procmail list
archives and search for "mail loop" to get a fix on what I'm talking about
here. If you cause one, there's a good chance that your sysadm will have
absolutely no interest in allowing you to run procmail on their box.
How is mail for "spam(_at_)ainscough(_dot_)com" actually routed? Is it an MTA alias,
or what?
Basically it's an internet hosting company. They have probably 20-50
domains hosted per server. I have no procmail installation in any of my
folders, so I am assuming a global install.
That'd be how procmail is normally installed, but I still don't get what
your security concern is. Have you confirmed with the admin that procmail
is on the system? Have you confirmed that it is the LDA? If it isn't the
LDA, besides needing to put your .procmailrc in your home directory (and
ensuring that the file perms are set properly), you'll need to set up a
.forward in your home directory as well.
Sorry, an unfortunate typo that turned out to be a related real word!! I
meant "main" procmail directory. In other words a global procmail recipe file.
The sysadm shouldn't put user recipes there. Besides, you won't be able to
change them when needed.
The bottom line is: I want all spamassassin tagged spam sent to the
domain "ainscough.com" to end up at "spam(_at_)ainscough(_dot_)com" rather than the
email address that it was addressed to. How it happens is not a big issue.
The:
!forward_address
Construct won't change the To: header. So, it remains that
_how_mail_gets_delivered_to_ your spambox address will greatly impact how
you try to route mail there.
You need to do the following, provided in a convenient printable checklist
form:
[ ] Spend more quality time with the procmail manpages
[ ] Determine where your user home directory is WRT your FTP login
(and whether you actually HAVE one, depending upon how your
ISP set up your account).
[ ] Better document how mail addressed to spam(_at_)ainscough(_dot_)com
is
handled, since if it passes through the same procmailrc
again, where have you gotten?
[ ] Clean up after all the various attempts at putting a .procmailrc
in almost every conceivable location except where it needs to
be.
[ ] Create a test .procmailrc file which simply logs:
# hard newline NOT a typo
NL="
"
LOGFILE=$HOME/procmail.log
LOG="We was here.${NL}"
[ ] Note that if you do not have shell access, you likely have a
unuseable SHELL setting, and so if you ever need run a shell
within your .procmailrc, you'll need to define SHELL= to be
some useable shell on your system. I might even go so far
as to add a comment to my ~/.procmailrc to note this, as
well as a big banner indicating that you don't have shell
access on the server, so that when future issues crop up
these factors will be remembered as significant.
[ ] Determine if procmail is installed as LDA (ask your sysadm)
[ ] If procmail is NOT the LDA, create a .forward file in your homedir
(see my disclaimer, I have info there)
[ ] Check perms on ~/.forward and ~/.procmailrc as per manpage
[ ] Address the loop hazard with the forward recipe (hint: "X-Loop")
before setting it up as your active mail recipe.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail