Skip to content

Entries tagged "procmail".

They look like big, good, strong hands, don't they?

22nd December 2008

Russ Allbery recently commented that it is really nice to receive patches for trivial scripts posted online.

I agree.

More than once I've posted a trivial script and had it be improved by people, or later included elsewhere.

So in the spirit of sharing here is my latest toy script:

This is a trivial script which searches a Maildir hierarchy and outputs a list of each email address which you've ever sent mail to.

Why would you want that? In my case my (personal) spam filtering makes use of whitelisting, and the assumption is that if I've ever mailed you in the past then I want to see your replies, and you get a break.

These days my (personal) mail filtering has a couple of broad rules:

  • If your mail is HTML it is junk. Unless I'm bored.
  • If your mail is GPG signed/encrypted I will see it.
  • If your mail address is on my whitelist then I want to see it.

After that then I see your message only if CRM119 decides I should.

#
# remove potentially spoofed header
#
:0 fhw
* ^X-whitelist:
| $FORMAIL -I "X-whitelist"

#
#  GPG-signed messages are OK and will be whitelisted
#
:0fW
* < 1024000
|/home/steve/bin/isgpged

:0e
| $FORMAIL -A "X-whitelist: yes" -A "X-GPG-Signed: Yes"

#
#  Get the sender of the message.
#
FROM=`formail -x From:| sed 's/^\([^@]*[ <]\)//' | sed 's/\([ >]\).*$//'`

#
# Add a whitelist tag if appropriate
#
:0 fhw
* !^X-whitelist: yes
* ? test -s $HOME/.procmail_whitelist
* ? echo $FROM| fgrep -qisf $HOME/.procmail_whitelist
| $FORMAIL -A "X-whitelist: yes" -A "X-Whitelist-Test: $FROM"

The net result of these tests is that I can now run the spam filter on non-whitelisted mails:

#
# Run CRM114 mailreaver
#
:0fw: .msgid.lock
* !^X-whitelist: yes
| /usr/bin/crm -u /home/steve/.crm /usr/share/crm114/mailreaver.crm

#
#  Spam.
#
:0:
* ^X-CRM114-Status: SPAM.*
* !^X-whitelist: yes
.CRM.Spam/

#
#  Unsure.
#
:0
* ^X-CRM114-Status:.*UNSURE
* !^X-whitelist: yes
.CRM.Unsure/

There is more to my setup than that, but that's the minimum you'd need to see.

Of course this is a reminder, once more, that the kind of filtering that you carry out for yourself is different from that that other people will do.

ObFilm: The NeverEnding Story

Tags: mybin, namecheck, procmail, random. | 3 comments.

 

I think I did pretty well under the circumstances

13th October 2008

Procmail

This will be the last time I talk about this, but here's my anti-rubbish procmail filter.

It correctly copes with:

  • Foreign character sets that I can't read.
  • Bounces from joe-jobs.
  • Malformed emails.

Obviously edit to suit your tastes. Especially with regard to character sets - it is a wide brush which is tarring a group unfairly. That said in practise it works for me.

If you want real antispam filtering then you should probably be looking at externalising it, or having a layered approach.

ObQuote: Citizen Kane

Tags: bounces, procmail, spam. | 1 comment.

 

Fight in the shade

1st May 2008

Tonight I'm going to enjoy a nice long sleep after attending The Beltane Fire Festival yesterday evening.

I did manage to sort out an SSL certificate yesterday, before I went out. A lengthier process than expected because the SSL-registrar was annoying and mailed the admin address listed in whois for my domain; rather than an address upon the domain itself.

I guess they can't be blamed for that, and the registrar did forward on the request when begged, so it wasn't the end of the world. For reference I used godaddy.com; who sold me a 3 year SSL certificate for about £25.

Today I've been mostly catatonic because I had only two hours sleep last night. But one good piece of news was receiving a (postal) mail from Runa in response to the letter I had sent her some time ago.

ObQuote: 300

Tags: mail-scanning, procmail, ssl. | 1 comment.

 

While we live according to race, colour, or creed

2nd April 2007

I’m back from Vienna (Ask Alfie for picture(s) of me wearing my partner’s hat ..!) with a new need to update my killfile.

I use procmail to filter my mail, and my current setup looks like this:

# If the sender is in the killfile then drop the mail into killfile
:0:
# grep for it in the killfile
* ? grep -i `formail -rtzxTo:` $HOME/.procmail_killfile
/dev/null

This invokes formmail to get the sender of each incoming message and then drops the mail into /dev/null if the message is from somebody whos email address is contained in ~/.procmail_killfile – there are two problems with this approach:

  • It doesn’t handle killing threads, only senders. I guess using a similar approach to grep for message-id’s in reference would work, but I’m having a hard time thinking it through properly.
  • It doesn’t cope with people who use multiple addresses. Perhaps message-id would be useful here, although again if people use multiple sending hosts then they would have different components.

Any improved recipes are greatfully received. And that’s all I’m going to say about Debian communications for today.

Tags: killfile, megan, procmail, vienna. | No comments