Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Invoking Procmail from Sendmail
and Procmail Spam filtering

News

Recommended Books

Recommended Links Tutorials Recommended Papers using dot forward file for invocation Humor Etc

Two popular set of scripts that can be used with procmail are spam bouncer and junkfilter. Both contain a lot of information on how to use it for mail filtering. Scamassassin also can be looked at but in latest version it is way too complex. 

NEWS CONTENTS

Old News ;-)

Procmail Tutorial by Jim Dennis

You could forward your mail through any arbitrary program with a .forward that consisted of a line like:
    "|$HOME/bin/your.program"
Note the quotes and the "pipe" character. They are required.

Now -- rather than saddling you with all details for how "your.program" would have to work -- what format sendmail would pass information to you, how you would return values to sendmail, how you'd handle file locking (in case more mail came in while you were processing the last one, etc) -- we'll move along to procmail specifically.

What I've discussed so far is the general information that applies to all sendmail-compatible MTA/MDA's.

One note that is well worth making is that although sendmail is designed and often run as an integrated transport and delivery, it's possible to configure a system to use procmail as the delivery agent (most of the popular Linux distributions default to this configuration, including Slackware, Red Hat, and Caldera).

In this scenario sendmail passes local mail to procmail. This makes things marginally easier as we'll soon see.

Assuming that your ISP is not so configured, you must create a .forward file to get sendmail to pass each incoming mail to procmai.

Here's the canonical example, pasted right out of the man pages:

    "|IFS=' '&&exec /usr/local/bin/procmail -f-||exit 75 #YOUR_USERNAME"
This seems awfully complicated compared to my earlier example. That's because my example was flawed for simplicity's sake.


What this mess means to sendmail (paraphrasing into English) is:
 

Pipe the mail to the following command(s):

Set the "inter-field seperator" (IFS) to a space, and -- if that went O.K. (&&) execute the program named "/usr/local/bin/procmail"

(yours may need to be different -- someone at primenet should tell you where their copy of procmail is installed, or you can try the command which procmail to see if it's on the patch or locate procmail if they are maintaining a file locator database).

The procmail program is being passed a set of switches: "-f-" which tells it to "update timestamp in the leading the 'From' line in the header"

(this last bit is rather obscure and has to do with how messages are normally stored in your "incoming" or mail file or "spool" as we Unix hacks like to call it).

The next part of this .forward command is the Bourne shell's "||" operator which is basically a continuation from the "and" (&&) operator that we used before. It says "or" (if that command didn't work -- i.e. it returned any error) than "exit" (stop processing) and return an error number 75 (which we presume is meaningful to sendmail -- the program that called this command).

The last part of this .forward expression is a comment which, according to the man pages,

is not actually a parameter that is required by proc- mail, in fact, it will be discarded by sh before procmail ever sees it; it is however a necessary kludge against overoptimising sendmail programs:
(quoting from it)
You should just change the phrase YOUR_NAME to your login name on that system.
This complicated line can be just pasted into most .forward files, minimally edited and forgotten.

If you did this and nothing else your mail would basically be unaffected. procmail would just append new messages into your normal spool file.

If your ISP uses procmail as its local delivery agent then you can skip the whole part of about using the .forward file -- or you can use it anyway.

In either event the next step to automating your mail handling is to create a .procmailrc file in your home directory. You could actually call this file anything you wanted -- but then you'd have to slip the name explicitly into the .forward file (right before the "||" operator). If you use .procmailrc than procmail will default to using it.

Now we can get to a specific example. So far, all we've talked about it how everything gets routed to procmail -- which mostly involves sendmail and the Bourne shell's syntax. Almost all sendmails are configured to use /bin/sh (the Bourne shell) to interpret alias and .forward "pipes."

procmailrules to filter out identifyable spam

Simple header rules :

A number of header things really identify spam very easily. These are sure signs of mail generated by spamming tools :

:0
* ^X-Advertisement:
spam

:0
* ^X-Advertisment:
spam

:0
* ^Message-ID: <>
spam

:0
* ^Received: from --- unknown host ---
spam

:0
* ^X-Mailer: RM-Super
* REMOVELIST:
spam

The next ones are a bit trickyer. They work by the idea that I don't have an account on sites used in the To: line of a lot of spam. But I did have to revise this as I sometimes recieve mail also aimed at an account there.

:0
* ^To:.*@(mail-response|msn|aol|public|hotmail|webavenues|netcom|ix.netcom)\.com
* !^(To|Cc):.*(koos|kh)@
spam

:0
* ^To:.*@(mts|usa)\.net
* !^(To|Cc):.*(koos|kh)@
spam

Including ofcourse the by now famous 'friend@public.com'. I pity whoever registered public.com. The check for mail not to 'koos@' is to make sure it's not by accident mail for a number of people including an account on one of those sites *and* me. That's valid mail.

The next set is 'famous spam relays'. The choice of addresses is purely from my own experience.

:0
* ^Received: from .*(mail.mymail.net|tsf-industries|spamrelay|flash.net|freemanchester.com|ultramax.net)
spam

O'Reilly Network Filtering Spam with Procmail [Jan. 10, 2002] -- into to Junkfilter and Spambouser

In the last article, we installed the procmail utility and generated a few basic recipes. This week, let's start by looking at procmail's built-in logging mechanism. We'll then take a look at some other available resources that build on procmail's capabilities.

On your FreeBSD system, there is a utility called mailstats that gives you statistics on how many messages were handled by the sendmail program

... ... ...

This site has an excellent list of resources that deal with procmail, including spam resources.

This site is a goldmine of procmail FAQs, tips, and resources, and is well worth bookmarking for future reference.

 both of which are in the FreeBSD ports collection. This makes their installation painless. You'll find, though, it will take some trial and error on your part to tweak any spam filter to suit your needs. Also, no spam filter can be 100% accurate, as there will always be legitimate users that have email accounts with blocked domains and spammers are always trying to find new ways to bypass spam filters.

http://junkfilter.zer0.org/  junkfilter is copyright 1997-2002 Gregory Sutter.

junkfilter is a procmail -based filter system for electronic mail. Procmail is a popular and powerful mail-processing program available for Unix systems. junkfilter filters sex spam, MLM schemes, and all other types of unsolicited commercial e-mail (UCE). End spam -- filter it!

The SpamBouncer a Procmail-Based Spam Filter

The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email to see if it meets one or more of the following conditions:

The SpamBouncer sorts suspected spam into three categories -- email sent by a virus, email from known spam sources which is definitely spam, and email which is probably spam, but might also be legitimate. It then tags each email with appropriate headers for the spam classification, and responds according to the parameters you have set.

The FreeBSD Diary -- Setting up Spam Bouncer

Alcor On-Line Help catching spam with procmail

DevX: Procmail 'Passthrough' Partners for Powerful E-mail Filtering(Dec 20, 2001)

Linux Gazette: Stopping Spam on Your Linux Box (May 12, 2001)

LinuxWorld: Ask the Geek: Fight spam with procmail(Mar 02, 2001)

Your first e-mail filter
We rely on procmail for automating e-mail traffic. We'll focus on it's installation and use (for an overview of the procmail utility (see Resources below).

First, verify that procmail is installed on your host. Most ISPs that provide shell access make it available as /usr/local/bin/procmail/var/bin/procmail, or some local variation. Corporate networks are less likely to have procmail, so don't be surprised if you can't find it on your host. The directions available at the procmail home page are easy, so you or your sysadmin will have it up and running in short order.

Once you've confirmed that procmail is available as a Unix executable, take these steps:

  1. Create the file $HOME/.procmailrc with contents:
    	VERBOSE=on
    	MAILDIR=$HOME/mail
    	PMDIR=$HOME/.procmail
    	LOGFILE=$PMDIR/log
    	INCLUDERC=$PMDIR/rc.personal
    
  2. Create the file $HOME/.procmail/rc.personal with contents:
    	:0:
    	* ^Subject.*cable descrambler
    	discard
  3. Create the file $HOME/.forward with contents:
    	"|IFS=' ' && exec /usr/local/bin/procmail -f || exit 75 #YOUR EMAIL NAME"
    

    This is the step that's likely to involve the most variation from one system to another. In the last item in the Resources list below, we list the .forward commands we've found to work best under a variety of operating systems.

  4. Set necessary permissions with the commands:
    	chmod 644 $HOME/.forward
    	chmod a+x $HOME
  5. Test the filter by typing the four lines:
    	sendmail YOUR_EMAIL_ADDRESS
    	Subject: send us money
    	blah, blah
  6. And then the four lines:
    	sendmail YOUR_EMAIL_ADDRESS
    	Subject: send us money for our cable descrambler
    	blah, blah

What you should see now is that you have one new mail message, with the subject line, "send us money." You'll also have a new file, $HOME/mail/discard, that holds the "send us money for our cable descrambler" message.

You're in business. You now have the means to protect yourself from messages you don't want to see.

Variations on a theme
There are many steps you'll want to take to improve your filter. You can add a second rule, and your ruleset becomes:

	:0:
	* ^Subject.*cable descrambler
	discard

	:0:
	* ^Subject.*adults only
	discard

You can filter out messages from sites notorious for their junk:

	:0:
	* ^From: CyberMarketing@hotmail.com
	discard
or from suspicious-looking people:	
	:0:
	* ^From anonymous
	discard

	:0:
	* ^From bulk
	discard   

You'll probably want to throw away the electronic equivalent of "Deliver to Resident" messages,

	:0:
	* ^To:.*public.com   
	discard

as well as anything courteous enough to announce itself as an unsolicited advertisement:

	:0:
	* ^X-Advert
	discard

 

Recommended Links

Softpanorama Top Visited

Softpanorama Recommended

 

Tutorials

Configuring Procmail as a Sendmail rule-invoked mailer

This is a basic tutorial on how to invoke procmail from within a sendmail ruleset (not as Mlocal, but actually invoked during mail processing, with the express intention of having sendmail continue to process a message which procmail may have changed in some fashion).

John Hardin has a writeup on configuring Procmail within a sendmail gateway, which is a similar process.

Let me start with a few disclaimers - these are rough notes from when I performed such a test on a Sendmail 8.10.x system (i.e. some time ago) with the mere intent of learning how to do it myself so that users who insist on repeatedly asking for this info on the procmail list can be directed to a page laying out the details for them, even though it is really SENDMAIL trickery and the procmail manpage ('man procmail') already provides the basic framework. I do not utilize this approach - I personally have no need for invoking procmail from within sendmail rulesets, and certainly not enough of one to justify the additional processing overhead which it involves. I WILL NOT answer private inquiries for assistance, unless they accompany a service contract and an appropriatley negotiated retainer (US$ only please). I am dead serious. I'm not in the business of taking blame or becoming someone's tecnical crutch or emergency repairman when they take it upon themselves to diddle with the internal mechanisms of tools which they don't fully comprehend.

If you don't maintain your sendmail config using .M4 files, then shame on you. If you don't know about the .M4 config files, and the "make" process for them, then you want to get acquainted with that before proceeding here. It is enough that I'm spelling out this hack, but I am NOT going to re-document sendmail too.

Let me give you clear warning: screwing with your procmail config can cause mail to JUST DISSAPPEAR. Gone. Poof. The only trace you'll have might be mention of it in your system logs. Experienced techs know that the best way to test sendmail configurations is in a sandbox - on a server set aside specifically for performing those tests. Well, at least not a server used for regular mail processing - I use a security monitoring host which isn't used in any fashion for email - it isn't an MX, and there are no users on it (or a web server, etc) to be generating messages. If you do development changes to a live mail server, you won't find any sympathy with me if something goes sour on you.

Your application of any information gained from this document is entirely at your own risk - there are many variables in play, not the least of which are your sendmail version and other sendmail configuration options you may have in effect.

Having said that, using procmail from within sendmail isn't really all that difficult - if you understand the sendmail config file syntax (having a copy of the ORA "Sendmail" book (or the ORA Bookshelf CD version) to reference would be a good idea).

Many people errantly use MAILER(`procmail') in their sendmail M4 config files when initially setting up sendmail to use procmail, when all they're trying to do is set up sendmail to use procmail as the LDA. For that, they need to use FEATURE(`local_procmail') - which sets the Mlocal properly. the MAILER definition has *NOTHING* to do with procmail as the LDA, and is unnecessary unless you're trying to invoke procmail from within sendmail rulesets.

In your config.mc you'd add MAILER(`procmail') on a line BEFORE MAILER(`smtp') (remember, the config is processed in reverse or something like that). Build the config.cf file, make any manual edits you might have to make, then (usually in ruleset 0, or "Sparse=0"), add something like the following (note that with the supplied .m4 file below, this is already done):

R$*	$: $>ProcmailHandler $1		# procmail filtering

 

I'm using the newer sendmail syntax for ruleset labelling - you can use names instead of just numerics. Now, somewhere else in the file - I typically do it down below, but in any event, you should be careful to ensure that it is BETWEEN rulesets or definitions, not dropped in the middle of one, add:

You may download this file as ProcmailHandler.m4.

divert(-1)
#
# Copyright (c) 2002 Professional Software Engineering.
#	All rights reserved.
#
# By using this file, you agree to hold the author and it's agents harmless.
#
# The rules provided herein are intended only to demonstrate the basic
# functionality of procmail as a sendmail rule-invoked mailer.
#
# 
#

ifelse(defn(`_ARG_'), `',
	ifdef(`PROCMAIL_MAILER_PATH',
		PROCMAIL_MAILER_PATH,
		`/usr/local/bin/procmail'),
	_ARG_))

divert(0)
VERSIONID(`$Id: procmailhandler.m4,v 8.12 2002/02/01 12:58:08 sbs Exp $')

MAILER(`procmail', PROCMAIL_MAILER_PATH)dnl

LOCAL_RULE_0
R$*	$: $>ProcmailHandler $1		# procmail filtering

LOCAL_RULESETS
SProcmailHandler
# Following three lines are from Adrezej Filip on comp.mail.sendmail 20030412
# This allows sendmail to ignore the hack when it processes newaliases
R$*	$: <${opMode}> $1
R<i>$*	$@ $1
R<$*>$*	$: $2

# parse for local users (single token, no domain)
# note that depending upon where you place the hook for this ruleset,
# this may occur before or after sendmail expands aliases which may
# resolve an apparent local delivery to a remote address - place your
# hook as you see fit.
R$- .procmail
	$@ $1
	# procmail has already looked at this
R$-
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 . procmail
	# invoke procmail

# parse for canonical domains
# (resolved domains will have a dot trailing the domain name)
R$* < @ $+ .procmail >
	$@ $1 < @ $2 . >
	# procmail has already looked at this.
R$* < @ $+ . >
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 < @ $2 .procmail >
	# invoke procmail

# parse for non-resolveable canonical domains
# (unresolved domains will NOT have a dot trailing the domain name)
R$* < @ $+ .xprocmail >
	$@ $1 < @ $2 >
	# procmail has already looked at this.
R$* < @ $+ >
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 < @ $2 .xprocmail >
	# invoke procmail

# other examples would include filtering for a specific user address or
# hostname/domain or inbound vs. outbound.  Handle more specific cases FIRST.

divert(0)

As with all sendmail rules, there is a TAB between the LHS and RHS, and if you continue a line, it should start with a TAB. The trailing dot in the above expressions is there because in my sendmail config (which other current sendmails should be very similar to) canonicalizes the address to include a trailing dot.

In your /etc/procmailrcs/outbound.rc, you'd have something like:

#
# This is a simple script intended to demonstrate sendmail rule-invoked
# procmail filtering.
#

DEFAULT=|
SHELL=/bin/sh
LOGFILE=/etc/procmailrcs/outbound.log
VERBOSE=ON

# grab the arguments from the commandline and put them into variables.
USER=$1
REC=$2

# copy *ALL* messages.  This is just an example.
:0c:
/etc/procmailrcs/outbound.copy

# rewrite certain message to include a trailing disclaimer
:0f
* USER ?? someusername
* ^From:.*someusername@host\.domain\.tld
| cat - /etc/procmailrcs/trailer.sig

# Pass along all other mail (or filtered messages)
:0
! -f "$@"

 

This file should have appropriate ownership and security settings (i.e. don't make it group or world writeable - and probably, you don't even want it readable by anyone other than owner).

Now, to explain. Mprocmail is the procmail mailer - it tells sendmail how to invoke procmail and what options to apply to it, etc. The specifics are uninmportant to the basic implementation - it is handled just like Mlocal or Mprog according to your config. In the standard MAILER definition, procmail is handed the rcfile, the sender address/username, and the recipient username/addresses(s). The rcfile above takes the two commandline options (things specified after the rcfile) and assigns them to variables which it can then use.

For EXAMPLE purposes only, we have VERBOSE logging on and are dumping to a logfile. You wouldn't want that enabled on a regular high-traffic mailspool. Also for EXAMPLE purposes, there is a rule which uses the 'c'opy flag to make a copy of the messages passing through this rc and store them to a mailbox file. Yup, instant copy of inbound and outbound message traffic (at the moment, the rcfile has no idea whether the message is inbound or outbound - that's a function of the sendmail ruleset you use to invoke it, and where you perform that invocation). Next in the example is something that checks whether the sending user is a specific username and the From: field contains their address (you might do either, but this is intended to catch LOCALLY generated messages where the user MIGHT change the From: field, or be using procmail to forward a message (which you might not want to append the disclaimer to). Anyway, the filter rule pipes through to cat which takes the original message and follows that with the signature text (in my test case, it is a truely obnoxious parody of the legal disclaimers some offices stuff on all of their outbound messages). Now, this was just a FILTER rule, so the (modified) message continues along to the next rule - as would any message which didn't meet the conditions to be filtered - that last rule (which you should recognize from the procmail manpage, 'cept for the omission of the '-oi') delivers the message to sendmail ensuring to set the -f (sender) address to the same address we received it from.

Yes, it is unfortunate that the invocation of mailers from sendmail doesn't allow them to simply be piped through, but in sendmail's mind, once it invoked the procmail mailer (Mprocmail), it was delivered, so for procmail to have sendmail continue processing it, it must invoke sendmail with the message.

Now, we've covered the back end, but I haven't yet explained the sendmail rules. I should preface this by saying that the specific rules you might choose to use from sendmail are your business, and are something you should follow up in a sendmail support forum (news:comp.mail.sendmail perhaps), as, with the exception of invoking procmail, they don't really pertain to procmail at all. That said:

We inserted the following rule into the parse ruleset:

R$*	$: $>ProcmailHandler $1		# procmail filtering

 

The LHS says "does this match ANYTHING?" If so, then the RHS gets processed, which says "Okay, then, call the ProcmailHandler ruleset with the argument we're parsing".

Elsewhere in the .cf, we introduced the ProcmailHandler ruleset (see above).

It is important to remember that the rules there are separate - although related - rules. On a call to the ProcmailHandler ruleset, ONE of these will take effect (or none will, if there is no match), and will return to the caller without invoking the other. It is for this reason that we check for the .procmail ones first within each pair (since the final rule above would gladly match most messages even if .procmail is already appended).

The first pair of rules operate on single token addresses: that being a local type address consisting of just a username. The second pair operate on canonically resolved addresses. Within each pair, the first one says "if we match an address with a .procmail at the end, then strip that .procmail bit out (this is what cleans up the rewritten address after procmail is invoked). The other rule says that if we have an address (presumed at this point to NOT have a trailing .procmail), then invoke our procmail mailer and also change the address (this is how we ensure that we don't execute procmail a second time when the message is re-introduced into sendmail).

It might help if you create a config file with the above rulesets, then execute:

sendmail -bt -ctesting.cf
> 3,0 someuser
> 3,0 someuser.procmail
> 3,0 someuser@domain.tld
> 3,0 someuser@domain.tld.procmail
> 3,0 someuser@bogusdomain
> 3,0 someuser@bodusdomain.procmail

 

You should find that the non-.procmail versions end up parsing into a .procmail version and showing that the procmail mailer would have been called. If you parse the .procmail versions, you'll see that they get resolved down to a local or (E)SMTP delivery as appropriate, with the .procmail portion stripped out. Note that with the canonical domain stuff here, the domain.tld should actually be RESOLVEABLE - if you need to deal with unresolvable domains (why? Surely if you're dealing with a bogus domain, you'd at least locally resolve them in /etc/hosts, right?), you'll need to clone the second pair of rules and remove the trailing dot and tweak the .procmail bit to something slightly different (so that the original rule above doesn't add a dot where it isn't appropriate when rewriting). In the ruleset above (and in the .M4 file linked below), I've included this rule, but you really shouldn't need it.

Because of the broadness of the last expression, you'd want this AFTER the version which handles resolveable hosts ( the $+ would gladly match a hostname with a trailing dot). Specifically, you don't want a rewritten host like : somehost.domain.tld..procmail (note TWO dots). Go ahead, and move the last two rules up and run the address tests again and see what you get, then switch them back so that it isn't broken.

In any event, if the second rule (in any pair) matches, then we'll invoke the procmail mailer on this message and rewrite the recipient address to include the .procmail bit. The above address test will demonstrate this at work.

I've created a HACK (that's a real sendmail macro - just like FEATURE and MAILER) file for the above, which you can add to your sendmail config tree:

/usr/src/sendmail/cf/hack/ProcmailHandler.m4

Then add the following to your config.mc file AFTER your MAILER(`smtp') line:

HACK(`ProcmailHandler')dnl

This will add the MAILER(`procmail') and the necessary rules to your generated .cf file. You'll still need to verify the procmail path (which you can conveniently specify as a second parameter to the HACK macro above), and create the /etc/procmailrc/outbound.rc file and necessary filters, but otherwise, it should work.

Something to note is that in doing this, virtually every email passing through your sendmail will generate an extra process (procmail), plus additional processes beyond that (if procmail runs any shells or other programs in pursuit of the checks/filters), and another sendmail process if procmail actually filters the message rather than discarding it. The additional invocation of sendmail will carry with it the introduction of an additional Received: header as well, indicating the message was received from root@localhost.

procmail-on-gateway

Implementing procmail on a sendmail 8.8.8 and later gateway:
(Note: This is still undergoing testing and refinement)
$Id: procmail-on-gateway.txt,v 1.9 2002-01-12 16:41:00-08 jhardin Exp jhardin $
<jhardin@impsec.org>
With help from Joshua Marshall <marshallj@switch.aust.com>


1. Add the following delivery agent:

Mprocmail,      P=/usr/bin/procmail, F=DFMmShun, S=11/31, R=21/31, T=DNS/RFC822/X-Unix,
                A=procmail -m $h $g $u

   [TAB]---^



2. Add "procmail" to class P with this somewhere near the top
of your sendmail.cf (near where the other classes are being set up):

  CPprocmail



3. Add the following to ruleset 0, between the "handle virtual
users" and "short-circuit local delivery" stanzas:

# pipe through procmail for processing
R$*<@example.com>$*     $#procmail $@/etc/procmail/filter.rc $:$1<@example.com.procmail.>$2
R$*<@example.com.>$*    $#procmail $@/etc/procmail/filter.rc $:$1<@example.com.procmail.>$2
R$*<@$*.procmail.>$*    $1<@$2.>$3

   [TAB]-------------^

Vary the domain name and script name (/etc/procmail/filter.rc) for your needs.

If you are relaying mail for multiple domains, use the following instead:

R$*<@$=w>$*             $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$=w.>$*            $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$*.procmail.>$*    $1<@$2.>$3

   [TAB]-------------^



If you prefer to use sendmail .mc files, add this to your config.mc file:

LOCAL_CONFIG
CPprocmail

LOCAL_RULE_0
R$*<@$=w>$*             $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$=w.>$*            $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$*.procmail.>$*    $1<@$2.>$3

MAILER_DEFINITIONS
Mprocmail,      P=/usr/bin/procmail, F=DFMmShun, S=11/31, R=21/31, T=DNS/RFC822/X-Unix,
                A=procmail -m $h $g $u



4. Here is a sample filter.rc file - add your local configuration
   settings before using it:

################################################################
#
# procmail rules to filter mail on a gateway
#

LOGFILE=/var/log/procmail.log
NL="
"
LOGABSTRACT=no

# Configuration settings go here...
# See the discussion of what to put in /etc/procmailrc at
# http://www.impsec.org/email-tools/sanitizer-configuration.html
# /etc/procmailrc is the "master procmail script" for local
# delivery, this file is the "master procmail script" for relay
# The settings in one DO NOT affect the other.

POISONED_EXECUTABLES=/etc/procmail/poisoned

# etc... - you NEED to put configuration settings here.
# NB: DO NOT enable RECIPIENT notification on a relay...

# run the sanitizer
INCLUDERC=/etc/procmail/local-rules.procmail
INCLUDERC=/etc/procmail/html-trap.procmail

# send the mail on to the next relay
:0
! -oi -f "$@"

#
################################################################



5. If the next hop is a Microsoft Exchange Server, make sure that you
configure it so that it will accept mail addressed to its
fully-qualified domain name in addition to the simple domain name.
For example, if your domain is "example.com" and your Exchange Server is
running on the computer named "exchange", configure it to accept mail
addressed to "@exchange.example.com" as well as just "@example.com"

 

Recommended Papers

O'Reilly Network Filtering Spam with Procmail [Jan. 10, 2002] -- into to Junkfilter and Spambouser

In the last article, we installed the procmail utility and generated a few basic recipes. This week, let's start by looking at procmail's built-in logging mechanism. We'll then take a look at some other available resources that build on procmail's capabilities.

On your FreeBSD system, there is a utility called mailstats that gives you statistics on how many messages were handled by the sendmail program

... ... ...

This site has an excellent list of resources that deal with procmail, including spam resources.

This site is a goldmine of procmail FAQs, tips, and resources, and is well worth bookmarking for future reference.

 both of which are in the FreeBSD ports collection. This makes their installation painless. You'll find, though, it will take some trial and error on your part to tweak any spam filter to suit your needs. Also, no spam filter can be 100% accurate, as there will always be legitimate users that have email accounts with blocked domains and spammers are always trying to find new ways to bypass spam filters.

The SpamBouncer a Procmail-Based Spam Filter

The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email to see if it meets one or more of the following conditions:

The SpamBouncer sorts suspected spam into three categories -- email sent by a virus, email from known spam sources which is definitely spam, and email which is probably spam, but might also be legitimate. It then tags each email with appropriate headers for the spam classification, and responds according to the parameters you have set.

The FreeBSD Diary -- Setting up Spam Bouncer

Alcor On-Line Help catching spam with procmail

DevX: Procmail 'Passthrough' Partners for Powerful E-mail Filtering(Dec 20, 2001)

 
Re: Invoking procmail from sendmail
Author:   Per Hedeland <per@erix.ericsson.se>
Date:   2000/05/12
Forum:   comp.mail.sendmail

...

>I read somewhere that you can invoke procmail from within sendmail. How
>do I do that? Does that mean that some filtering can be done in
>sendmail?

Summarized from another recent thread - this will send all mail through
procmail.

Put this in your .mc file:

FEATURE(`mailertable')
MAILER(`procmail')

LOCAL_CONFIG
CP PROCMAIL

LOCAL_RULE_0
R$*				$: <> $1			mark all
R<> < @ $* > $*			$: < @ $1 > $2			skip route-addr
R<> $* < @ $* . PROCMAIL . >	$: $>3 $1 @ $2			already filtered
R<> $* < @ PROCMAIL . >		$: $1				already filtered
R<> $* < @ $* . >		$: <> $1 < @ $2 >		remove dot
R<> $* < @ $* >			$: $1 < @ $2 . PROCMAIL . >	send to procmail
R<> $*				$: $1 < @ PROCMAIL . >		send to procmail

And in your mailertable:

PROCMAIL   procmail:/etc/procmailrcs/some.rc
.PROCMAIL  procmail:/etc/procmailrcs/some.rc

See cf/README in the sendmail distribution, and the procmail man page,
for further details.

You may also want to use

MODIFY_MAILER_FLAGS(`PROCMAIL', `+m')

or for pre-8.10 sendmail

define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m')

in your .mc file - this will improve performance by sending mail for
multiple recipients through a single invocation of procmail, but makes
address-based processing in the procmaillrc trickier.

--Per Hedeland
per@erix.ericsson.se

Discussion

Subject: Re: sendmail 8.9.3 on Solaris - Blocking Attachments
Date: 05/19/2000
Author: sendmail <sendmail@ragnark.vestdata.no>

On Fri, May 19, 2000 at 08:31:37AM -0400, Joe Borgia wrote:
> Anyone know of a way to block *.vbs, *.exe, *.com files in sendmail
> running
> on Solaris. It's sendmail.org's version of sendmail, but it's running on
> Solaris. Most
> of what I've seen here in this group talks about blocking on Linux boxes
> using procmail. Honestly, I don't know what procmail does, and I don't
> believe it's
> running on our sendmail server.
 
procmail is a MDA (mail delivery agent). It's task is to deliver your the incomming mail to the local users on your server.
 
Sendmail can use procmail or any other MDA. Run `grep Mlocal
/etc/sendmail.cf` to see what MDA is default in your setup.
 
All this software probably works just as well on Solaris as on linux. You can use the procmail-filters you refer to, or you can use
mailchecker (search on sourceforge.net). It's software written
specificly for sorting out dangerous mail-parts. (not well tested - prepare to work a little bit)
 
 
--
Ragnar KjЃшrstad

 

Subject: Re: File attachments: filtering out
Date: 05/19/2000
Author: Frank Hahn <fhahn@yahoo.com>

On Thu, 18 May 2000 21:52:20 +0100, A Pietro <apietro@my-deja.com> wrote:
>How can I filter out email messages which have file attachments?
>
>Do I use something called procmail.rc -- I think this file has rules to
>filter spam?
>Do I look for a certain type of header?
>
If you have procmail installed, the following might help:
 
ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html

See also ftp://ftp.rubyriver.com/pub/jhardin/antispam/html-trap.procmail
 
There are many other ways to do something similiar.
 
--
Frank Hahn

A fool must now and then be right by chance.

 

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/07/2000
Author: Per Hedeland <per@erix.ericsson.se>

In article <391377d3.208763@news.escape.ca> sean@ertw.com (Sean
A. Walberg) writes:
>On this thread, how would one hack sendmail to use procmail in a
>non-local-delivery sense, ie passing all mail on a hub through
>procmail before it gets sent out or to the mail server?  The man page
>for procmail requires that the domain be static, in which case it only
>works for incoming mail.
 
Well, it's just an example... - you could do something like this to send all mail through procmail (untested!):
 
FEATURE(`mailertable')
MAILER(`procmail')
...
 
LOCAL_CONFIG
CP PROCMAIL
 
LOCAL_RULE_0
R$*    $: <> $1  mark all
R<> $* < @ $* . PROCMAIL . > $* $: $>3 $1 < @ $2 > $3  already filtered R<> $* < @ PROCMAIL . >  $: $1    already filtered
R<> $* < @ $* > $*  $: $1 < @ $2 . PROCMAIL . > $3 send to procmail R<> $*    $: $1 < @ PROCMAIL . >  send to procmail
 
And in mailertable:
 
PROCMAIL  procmail:/etc/procmailrcs/some.rc
.PROCMAIL  procmail:/etc/procmailrcs/some.rc
 
One un-nice thing about it is that the recipient address(es) will have .PROCMAIL (@PROCMAIL for unqualified addresses) appended while in the procmailrc, i.e. you need to take that into account if doing
address-based processing.
 
--Per Hedeland
per@erix.ericsson.se

 

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/07/2000
Author: Per Hedeland <per@erix.ericsson.se>

In article <Pine.GSO.4.05.10005071536430.14118-100000@wpg-14.escape.ca>
"Sean A. Walberg" <sean@escape.ca> writes:
>And I can see it in the queue.  Now I push it out:
>[root@phoenix mqueue]# sendmail -qRswalberg@exchange.hsc.mb.ca
><swalberg@exchange.hsc.mb.ca>... Host unknown (Name server:
>exchange.hsc.mb.ca..procmail.: non-recoverable error)
><sean@escape.ca>... Host unknown (Name server: escape.ca..procmail.:
>non-recoverable error)
 
There is a bug in the rules I gave, resulting in the double dot before 'procmail'. Here's an updated version:
 
R$*    $: <> $1  mark all
R<> $* < @ $* . PROCMAIL . > $* $: $>3 $1 < @ $2 > $3  already filtered R<> $* < @ PROCMAIL . >  $: $1    already filtered
R<> $* < @ $* . > $*  $: <> $1 < @ $2 > $3  remove dot R<> $* < @ $* > $*  $: $1 < @ $2 . PROCMAIL . > $3 send to procmail R<> $*    $: $1 < @ PROCMAIL . >  send to procmail
 
However it seems you also don't have the mailertable working - test it:
 
sendmail -bt
> /map mailertable procmail
> /map mailertable .procmail
 
>Though what I don't understand why the address doesn't get rewritten,
 
It clearly does get rewritten, note the
 
Name server: exchange.hsc.mb.ca..procmail.: non-recoverable error
 
message. The error reports the original address though, as it should.
 
>when:
>
>> [root@phoenix mqueue]# sendmail -bt      
>ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Enter <ruleset> <address>
>> 0 swalberg@hsc.mb.ca
 
That isn't a proper test, you need
 
> 3,0 swalberg@hsc.mb.ca
 
- without the pass through ruleset 3, it is effectively treated as if it were a simple username.
 
--Per Hedeland
per@erix.ericsson.se

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/09/2000
Author: Per Hedeland <per@erix.ericsson.se>


<< previous in thread  ∑  next in thread >>
 

In article <Pine.GSO.4.05.10005071951470.14118-100000@wpg-14.escape.ca>
"Sean A. Walberg" <sean@escape.ca> writes:
>This time when I send from sean@escape.ca to swalberg@exchange.hsc.mb.ca,
>I get
>
>Message comes in:
>TAA17826      197 Sun May  7 19:56 <sean@escape.ca>
>      <swalberg@exchange.hsc.mb.ca>
>[root@phoenix cf]# sendmail -qRswalberg@exchange.hsc.mb.ca
>TAA17853 197 Sun May 7 19:57 sean@escape.ca
>      swalberg@exchange.hsc.mb.ca.PROCMAIL
>[root@phoenix cf]# sendmail -qRswalberg@exchange.hsc.mb.ca.PROCMAIL
>TAA17853      197 Sun May  7 19:57 sean@escape.ca
>                (Deferred: Connection refused by messenger.hsc.mb.ca.)
>      swalberg@exchange.hsc.mb.ca.PROCMAIL
>
>Messenger is disabled, but should the .PROCMAIL be there?
 
Yes, assuming it has been through procmail, that's the way it'll be sent back to sendmail, and thus appear in the queue if queued.
 
> Going the
>other way around (from hsc.mb.ca to escape.ca)
>
>[root@phoenix /root]# sendmail -qRsean@escape.ca
>[root@phoenix /root]# mailq
>                Mail Queue (7 requests)
>--Q-ID-- --Size-- -----Q-Time-----
>------------Sender/Recipient------------
>TAA17775      10 Sun May  7 19:54 swalberg@exchange.hsc.mb.ca
>                                  sean@escape.ca.PROCMAIL
>[root@phoenix /root]# sendmail -qRsean@escape.ca.PROCMAIL
>sean@escape.ca.PROCMAIL... User unknown
 
Grumble... When I wrote "untested", I was hoping to not having to bother testing them...:-) Anyway, I'm not sure that's the cause of what you're seeing, but there's another bug in the rules - also, trying to handle "route-addrs" (<@foo,@bar:user@baz>) is futile, they won't work when passed to procmail and back (and no-one uses them, and they're stripped down by default in 8.10 anyway). So, yet another version:
 
R$*    $: <> $1  mark all
R<> < @ $* > $*  $: < @ $1 > $2  skip route-addr R<> $* < @ $* . PROCMAIL . > $: $>3 $1 @ $2  already filtered R<> $* < @ PROCMAIL . >  $: $1    already filtered
R<> $* < @ $* . >  $: <> $1 < @ $2 >  remove dot R<> $* < @ $* >  $: $1 < @ $2 . PROCMAIL . > send to procmail R<> $*    $: $1 < @ PROCMAIL . >  send to procmail
 
If you still have problems with the above, try in -bt mode:

Just to follow up on this, it's been working great for a couple of days now.
 
One thing to note is that multiple recipients seem to get expanded to one run through procmail per address.  Not a big deal until you try to cram through a couple of thousand emails at once, ie a list.  Once I upped the max files allowable all was well.
 
Once again, many thanks!
 
Sean
 
On Tue, 09 May 2000 01:19:59 GMT, sean@ertw.com (Sean A. Walberg)
wrote:
 
>On 9 May 2000 00:36:58 GMT, per@erix.ericsson.se (Per Hedeland) wrote:
>
>>Grumble... When I wrote "untested", I was hoping to not having to bother
>>testing them...:-) Anyway, I'm not sure that's the cause of what you're
>>seeing, but there's another bug in the rules - also, trying to handle
>>"route-addrs" (<@foo,@bar:user@baz>) is futile, they won't work when
>>passed to procmail and back (and no-one uses them, and they're stripped
>>down by default in 8.10 anyway). So, yet another version:
>>
>>R$*    $: <> $1  mark all
>>R<> < @ $* > $*  $: < @ $1 > $2  skip route-addr
>>R<> $* < @ $* . PROCMAIL . > $: $>3 $1 @ $2  already filtered
>>R<> $* < @ PROCMAIL . >  $: $1    already filtered
>>R<> $* < @ $* . >  $: <> $1 < @ $2 >  remove dot
>>R<> $* < @ $* >  $: $1 < @ $2 . PROCMAIL . > send to procmail
>>R<> $*    $: $1 < @ PROCMAIL . >  send to procmail
>
>This seems to work for incoming mail, but I've yet to test it for
>outgoing.  I'll follow up tomorrow when I can test it fully.
>
>I've already had a couple of people ask about some of my other queries
>regarding this topic, once I get it all working I'll write it up and
>post a URL so you shouldn't have to answer this again :)
>
>Thanks again,
>
>Sean
>
>---
>Sean Walberg <sean at ertw dot com>  http://www.ertw.com
>Winnipeg Linux/Unix events      http://linux.ertw.com
 
---
Sean Walberg <sean at ertw dot com>  http://www.ertw.com
Winnipeg Linux/Unix events      http://linux.ertw.com

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/11/2000
Author: Per Hedeland <per@erix.ericsson.se>


<< previous in thread  ∑  next in thread >>
 

In article <3919e88e.54348@news.escape.ca> sean@ertw.com (Sean
A. Walberg) writes:
>Just to follow up on this, it's been working great for a couple of
>days now.
 
Good to hear that it finally worked!:-)
 
>One thing to note is that multiple recipients seem to get expanded to
>one run through procmail per address.
 
Yes, this is because MAILER(`procmail') doesn't have the 'm' flag - you can add it with
 
define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m')
 
or nicer in 8.10
 
MODIFY_MAILER_FLAGS(`PROCMAIL', `+m')
 
The reason 'm' isn't set by default is, I believe, that it makes it *really* tricky to do processing based on the recipient address in the procmailrc.
 
>  Not a big deal until you try to
>cram through a couple of thousand emails at once, ie a list.  Once I
>upped the max files allowable all was well.
 
Hm, max files in your OS settings? There'll still be a rather heavy load due to the many (and unnecessary if you don't do address-based
processing) invocations of procmail.
 
--Per Hedeland
per@erix.ericsson.se

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/11/2000
Author: Sean A. Walberg <sean@ertw.com>


<< previous in thread  ∑  next in thread >>
 

On 11 May 2000 01:02:14 GMT, per@erix.ericsson.se (Per Hedeland)
wrote:
 
>define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m')
 
Excellent
 
>Hm, max files in your OS settings? There'll still be a rather heavy load
>due to the many (and unnecessary if you don't do address-based
>processing) invocations of procmail.
 
In Linux, by default the max open files is 4096.  I upped it to 8192 (echo 8192 > /proc/sys/fs/file-max) because I was getting "too many open files" errors.  When a mailing list was being expanded I was seeing just under 6000 files open (cat /proc/sys/fs/file-nr).
 
Thanks again!
 
Sean
 
 
---
Sean Walberg <sean at ertw dot com>  http://www.ertw.com
Winnipeg Linux/Unix events      http://linux.ertw.com

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/18/2000
Author: Marcel Janssen <maja@oce.nl>


<< previous in thread  ∑  next in thread >>
 


 
Per Hedeland wrote:
>
> Grumble... When I wrote "untested", I was hoping to not having to bother
> testing them...:-) Anyway, I'm not sure that's the cause of what you're
> seeing, but there's another bug in the rules - also, trying to handle
> "route-addrs" (<@foo,@bar:user@baz>) is futile, they won't work when
> passed to procmail and back (and no-one uses them, and they're stripped
> down by default in 8.10 anyway). So, yet another version:
>
> R$*                            $: <> $1                        mark all
> R<> < @ $* > $*                $: < @ $1 > $2                  skip route-addr
> R<> $* < @ $* . PROCMAIL . >    $: $>3 $1 @ $2                  already filtered
> R<> $* < @ PROCMAIL . >        $: $1                          already filtered
> R<> $* < @ $* . >              $: <> $1 < @ $2 >              remove dot
> R<> $* < @ $* >                $: $1 < @ $2 . PROCMAIL . >    send to procmail
> R<> $*                          $: $1 < @ PROCMAIL . >          send to procmail
>
 
> If you still have problems with the above, try in -bt mode:
>
> 3,0 sean@escape.ca.PROCMAIL
>
 
I set up sendmail.cf as mentioned in this thread.
But, in the rewrite it keeps adding .PROCMAIL
 
<root@mailhost> /etc/mail $ mailq
                /var/spool/mqueue (1 request)
----Q-ID---- --Size-- -----Q-Time-----
------------Sender/Recipient------------
e4I80M204849*      8 Thu May 18 10:00 root
                                      maja@PROCMAIL
<root@mailhost> /etc/mail $ mailq
                /var/spool/mqueue (1 request)
----Q-ID---- --Size-- -----Q-Time-----
------------Sender/Recipient------------
e4I80Nc04866*      8 Thu May 18 10:00 root
                                      maja@PROCMAIL.PROCMAIL
<root@mailhost> /etc/mail $ mailq
                /var/spool/mqueue (1 request)
----Q-ID---- --Size-- -----Q-Time-----
------------Sender/Recipient------------
e4I80To05040*      8 Thu May 18 10:00 root
                                      maja@PROCMAIL.PROCMAIL.PROCMAIL
 
<root@bb> /etc/mail $ /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 maja@oce.nl
canonify          input: maja @ oce . nl
Canonify2          input: maja < @ oce . nl >
Canonify2        returns: maja < @ oce . nl . >
canonify        returns: maja < @ oce . nl . >
parse              input: maja < @ oce . nl . >
Parse0            input: maja < @ oce . nl . >
Parse0          returns: maja < @ oce . nl . >
ParseLocal        input: maja < @ oce . nl . >
ParseLocal      returns: maja < @ oce . nl . PROCMAIL . > Parse1            input: maja < @ oce . nl . PROCMAIL . > Mailertable        input: < oce . nl . PROCMAIL > maja < @ oce . nl . PROCMAIL . >
Mailertable        input: oce . < nl . PROCMAIL > maja < @ oce . nl . PROCMAIL . >
MailerToTriple    input: < procmail : / etc / procmailrcs / testrc > maja < @ oce . nl . PROCMAIL . >
MailerToTriple  returns: $# procmail $@ / etc / procmailrcs / testrc $: maja < @ oce . nl . PROCMAIL . >
Mailertable      returns: $# procmail $@ / etc / procmailrcs / testrc $: maja < @ oce . nl . PROCMAIL . >
Mailertable      returns: $# procmail $@ / etc / procmailrcs / testrc $: maja < @ oce . nl . PROCMAIL . >
Parse1          returns: $# procmail $@ / etc / procmailrcs / testrc $: maja < @ oce . nl . PROCMAIL . >
parse            returns: $# procmail $@ / etc / procmailrcs / testrc $: maja < @ oce . nl . PROCMAIL . >
>
 
This is my mc
divert(0)dnl
VERSIONID(`$Id: config.mc,v 8.11 2000/05/05 17:30:30 maja Exp $') OSTYPE(solaris2)dnl
DOMAIN(generic)dnl
define(`LOCAL_MAILER_FLAGS', `C')dnl
define(`LOCAL_SHELL_FLAGS', `C')dnl
define(`LOCAL_SHELL_PATH', `/usr/lib/smrsh')dnl
define(`SMTP_MAILER_FLAGS', `C')dnl
FEATURE(`mailertable',`dbm -o /etc/mail/mailertable')dnl
FEATURE(`local_procmail',`/bin/procmail')dnl
FEATURE(`smrsh',`/usr/lib/smrsh')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
MODIFY_MAILER_FLAGS(`PROCMAIL', `+m')
define(`PROCMAIL_MAILER_PATH', `/bin/procmail')dnl
MAILER(`procmail')
MASQUERADE_AS(`oce.nl')dnl
MASQUERADE_DOMAIN(`oce.nl')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`always_add_domain')dnl
LOCAL_RULE_0
R$*                            $: <> $1                        mark all R<> < @ $* > $*                $: < @ $1 > $2                  skip route-addr
R<> $* < @ $* . PROCMAIL . >    $: $>3 $1 @ $2                  already filtered
R<> $* < @ PROCMAIL . >        $: $1                          already filtered
R<> $* < @ $* . >              $: <> $1 < @ $2 >              remove dot
R<> $* < @ $* >                $: $1 < @ $2 . PROCMAIL . >    send to procmail
R<> $*                          $: $1 < @ PROCMAIL . >          send to procmail
 
Thanks,
Marcel

Subject: Re: sendmail 8.9.3: blocking attachements
Date: 05/19/2000
Author: Per Hedeland <per@erix.ericsson.se>


<< previous in thread  ∑  next in thread >>
 


In article <3923B02D.F099D862@oce.nl> Marcel Janssen <maja@oce.nl> writes:
>I set up sendmail.cf as mentioned in this thread.
>But, in the rewrite it keeps adding .PROCMAIL
 
I did actually collect all the (correct:-) pieces in a single posting, but it was in another thread - see:
http://www.deja.com/=dnc/msgid.xp?MID=<8fi50l$jqe$1@news.du.uab.ericsson.se>
Anyway you're missing this piece (which was only in the original post in this thread):
 
LOCAL_CONFIG
CP PROCMAIL
 
--Per Hedeland
per@erix.ericsson.se




Etc

Society

Groupthink : Understanding Micromanagers and Control Freaks : Toxic Managers : BureaucraciesHarvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Two Party System as Polyarchy : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

Skeptical Finance : John Kenneth Galbraith : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Oscar Wilde : Talleyrand : Somerset Maugham : War and Peace : Marcus Aurelius : Eric Hoffer : Kurt Vonnegut : Otto Von Bismarck : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Oscar Wilde : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

 

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 19, 2014