At 15:59 2002-07-30 +0100, John McDermott wrote:
I have an alias -- I'll call it 'mail-alias' here -- in /etc/aliases which
corresponds to about 20 email addresses. (The addressees work on a common
project). The alias has been on a web-page for some time,
You should want to ordinal-encode it on the webpage then - the spambots
aren't too bright about handling url-encoded addresses:
<A
HREF="mailto:mail-alias@mydomain.tld";>
mail-alias@mydomain.tld</A>
(view the raw message if the above just appears to be a text
address). Even fairly old versions of LYNX support dealing with resolving
the above format. I generate URL-encoded addresses on the fly via PHP
embedded in my webpages, so when I code the pages, they're still plain
addresses, but when the pages are served up, they're "mailfuscated" at that
time. I've been using this technique about 4+ years or so now, and it's
proven VERY effective. The spam I get at the addresses which have only
been promoted through this mechanism tends to be manually harvested -
low-volume spew that someone is sending to addresses related to their own
site (and I've received only about a a half-dozen of those).
Anyway, on to the procmail question:
I move all the addresses for the alias into a text file called
addresses.txt, say. Then I change the entry for mail-alias in /etc/aliases
to read
mail-alias: "|/usr/bin/procmail /path/to/some_procmail.rc_file"
and I set entries in the file '/path/to/some_procmail.rc_file' to 1)
filter out spam and 2) forward the remaining mail to the entries in
addresses.txt.
What you're describing there is a procmail-based mailing list. Nothing new
here.
Well, I don't know if the sketch is even close. Has anyone out there done
this successfully already?
I use procmail in front of the majordomo mailing list manager to pre-filter
messages before they head into some mailing lists - that's not really a
whole lot different from what you're looking to do here, except how my
filters are obtaining the address(es) (or program to invoke, depending upon
if it is the mailing list or the listowner) to ultimatley forward to.
I'd really appreciate some pointers. If the sketch *is* the right sort of
thing, has anybody got some help for me about just what needs to go in the
.rc file?
Whatever it is you're going to do filtering with.
Start by defining a shell (your mail account user might not have one
defined). Next, consider putting the spam checking rules into external
files (/etc/procmailrcs/spam.rc or whatnot), and INCLUDERC them, thus
allowing you to re-use them for an /etc/procmailrc invoked LDA ruleset and
maintain one primary set of spam rules for all users (or all users who
actually opt in to using the rules). At the very bottom of your .rc,
forward into your list of addresses.
[/etc/aliases]
mail-alias: "|/usr/bin/procmail /etc/procmailrcs/scrubber.rc mylist"
(don't forget to rebuild your aliases - but make this change AFTER you get
the other files in place)
[/etc/procmailrc/lists/mylist]
space delimited list of recipient addresses
(start with just yourself for testing)
[/etc/procmailrcs/scrubber.rc]
# define path if necessary
SHELL=/bin/sh
# define logfile and verbosity as necessary
# include main spam rules
INCLUDERC=/etc/procmailrcs/spam.rc
# since you're forwarding, you REALLY want to watch out for mail loops..
# file however you will - but you really should FILE (or discard) it, not
# forward to an address which itself might be doing the autoreply (such as
# "vacation" crap).
:0
* ^X-Loop: list-$1
/dev/null
# tweak some headers - adding an X-Loop and precedence:
:0wfh
| formail -b -I "Precedence: bulk" \
-A "X-Loop: list-$1"
# finally, forward it
:0
! `cat /etc/procmailrcs/lists/$1`
Alternatley, you could have a separate mail alias which invokes an MTA
include for the recipient list (see the ORA "Bat" book, s25.2):
secret_mail_list: :INCLUDE:/etc/procmailrcs/lists/mylist
Then, the final rule of the procmail script would simply forward:
:0
! secret_mail_list
(OTOH, this singular address could be directly abused if someone discovered
what the address was, and it would have no loop protections).
---
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