Summary: Mark H. notes that as a POP client user of an ISP that runs
SA that it can be difficult configuring items that go into user_prefs
(white lists, black lists, etc).
Mark states
> Its complex and difficult to communicate with SA. I do have a shell
> account, but not everyone does, and no one should have to use the
> shell to
> configure their PC tools. However, my ISP has moved the POP server to a
> different machine than the shell server, making configuring SA more
> complicated. (we're only talking about user configuration here,
> not admin).
1. So, there are user accounts on the POP server, where user_prefs live
under the home directory? The ISP doesn't use mySQL or something else
to mange prefs do they? (that would make things more difficult).
2. If the user_prefs live under $HOME/.spamassassin/user_prefs on the
POP server, how do you access that file now? FTP from the shell account
server?
3. If you contemplated managing the user_prefs configuration via an
HTML-based web browser interface, the POP server would have to be running
a web server on the POP machine, and the web server would have to be
configured
to allow a CGI script or some other active agent on the POP machine. Further
the
CGI script would have to have access to files directly under your home
directory,
namely, .spamassassin/user_prefs, and this isn't always (generally?) the way
a
web server is set up.
Do you run procmail on the POP server? If so, with some work you can achieve
some
of your goals using procmail actions, and then build the web-based GUI on
your PC.
For exmaple, if you added a "GET USER_PREFS", and "PUT USER_PREFS" action to
your
procmailrc recipes, you'd have a method for getting a local copy of
user_prefs via
a mail client running on your PC. Using java, or perl, or some other
programming tool on
the PC, you could send an e-mail to the POP server, requesting the
user_prefs file.
Something like this:
Mail -s 'GET user_prefs' [EMAIL PROTECTED] > local_prefs
then your user config. app would run on your PC, edit your local copy of
user_prefs,
and then send it back, to updated on your POP server,
Mail -s 'PUT user_prefs' [EMAIL PROTECTED] < local prefs
Easier said than done, but a lot of this could be put together under Cygwin
on the PC
if you're Unix shell literate.
On the POP client side, the GET/PUT command might be handled this way in
your .procmailrc file:
FROM=`formail -rx To: | sed -e 's/^[ ]*//'
USER_PREFS=$HOME/.spamassassin/user_prefs`
#
# Check for GET|PUT user_prefs in the subject line
# and perform some simple validation that this is from my user id.
# Not fool proof; better would be a password in a special header field,
# or a PGP signature check.
#
:0
* ^Subject:[ ]*(GET|PUT)[ ]+user_prefs
* \FROM ?? [EMAIL PROTECTED]
{
# Handle the get operation
:0
* ^Subject:[ ]*GET
| (formail -r; cat $USER_PREFS) | $SENDMAIL -oi -t
# Handle the put operation
# we use the global $LOCKFILE here to make sure no other deliveries
# are going on while we update user_prefs.
:0Ebw:$LOCKFILE
* ^Subject:[ ]*PUT
| cat > $USER_PREFS
}
----
You can extend this idea of adding SA commands assessible by mail. Here are
a couple that
I use:
SA=/usr/bin/spamassassin
#
# Send a spamassassin spam report. The body of the e-mail
# is assumed to inclue a text attachment, and somewhere near the beginning
of the
# attachment, there's a ^From line, with the attachment proceding all the
way
# to the end of the mssage. This in fact may also pick up the line that
terminates
# the message attachment, but it's better than nothing. More correct would
be to
# use one of the MIME handling tools to extract the attachment properly.
This
# recipe provides a method to send a spam mail in for reporting.
# The Subject line has just "spam" (w/o quotes) in it, and a simple check
# is made to make sure it is from the expected user.
#
:0 b
* ^Subject: spam$
* \FROM ?? [EMAIL PROTECTED]
* ? test -x $SA
| sed -n -e '/^From/,$p' | $SA -r
#
# Add the email addressess in the body to the auto-whitelist
# Here, all lines in the _body_ of the message with From: in
# them are fed to spamassissin -W, for white listing. A similar
# interface could be set up for black listing an address.
# For whitelisting, the subject line is simply "white list".
# (w/o the quotes)
#
:0 b
* ^Subject: white[ ]*list$
* \FROM ?? [EMAIL PROTECTED]
* ? test -x $SA
| sed -n -e '/^From:/,/^$/p' | $SA -W
DISCLAIMER: These are just sketches of an implementation that uses e-mail to
effect
various spamassassin commands. The recipes would need to verified, debugged,
and
refined before they're put into production use.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
