<http://lipas.uwasa.fi/~ts/info/spamfoil.html> Copyright © 1997-2013 by Prof. Timo Salmi     Last modified Tue 5-Feb-2013 22:02:18

Counting since 8.10.1997

Spamming is futile, you will be filtered

"procmail - autonomous mail processor"

Command	What it is about
man procmail	The autonomous mail processor
man procmailex	Procmail rcfile examples
man procmailrc	Procmail rcfile

"|IFS=' ' && exec /usr/local/bin/procmail || exit 75 #myid"

whoami

pwd

/home/myid/.mail

# Environment variables for procmail
MAILDIR=/home/myid/.mail
LOGFILE=/home/myid/.mail/procmail.log

#Let's delete all email from cyberspam.com (Note here :0 not :0: *)
:0
* ^From:.*@cyberspam\.com
/dev/null

#Let's put announcements from the mailer-daemon in a special folder
:0:
* ^From:.*MAILER-DAEMON
/home/myid/.mail/Returned.mail

#Let's not directly accept mail to mailing lists, only personal email
#Note to substitute myid with your own userid on the second line
:0:
* !^TO_myid
/home/myid/.mail/ProbableSpam.mail

#Let's put all the rest in the mailbox
:0:
${DEFAULT}

         

#Environment variables for procmail, including the additions below
#Get the subject
#Discard some dangerous special chars + any leading and trailing blanks
#Note: On some systems -xSubject: has to be -x"Subject: "
SUBJECT=`formail -xSubject: \
         | sed -e 's/[;\`\\]/ /g' \
         | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`
FROM=`formail -rt -xTo: \
         | sed -e 's/[;\`\\]/ /g' \
         | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`

#Accept email having password on the subject line
:0:
* ^Subject:.*mypass
${DEFAULT}

#Send password notifications (except to your own domain)
:0:/home/myid/.elm/password.script.lock
* !^From:.*mypc.mydom
| /home/myid/.elm/password.script "${FROM}" "${SUBJECT}"

-------------------------- snip ------------------------------------
#!/bin/sh

# Ensure System V vs. BSD compatibility, get yours from your sysadmin!
#
PATH=/usr/local/bin:/usr/ucb:/usr/bin:/bin ; export PATH

# Information from the filter's command line
#
sender="$1"
subject="$2"

# Path to a temporary, auxiliary file to build the reply
#
tempfile="/home/myid/.elm/password.script.tempfile.$$"

        *************************************************
        * This is a computer-generated response message *
        *************************************************

Dear "${sender}"

Thank you for your email about
"${subject}"

...Whatever opening pleasantries.... To send email to xx@yyy.zzz
please put "password" anywhere on your subject line. ...Whatever
closing pleasantries...

xxENDITxx

rm -f ${tempfile}
-------------------------- snip ------------------------------------

-------------------------- snip ------------------------------------
#Define the password
PASSWD_=YourRequiredEmailPassword

#Whatever other recipes in between.

#Return email if the password is not there
:0:passwd.lock
#
# Check for (the lack of) the password
* $ ! ^Subject:.*${PASSWD_}
#
# Avoid email loops
* ! ^X-Loop: myid@myhost\.mydom
* ! ^From:.*myid@([-a-z0-9_]+\.)*myhost\.mydom
#
# Prepare and send the notification
# Be sure to customize your sendmail path
| (formail -r \
   -i"Subject: Returned email: Password or privileges required" \
   -A"X-Loop: myid@myhost.mydom" ; \
   echo "*************************************************" ; \
   echo "* This is a computer-generated response message *" ; \
   echo "*************************************************" ; \
   echo ; \
   echo "Email password required!" ; \
   echo "Please include (${PASSWD_}) anywhere on your subject line." ; \
   echo "Then kindly resend your email to myid@myhost.mydom") \
   | /usr/lib/sendmail -t
-------------------------- snip ------------------------------------

Further useful links about spam

Comments and Questions about Timo's Method

• The most common, but a rather ineffective safeguard is address munging, such as using ts@NOSPAM.uvasa.fi instead of the true ts@uvasa.fi. I can tell from experience that this system gradually leaks. Another, similar method is hiding behind a totally forged identity. That is something I will not do. I dislike anonymity and give very little credence to anonymous Usenet postings and email. I personally always appear with my own name and my own address.
   
  
• Blacklisting is a very common approach to the spam problem. In blacklisting one uses an email filter to automatically discard email that comes from known spammer domains or know spammer addresses or has common spam keywords (such as XXX, cable descrambler, make money fast) in the subject header. The disadvantage with blacklisting is that one has to keep updating the database and it always will leak somewhat. Furthermore, if a domain is blacklisted, nothing gets trough. Incidentally, some ISPs (Internet Service Providers) filter well-know spam sites (such as Cyberpromo) already at the system level. Ours does. But this, of course, leaks a lot.
   
  
• At one extreme, in a sense, is whitelisting. That is letting through only email that comes from users or domains that the user has privileged in his/her database. In this method all else is discarded. Used this way, the whitelisting is far too radical a method of isolation. It is very problematic for making any new contacts.
   
  
• Finally, there is the email password system. Email that has a magic keyword in the subject header or in the body of the text is allowed through. The problem with this alternative is that the sender has to know and to use the receiver's password.

1. At the core of my usage is a whitelist of domains and users whom I will always let directly through.
    
   
2. The second layer of my system is the password system. Senders not on the whitelist will get an autoresponse from me giving my simple, public email password which to put into his/her future email subject headers in order to reach me.
    
   
3. The outer layer of my system is a blacklist, which has on it some abusive or otherwise persistently irksome cases whom I don't want to hear from. The blacklisting has two main levels:
   • Automatic returning of the email, unread.
   • Automatic deletion without any further notice.
   As an aside, the latter is a convenient alternative when one is, say, on a mailing list, and one temporarily wishes to suspend receiving material from that mailing list. It is easier and less drastic than unsubscribing.
    
   
4. There is some further elaboration in my system, like fully automated spam complaints, the selective truncation of overly long messages, etc. However, the previous items gave you the general outline of the arrangement of my method. The details fine tuning are beyond this response.

All the best, Timo