Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Mail Transfer Agent (MTA) Links

News

Recommended Books

Recommended Links Newsgroups Recommended Papers Reference FAQs RFCs
Sendmail Sendmail hardening Qmail Lotus Notes Spam filtering Procmail Humor Etc

Many operating systems and mail transfer agents (MTAs) can be used to implement robust, abuse-resistant mail systems. The most popular MTA is sendmail, originally written by Eric Allman at Berkeley. In the last century Sendmail was the most popular MTA with the market share around 70-80%. Now, partially due to constant security problems,  Sendmail has lost market share to other MTAs such as exim, postfixqmail, as well as Microsoft Exchange. Still it commands 30-40% of the market and remains a carrier-grade, feature-rich Internet Mail server with multi-platform support.

BSD-derived operating system like FreeBSD are the most robust choice for large mail servers.  Solaris (originally BSD-derived, though it now incorporates Unix System V) is also very common, especially for large companies. Linux often used as well but is slightly less reliable and secure.  As Eric Allman stated in the Sendmail FAQ:

Generally speaking, I adhere to the old axiom that you should choose what software you want to run first, then choose the platform (hardware and OS) that best runs this software. By this token, if sendmail is the software, then a recent version of BSD Unix would probably be best, since sendmail was developed at UC Berkeley on BSD Unix.

Here is the list of current MTA (from Software for e-mail):


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

sendmail's new paradigm

Well, it's not all that new, as sendmail 8.12 was released over three years ago, but since few people pay attention to sendmail more than they have to, the major changes in 8.12 and their side effects may have gone unnoticed.

First, some background: sendmail has some historical notoriety from a security point of view, since it for many years was a setuid-root application, and thus a buffer overflow for example could make sendmail a vector for an unprivileged user to take over the system. Starting with version 8.12, however, sendmail lost its setuid bit in favor of becoming setgid to a new group.

To make queueing work, a split-queue model was created: /var/spool/mqueue as the traditional "server" queue with the same 750 root, bin permissions, and the new /var/spool/clientmqueue as the new (you guessed it) "client" queue with 770 smmsp, smmsp permissions. For the curious, "smmsp" is the new user and group invented for these purposes, having UID and GID values of 25 (chosen to match the SMTP port value in /etc/services), and it stands for "SendMail Message Submission Program".

The default configuration involving all "direct submission" messages [meaning messages submitted via sendmail invoked from the command line or comparably by programs such as mailx(1)] will go to the client queue. Messages in the client queue are then transferred to the SMTP server on the local host, which then proceeds in the traditional way. Thus running a sendmail daemon has become critical even for out-bound mail, at least from certain sources [such as cron(1M)]. See entry 3.44 of the sendmail FAQ for more details on this, as well as how to configure around this for hosts where accepting in-bound from other hosts is undesirable. [E-mail] ( September 30, 2004 12:51 PM ) Permalink | Comments [1]

MAPS - Support - Application Note How to secure your mail system against third-party relay

Sendmail Version 8

    Status:  Freely Available
    Systems: Unix
    Info:    http://www.sendmail.org/

Versions before 8.8.4 require serious configuration hacking, and even then they aren't totally secure. Time to upgrade.

Rulesets for version 8.8.x are available from Claus AЯmann's web site at sendmail.org, http://www.sendmail.org/~ca/email/check.html. There are others around, but Claus's tend to be updated the most frequently.

Many sites which run 8.8.x have added anti-relay configuration, but are still susceptible to the "percent hack." Please pay special attention to the removelocal portion of check_rcpt in Claus's recipes to fix that.

Another approach is to limit mail server access to only those users who have authenticated themselves with a POP password, http://spam.abuse.net/adminhelp/smPbS.shtml. This is the so-called POP-before-SMTP solution. Although this is more complicated to setup, it is an excellent solution for providers that have "roaming users."

ISPs that are members of the iPass network should email ask@ipass.com to obtain the "Anti-Spam Kit" for sendmail 8.8.

Starting with version 8.9.0, sendmail prohibits relay by default, and provides a number of parameters to control this feature. See the Anti-Spam Configuration Control section of the cf/README file for information on these settings.

Caution: Most of these solutions require you to setup a list of domains to which relay is allowed. Be sure to include all authorized domains in this list. Don't forget downstream domains for which you MX, as well as virtual domains that you serve. Otherwise you will begin rejecting mail that you shouldn't.

Another caution: if you have confiured sendmail 8.9.3 with FEATURE(relay_entire_domain), this will accept relays from any host in your domain. What's "your domain"? It's your host name with the first "word." stripped from it. Unfortunately, by default, sendmail checks *EVERY* IP address on your system and does reverse lookups.

Many systems have a default as-shipped 'localhost.rev' that has 127.0.0.1 point to localhost.berkeley.edu or something like this. This means that any host in berkeley.edu will be able to relay, but your own hosts may be rejected. There other services that rely on your server having correct reverse DNS as well, so it'd be a good idea to fix this.

Many, many, systems have at least one virtual host where the reverse DNS just points to the domain name, e.g., xxxstuds.com or some similar thing. This is where you end up with an open relay; such a machine will relay for anything in '.com'. Similarly, if you had a virtual host (or even just your main IP) resolving to 'example.net', you would discover that anything in '.net' was allowed to relay.

The best solution is to upgrade (including the .cf file); if for some reason you can't do that, specify relay hosts by IP address instead of using relay_entire_domain.

procmail-on-gateway

Milter & SPF
Geoffrey D. Bennett

Sendmail Milter (Mail fILTER)
http://www.milter.org/

- An API (protocol + library) to interface with sendmail to read and
possibly modify message headers and bodies as they are processed.

- An alternative to:

- delivering to a program (eg. procmail) (which can only touch
locally delivered messages)

- configuring sendmail to only queue and running through
/var/spool/mqueue periodically

- dual-sendmail setup

- writing sendmail .cf rules

- altering sendmail's source code

Interesting points:

- Can reject email based on envelope to/from before accepting the
mail. Personally, I get annoyed when I see bounce messages sitting
around that won't be delivered because the original sender is
obviously bogus.

- Multiple milters can be installed for one copy of sendmail to use.

- C, Perl, and Python libraries available, and (experimental) C++,
PHP, and JAVA.

- Milters run as daemons; communication is usually through a
UNIX-domain socket.

- Connect, HELO, MAIL FROM, RCPT TO, DATA callbacks.

- Return values at each step: continue, reject, discard, accept.

- Message changes: add/replace/delete header, add/delete recipient,
replace body.

Obvious applications:

- Virus-scanning

- Spam filtering

- Logging

Interesting applications (some implemented at http://www.snert.com/Software/)

- milter-ahead (verify recipient addresses at secondary MX)

- milter-date (validate message dates)

- milter-gris (grey-listing)

- milter-sender (sender address verification)

- per-user filtering before accepting mail (eg. checking quota)

- bouncing too-large or non-subscriber mailing list emails before
accepting mail

Demonstrating a Milter written using Sendmail::Milter:

- From http://www.city-fan.org/ftp/contrib/perl-modules/ install
perl-Sendmail-Milter

- Write the milter (see <A HREF="test-milter">this example</A>).

- No global variables.

- Edit /etc/mail/sendmail.mc then rebuild sendmail.cf

- Run the milter.

- Restart sendmail.

- Test it.

SPF - Sender Policy Framework
(formerly Sender Permitted From)
http://spf.pobox.com/
also see these Linux Journal articles:
http://www.linuxjournal.com/article.php?sid=7327
http://www.linuxjournal.com/article.php?sid=7328

- A way to verify sender domains to help reduce spam, worms, and
viruses (or at least make them more accountable).

- Personally, I get annoyed when I receive emails from myself that I
didn't write.

- Like "reverse MX" records:

- MX records say "these mail servers receive mail for these domains"

- SPF records say "these mail servers send mail for these domains"

- Uses TXT records beginning with "v=spf1".

- Implementation has two parts:

- Publish SPF records for your domain (means that other mail servers can
reject mail that says it's from you but isn't)

- Adjust your mail server to reject (means that you can reject mail
that fails SPF checks).

SPF Record Examples:

- "prefixes" (+ (default), -, ?, ~)

- "mechanisms" (a, ip4, mx, ...)

- dig internode.com.au txt

internode.com.au. IN TXT "v=spf1 +mx +ip4:192.83.231.0/24 +ip4:203.16.214.0/24 ~all"

- dig adam.com.au txt

adam.com.au. IN TXT "v=spf1 ip4:203.6.132.64/27 ~all"

- dig aol.com txt

aol.com. IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

- dig netcraft.com.au txt

netcraft.com.au. IN TXT "v=spf1 ip4:203.16.230.0/23 ip4:150.101.234.78 -all"

- dig april.netcraft.com.au txt

april.netcraft.com.au. IN TXT "v=spf1 include:netcraft.com.au"

- dig mawsonlakes.org txt

mawsonlakes.org IN TXT "v=spf1 a mx ptr -all"

- dig websentric.com txt

websentric.com IN TXT "websentric.com sends no E-mail. All E-mail claiming to be from websentric.com is forged."
websentric.com IN TXT "v=spf1 -all"

- funkyness with "exists" and macros:

"v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all"

The target-name might expand to "1.2.0.192.someuser._spf.example.com".

Forwarding (eg. .forward files, pobox.com, etc.):

- Breaks ("to make an omlette, you need to break some eggs").

- See SRS (Sender Rewriting Scheme).

Roaming/Remote (or otherwise distant to the domain hoster) Users:

- Changes what we've always told users -- "Use your dial-up ISP's MX".

- Now need to use SMTP AUTH and use the mail server of the ISP who
hosts your domains.

Installation on RH9/FC1 with sendmail:

From http://www.city-fan.org/ftp/contrib/perl-modules/
and http://www.city-fan.org/ftp/contrib/mail/ install:

perl-Net-CIDR-Lite
perl-Sys-Hostname-Long
perl-Sendmail-Milter
perl-Net-DNS
perl-Mail-SPF-Query
perl-FreezeThaw
perl-MLDBM
perl-Mail-SRS
sendmail-milter-spf

Add these two lines to /etc/mail/sendmail.mc:

define(`confMILTER_MACROS_HELO', confMILTER_MACROS_HELO`, {verify}')dnl
INPUT_MAIL_FILTER(`spf-milter', `S=local:/var/spf-milter/spf-milter.sock, F=T, T=C:4m;S:4m;R:8m;E:16m')dnl

Rebuild sendmail.cf, start spf-milter, and reload sendmail:

m4 < sendmail.mc > sendmail.cf
service spf-milter start
service sendmail reload

Monitor /var/log/maillog

No SPF records:

May 18 17:47:18 april sendmail[11110]: i4I8HFPh011110: from=<clamav-users-admin@lists.sourceforge.net>, size=4410, class=-60, nrcpts=1, msgid=<40A9BD8E.1000403@telkom.co.id>, proto=ESMTP, daemon=MTA, relay=lists.sourceforge.net [66.35.250.206]
May 18 17:47:18 april sendmail[11110]: i4I8HFPh011110: Milter add: header: Received-SPF: none (april.netcraft.com.au: domain of clamav-users-admin@lists.sourceforge.net does not designate permitted sender hosts)
May 18 17:47:18 april sendmail[11112]: i4I8HFPh011110: to=<chris@netcraft.com.au>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=142817, dsn=2.0.0, stat=Sent

SPF accept:

May 18 06:36:29 april sendmail[23890]: i4HL6NfK023890: from=<Fool@foolsubs.com>, size=4602, class=0, nrcpts=1, msgid=<1084827973213-71792-32035682-2222-m@foolsubs.com>, proto=ESMTP, daemon=MTA, relay=mail2.foolsubs.com [69.25.30.112]
May 18 06:36:29 april sendmail[23890]: i4HL6NfK023890: Milter add: header: Received-SPF: pass (april.netcraft.com.au: domain of fool@foolsubs.com designates 69.25.30.112 as permitted sender)
May 18 06:36:30 april sendmail[23892]: i4HL6NfK023890: to=g, delay=00:00:04, xdelay=00:00:01, mailer=local, pri=34934, dsn=2.0.0, stat=Sent

SPF reject:

May 18 15:04:30 april sendmail[5283]: i4I5YReF005283: Milter: to=<g@netcraft.com.au>, reject=550 5.7.1 [RCPT TO: <g@netcraft.com.au>] Please see http://spf.pobox.com/why.html?sender=geoffrey@netcraft.com.au&ip=195.56.204.159&receiver=april.netcraft.com.au
May 18 15:04:30 april sendmail[5283]: i4I5YReF005283: lost input channel from host-204-159.fibernet.bacs-net.hu [195.56.204.159] to MTA after rcpt
May 18 15:04:30 april sendmail[5283]: i4I5YReF005283: from=<geoffrey@netcraft.com.au>, size

milter.org -- Milter community web site

Sendmail Home Page

[SUMMARY] sendmail question

Many thinks to Crist Clark, ippy at optonline.net and Chris Pinnock.

The solution is: put the frodo.domain and app.domain into local-host-names file in the /etc/mail. I belive using virual domain is another option, but we use the same domain, so we are not necessary to go that farhter.

My orignal post was:

There are two network interfaces on an host, each one is binding an IP.
The IPs have DNS entry, frodo( host name ) and app. I can send email to a user
on that machine like user at frodo.domain, but I can not send email to
user at app.domain. What is the easy sulotion? Thanks.

Doorbot Gaming PLM's Anti-Spam Sendmail Ruleset Summary: A Sendmail ruleset which blocks SMTP messages based on various header and access map checks.

My goals for this project were as follows:

You may have more success with your anti-spam measures by using Exim and SpamAssassin during the SMTP transaction, since SpamAssassin can "score" messages based on a variety of criteria.

As you read the following ruleset, you might find yourself confused, or overcome by intense fear. While these are common reactions to Sendmail, and it's configuration file language, it is actually not that hard to understand. I used O'Reilly's Sendmail book as a reference and guide.

My current (in production) Debian /etc/mail/sendmail.mc is as follows:

divert(-1)dnl
#-----------------------------------------------------------------------------
# $Sendmail: debproto.mc,v 8.12.3 2002-04-17 02:01:00 cowboy Exp $
#
# Copyright (c) 1998-2002 Richard Nelson. All Rights Reserved.
#
# ./cf/debian/sendmail.mc. Generated from sendmail.mc.in by configure.
#
# sendmail.mc prototype config file for building Sendmail 8.12.3
#
# Note: the .in file supports 8.7.6 - 8.12.3, but the generated
# file is customized to the version noted above.
#
# This file is used to configure Sendmail for use with Debian systems.
#
# If you modify this file, you will have to regenerate /etc/mail/sendmail.cf
# by running this file through the m4 preprocessor via one of the following:
# * `sendmailconfig`
# * `make`
# * `m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf`
# The first two options are preferred as they will also update other files
# that depend upon the contents of this file.
#
# The best documentation for this .mc file is:
# /usr/share/doc/sendmail-doc/cf.README.gz
#
#-----------------------------------------------------------------------------
divert(0)dnl
#
# Copyright (c) 1998-2002 Richard Nelson. All Rights Reserved.
#
# This file is used to configure Sendmail for use with Debian systems.
#
define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.12.3-4 2002-04-17 02:01:00 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
dnl #
dnl # General defines
dnl #
dnl # SAFE_FILE_ENV: [undefined] If set, sendmail will do a chroot()
dnl # into this directory before writing files.
dnl # If *all* your user accounts are under /home then use that
dnl # instead - it will prevent any writes outside of /home !
dnl # define(`confSAFE_FILE_ENV', `')dnl
LOCAL_CONFIG
FEATURE(`always_add_domain')dnl
LOCAL_CONFIG
Cwhelios.doorbot.com
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`nouucp', `reject')dnl
FEATURE(`mailertable')dnl
FEATURE(`smrsh')dnl
dnl #
dnl # Dialup/LAN connection overrides
dnl #
include(`/etc/mail/dialup.m4')dnl
include(`/etc/mail/provider.m4')dnl
dnl #
MAILER_DEFINITIONS
MAILER(local)dnl
MAILER(smtp)dnl

LOCAL_CONFIG
## Custom configurations below (will be preserved)
divert(-1)dnl
#
# helios.doorbot.com Sendmail configuration file
#
divert(0)dnl
FEATURE(`virtusertable', `hash /etc/mail/virtusertable.db')dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`dnsbl', `list.dsbl.org', "Delivery blocked; sender rejected via DNS blacklist. Visit http://dsbl.org/listing.php?ip=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `multihop.dsbl.org', "Delivery blocked; sender rejected via DNS blacklist. Visit http://dsbl.org/listing.php?ip=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `bl.spamcop.net', "Delivery blocked; sender rejected via DNS blacklist. Visit http://spamcop.net/w3m?action=checkblock&ip=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `relays.ordb.org', "Delivery blocked; sender rejected via DNS blacklist. Visit http://www.ordb.org/lookup/?host=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `relays.osirusoft.com', "Delivery blocked; sender rejected via DNS blacklist. Visit http://relays.osirusoft.com/cgi-bin/rbcheck.cgi?addr=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `spamhous.relays.osirusoft.com', "Delivery blocked; sender rejected via DNS blacklist. Visit http://relays.osirusoft.com/cgi-bin/rbcheck.cgi?addr=" $&{client_addr} " for more information.")dnl
FEATURE(`dnsbl', `sbl.spamhaus.org', "Delivery blocked; sender rejected via DNS blacklist. Visit http://www.spamhaus.org/sbl/ for more information.")dnl
dnl # Per http://lists.suse.com/archive/suse-security/2000-Aug/0050.html
dnl # FEATURE(`no_default_msa')dnl

define(`confSMTP_LOGIN_MSG', ``$j Sendmail $v/$Z in California, USA; $b'')dnl
define(`confMAX_RCPTS_PER_MESSAGE', 25)dnl
define(`confMAX_HEADERS_LENGTH', 32768)dnl
define(`confCONNECTION_RATE_THROTTLE', 3)dnl
define(`confPRIVACY_FLAGS', `goaway,restrictmailq,restrictqrun')dnl
define(`confSINGLE_LINE_FROM_HEADER', `true')dnl
define(`confNO_RCPT_ACTION', `add-to-undisclosed')dnl

LOCAL_CONFIG
Kstorage macro

LOCAL_RULESETS
HFrom: $>CheckFrom

SCheckFrom
# Try to catch forged spam
# Translate user@host.com (Full Name) to user@host.com
R$* ( $* ) $* $: $1
# Translate Full Name <user@host.com> to user@host.com
R$* < $* > $* $: $2
# Set focus
R$* $: <$1>
# Validate email address (which is what is left in the workspace) Valid emails have brackets removed.
R<$+ @ $+ . $-> $: $1@$2.$3
# Snow White Virus
Rhahaha@sexyfun.net $#error $: "553 Delivery blocked; HFrom: indicates the Snow White virus"
# Gibe Virus
Rrdquest12@microsoft.com $#error $: "553 Delivery blocked; HFrom: indicates the Gibe virus"
# Invalid emails will still have brackets, also catch null addresses
# Allow invalid email from localhost
R<$+> $: <$1> <$&{client_name}>
R<$+> < localhost > $@ OK
#R<$+> <$+> $: <$1> <$2 . $m>
#R<$+> < $j > $@ OK
R<$+> <$*> $: <$1>
R<$+> $#error $: "553 Delivery blocked; HFrom: specified invalid address"
R<$@> $#error $: "553 Delivery blocked; HFrom: specified a null address"
# Check against SMTP MAIL address, if they match, pass email.
# Note that if the address is blocked, it will be stopped at the SMTP MAIL
# command and will not get this far.
R$&f $@ OK
# Check for messages from MAILERDAEMON
R$* $: <$&f> $1
R< > $* $: $>CheckMAILERDAEMON $1
# Check for same domain name (different user name is OK. this will allow some mailing lists)
#R< $+ @ $+ > $+ @ $+ $: < $3 > $1 @ $4
#R< $+ > $&f $@ OK
#R< $+ > $+ @ $+ $: < > $1 @ $3
# Report error (valid messages should not get this far)
#R< $* > $* $#error $: "553 Delivery blocked; HFrom: does not match HReturn-Path: (may be forged)"
# Check HFrom: against access database
R<$&f> $+ @ $+ $: $(access $1@$2 $)
R$+ @ $+ $: $(access $1@ $: $1@$2 $)
R$+ @ $+ $: $(access $2 $: OK $)
# Remove subdomains, in case parent domain is filtered
R$+ @ $- . $+ . $+ $1@$3.$4
R$+ @ $+ $: $(access $1@$2 $)
R$+ @ $+ $: $(access $2 $: OK $)
ROK$* $@ OK
RREJECT$* $#error $: "553 Delivery blocked; HFrom: failed access database lookup."
RDISCARD$* $#discard $: discard
RERROR:$* $#error $: $1
R$* $#error $@ 5.7.1 $: $1

SCheckMAILERDAEMON
# only allow MD from localhost
# This will break read receipts
R$n @ $j $: <$&{client_name}>
R$n @ $m $: <$&{client_name}>
R< localhost > $@ OK
R<$+> $: <$1 . $m>
R< $j > $@ OK
# MD is nonlocal
#R$* $#error $: "553 Delivery blocked; messages from " $n " must originate locally"
# check bounce messages; if HFrom: is from a domain which is blocked,
# report header error
R$+ @ $+ $: $(access $1@$2 $)
R$+ @ $+ $: $(access $1@ $: $1@$2 $)
R$+ @ $+ $: $(access $2 $: OK $)
ROK$* $@ OK
RREJECT$* $#error $: "553 Delivery blocked; HFrom: failed access database lookup"
RDISCARD$* $#discard $: discard
RERROR:$* $#error $: $1
R$* $#error $@ 5.7.1 $: $1

# Check for X-Apparently-From: for possible spammers
HX-Apparently-From: $>CheckXApparentlyFrom

SXApparentlyFrom
R$+ @ $+ $: $(access $1@$2 $)
R$+ @ $+ $: $(access $1@ $: $1@$2 $)
R$+ @ $+ $: $(access $2 $: OK $)
ROK$* $@ OK
RREJECT$* $#error $: "553 Delivery blocked; HX-Apparently-From: failed access database lookup."
RDISCARD$* $#discard $: discard
RERROR:$* $#error $: $1
R$* $#error $@ 5.7.1 $: $1

# Check HTo: to verify user or alias exists
# What about BCC? Also, what about mailer tabled domains?
# Must not be blank
# Allow To: username only from localhost (for emailed log files)
HTo: $>CheckTo

SCheckTo
R$* ( $* ) $* $: $1
R$* < $* > $* $: $2
R$* $: <$1>
R<$+ @ $+ . $-> $: $1@$2.$3
R<$+> $: <$1> <$&{client_name}>
R<$+> < localhost > $@ OK
#R<$+> <$+> $: <$1> <$2 . $m>
#R<$+> < $j > $@ OK
R<$+> <$*> $: <$1>
R<$+> $#error $: "553 Delivery blocked; HTo: specified an invalid address"
R<$@> $#error $: "553 Delivery blocked; HTo: specified a null address"

# Check for valid Message ID
# Check message id for valid hostname (after @)
HMessage-Id: $>CheckMessageId

SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
# check for local Message-Id: header for non-local headers
# Put client hostname in an initial lookup focus
# anything -> < lookup focus > anything
R$* $: < $&{client_name} > < $1 >
# test if client hostname in lookup focus ends with one of our
# domains, $=m, if so the message is locally generated and all
# Message-Id: header are OK
R< localhost > < $+ > $@ OK
# Check for myhostname.mydomain.com
#R<$+> <$+> $: <$1 . $m> <$2>
#R< $j > <$+> $@ OK
# reject all other locally generated Message-Id: headers because
# client hostname is not local
R< $+ > < $+ @ $j > $#error $: "553 Delivery blocked; HMessage-ID: indicates local generation but client is not local (may be forged)"
# strip trash lookup focus leaving the original header
R< $+ > < $+ > < $2 >

# Check MessageID domain name... accept if it is a subdomain or same domain as from address
#R< $+ > < $1 > < $&f >
#R< $+ > < $+ @ $+ > < $1 > < $3 >

# now do the normal header check from the sendmail 8.9.1 cf/README file
# This will break mail from poorly configured, but non spamming, mail servers (it will also allow spam through)
#R< $+ @ $+ . $+ > $@ OK
# Allow format of <lotsoftext@name>
#R< $+ @ $+ > $@ OK

# Check MessageID for blocked domain names
R< $+ @ $+ > $: $(access $2 $: OK $)
ROK$* $@ OK
RREJECT$* $#error $: "553 Delivery blocked; HMessage-ID: failed access database lookup"
RDISCARD$* $#discard $: discard
RERROR:$* $#error $: $1
#R$* $#error $@ 5.7.1 $: $1
# In case something gets through, check it to verify the format (again)
#R< $+ @ $+ . $+ > $@ OK
R< $+ @ $+ > $@ OK
# Valid messageIDs should not get this far
R$* $#error $: "553 Delivery blocked; HMessage-ID: indicated invalid format"

HSubject: $>CheckSubject

SCheckSubject
RADV : $* $#error $: "553 Delivery blocked; HSubject: indicates unsolicited commercial email."
R ADV : ADLT $* $#error $: "553 Delivery blocked; HSubject: indicates unsolicited adult-content email."
RADV $* $#error $: "553 Delivery blocked; HSubject: indicates unsolicited commercial email."

Scheck_eoh
# This could break some mail
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
# We need an access map check here, in case we want to allow blank
# message IDs by IP/hostname
R< $+ > $: $(access $1 $: $1 $)
# Now check for brackets around an IP
R[ $+ ] $: $(access $1 $: $1 $)
ROK$* $@ OK
RREJECT$* $#error $: "553 Delivery blocked; HMessage-ID: missing or null, and client reverse DNS failed access database lookup."
RDISCARD$* $#discard $: discard
RERROR:$* $#error $: $1
# Block anything else
R$* $#error $: "553 Delivery blocked; HMessage-ID: missing or null but client is not local"

dnl # MAILER(`local')dnl
dnl # MAILER(`smtp')dnl

Note that the formatting of these rulesets is critical! For example, a line such as "R$* $: $1" must have a tab between "R$*" and "$: $1" as this is how Sendmail determines the left hand side (LHS) and right hand side (RHS) of each rule. Because web browsers read tabs as generic whitespace, you may choose to download this ruleset directly (11KB, md5sum: 1da035bca2b54329e6801152bb9dadc5).

If you'd like to monitor the amount of mail going in and out of the system (including rejections), edit /etc/mail/sendmail.conf and set the DAEMON_HOSTSTATS and DAEMON_MAILSTATS variables to "Yes" and then rebuild Sendmail's configuration file by running sendmailconfig.

-- PLM

Doorbot Gaming PLM's Anti-Spam Sendmail Ruleset

SecurityFocus HOME News Clues, Vandalism, Litter Sendmail Trojan Trail

The Trojan horse discovered in a distribution of the Sendmail open-source e-mail server has striking similarities to a backdoor planted in OpenSSH last summer, according to security experts who've analyzed the code. But missteps in the alerting process may have given the culprits a chance to cover their tracks.

The sophisticated backdoor came to light Tuesday through an advisory from the government-funded Computer Emergency Response Team (CERT) Coordination Center. CERT warned that copies of version 8.12.6 of Sendmail downloaded between September 28th and October 6th from the Sendmail Consortium's public FTP server contained the backdoor.

Once downloaded, the victim unwittingly activates the backdoor by compiling Sendmail from source code. The malicious code then establishes a secret control channel to a particular Internet host over TCP port 6,667, according to the CERT advisory.

That's the same general technique used by a backdoor discovered last August in another popular open-source package, OpenSSH, a free implementation of the SSH standard that lets users encrypt their communications over the Internet. That similarity is more than skin deep, according to Erik Parker, a senior security analyst at San Antonio-based Digital Defense who analyzed the code in his spare time.

Parker found that the Sendmail backdoor was controlled by a simple trio of one-letter commands: 'A' to kill the exploit, 'D' to execute a command, and 'M' to put the Trojan to sleep. The same syntax, possibly an insider's nod to the hacker group ADM, was used in the OpenSSH backdoor, according to an analysis by the OpenSSH development team at the time.

The analyst thinks the same hacker pulled both stunts, but admits that the similarities in code don't prove it. "It could have been a copycat," Parker says, "or somebody could have ripped that code off because they didn't know how to code it themselves."

Files Erased

Parker says he came by the Trojan horse the old fashioned way -- he was one of the estimated 200 people to unknowingly download the backdoor from the Sendmail FTP server before it was discovered, though he didn't compile the package. When the CERT advisory came out he and co-worker Forrest Rae ripped into the code and examined the malicious add-on.

In addition to the "ADM" commands, Parker pulled out the Internet address that was programmed into the backdoor as the control host, and contacted the owner, Denver-based network engineer Eli Klein. He was surprised to learn that Klein, apparently himself a victim of the hackers, hadn't already heard from the Sendmail Consortium or CERT.

It turns out that wasn't good enough. Wednesday evening found Klein scrambling to recover gigabytes of files -- everything from intrusion detection logs to years of personal financial records -- that he says the intruder deleted in an apparent effort to cover his or her tracks.

"Whoever it was that hacked Sendmail probably did have my box owned at some point, and decided to clean up," says Klein. "All of my files were on this PC. I lost everything from the last seven or eight years."

Parker says Klein should have taken his machine offline the moment he learned of its alleged role in the hack, but he also faults CERT and the Sendmail Consortium for not warning Klein before issuing an advisory.

In an interview, Marty Lindner, CERT's team leader for incident handling, said he doesn't remember the identify of the control host, and referred further inquiries to the Sendmail Consortium. Sources involved with the advisory say miscommunication between the Sendmail Consortium and CERT is to blame for Klein being left out of the loop -- each thought the other would notify Klein before the alert was issued.

"That's basically correct," confirms Eric Allman, a member of the Sendmail Consortium and chief technology officer of Sendmail Inc. "Mistakes were made, let's put it that way... I want to apologize to him for the way this happened to him. It wasn't supposed to happen that way."

Because the files on Klein's machine were merely deleted, rather than being thoroughly wiped from the hard drive, the prospect of eventually recovering them -- and retrieving some clues from aclue.com -- are good.

Allman says details of the hack's execution are still scarce, but it appears that the hacker managed to modify the FTP program that serves up the files, so that one out of every ten downloads would receive the backdoor without the original package ever being touched. It's a decidedly unusual technique. "I haven't had a chance to do a forensic analysis on it, but my first take was that it was pretty sophisticated," says Allman. "He did a pretty remarkable job of covering his tracks, and the attack was fairly subtle."

Earthweb Networking and Communications Network Software SuSE eMail Server Best of Show

"Pop quiz: what messaging server has group calendaring, including free/busy notifications, group contacts, POP3 and IMAP, built-in encryption, Web mail, low system requirements, high scalability, reasonable cost, and non-restrictive licensing? Answer: SuSE Linux eMail Server 3.1.

"Sound too good to be true? It isn't. This is what all commercial software should be like. SuSE provides a complete package, including the operating system, SuSE Linux Enterprise Server 7. It is designed to run standalone on a dedicated server, just pop in the installation CD and 15 minutes later you have a mail server. SuSE installs only the necessary components for a complete messaging server. It occupies a mere 515 megabytes..."

Inflex - About Inflex is an email scanner which encapsulates your existing sendmail server setup. It scans both incoming and outgoing email and it does not alter your current /etc/sendmail.cf file. It can scan for email viruses, unwanted file types (eg. EXE, BMP, MPEG) and file names (eg. prettypark.exe). It can also be used to scan for text snippets within emails and to insert disclaimers into outbound emails.

[Mar 4, 2002] ZDNet UK - News - Story - Looping emails Latest scourge of the Internet

A simple system administrator mistake is now capable of practically disabling email systems worldwide, as recent incidents show

When Roman Drahtmuller saw the volume of complaints his company was receiving from disgruntled emailers, some of whom had suddenly received hundreds of spam emails from the same source, he knew something was wrong.

"We are in trouble," wrote the security expert, who works for Linux distributor SuSE in Germany, in a reply to the spam victims. He proceeded to explain why.

The problem was that people around the world were apparently getting spammed by SuSE and up to 20 other companies. And the victims were not getting just one spam from each company, but hundreds. To make matters worse, every time one victim sent an email reply to complain, that email was forwarded on to everybody else on the list. Far from abating the torrent of spam, each complaint merely exacerbated the problem.

There was, it seemed, nothing anybody could do. Although companies such as SuSE looked to be the cause of the problem they, too, were victims: the emails appeared to be coming from mailing lists including security@suse.com, said Drahtmuller, but they were in fact originating from savoixmagazine.com, the Web site of a Singapore-based women's magazine.

So when Drahtmuller wanted to send out an email explaining the problem, it was easy to reach the victims; he simply sent his email to savoixmagazine.com.

"This is the problem," wrote Drahtmuller. "Someone has set his mail system to forward all email going to latestissue@savoixmagazine.com to a large list of recipients, mainly mailing lists (which is the reason why I get these emails here: security@suse.com is also on this list)."

In addition to security@suse.com, some help and subscribe lists were included; the type of addresses that tend to send out an automatic reply confirming receipt. All these automatic replies that were being sent back to savoixmagazine.com were bounced straight back out to the magazine's mailing entire mailing list -- including security@suse.com and the other such lists, resulting in a never-ending loop, and a torrent of emails for anybody unlucky enough to find themselves on the list.

"I will therefore shutdown/blackhole our mailing list server... until the problems with latestissue@savoixmagazine.com are solved," wrote Drahtmuller. "We at SuSE are sorry for this incident, but since we are not responsible for what is going on, there is nothing much we can do against it."

Most worryingly, said Drahtmuller, was that the actual culprits may not have been seeing the emails they produced.

The SuSE/SavoixMagazine incident, while unusual, was not unique. A US-based data recovery company recently found itself in the same situation, though it is not clear whether in this case the company was to blame.

When Drahtmuller contacted savoixmagazine.com's hosting company in the US, the situation slipped into the ridiculous as the hosting company tried to reply in Drahtmuller's native German language. "Even though we contacted them in English, they ran their response through Babelfish (translation software) so we couldn't understand what they were saying," he told ZDNet UK. "In the end we blocked their servers from our mail exchanges. We did what we could but the problem still existed."

Drahtmuller said that SuSE fixed the problem quickly, "within 40 minutes", but added, "There were still mails in queues everywhere in world directed back to security list," and these emails continued to propagate the loop.

Drahtmuller's belief was that the system administrators running savoixmagazine.com's server "didn't know what they were doing." The problem, he said, was that the server was stripping part of the email headers; this was why people receiving the emails did not see savoixmagazine.com's address at the top and instead believed them to be coming from SuSE's security mailing list.

"At savoixmagazine.com the mail headers were cut so it was almost impossible to find out where the mail originated from," said Drahtmuller. The everyday analogy is a letter stripped of its envelope that had the original return address printed on it, repackaged in a new envelope with a different return address, and forwarded on. "Usually mail loops like this are not possible with Unix systems because they always maintain the headers," he added.

Drahtmuller said the incident was probably an accident, rather than a malicious attack, but noted that it would be possible for a malicious person to create such an attack intentionally, and sometimes does happen when spammers forge sender addresses on email. "All you have to do is to get a set of email addresses, put them into a mailing list, and you could trigger such a loop. It doesn't happen frequently, but I have seen it a couple of times."

Related Links
Scripting flaw leaves sites vulnerable
Security guru: Let's secure the Net
Cloud Nine sells up after DoS attack

SAGE ;login - antispam

For most corporations, email is a mission-critical application. It often is the number one communications medium for developers, sales, and customers. However, unsolicited commercial email (UCE or spam) has reached levels at which it is starting to interfere with the effectiveness of email as a communication tool. Separating junk from real email wastes not only network/computing resources but also employee time. More important, many people consider spam to be an invasion of their private mailboxes; arguably the worst aspect of spam is that it demoralizes employees and can even jeopardize their emotional well-being.

Most corporate postmasters have been given the responsibility of dealing with spam. A quick search on the Internet reveals various technical solutions that have been created to help stop spam. One big implementation problem with these anti-spam measures is that they are usually applied on a site-wide basis. For most corporations, some email addresses — such as sales, technical support, and bug reporting — must not be blocked. Some of the spammers are our customers; we want their purchase orders to get through but not their spam. We never want to block bug reports from coming in, even if they are from a known spammer.

This article discusses configuration changes that can be made to sendmail rulesets in order to implement an anti-spam filtering policy on a per-user basis. Users can decide if they want to activate anti-spam features and what level of filtering they want.

The Anti-Spam Features of sendmail

Beginning with sendmail 8.8, the check_* group of rulesets were added as features. This group of rulesets provides hooks into the SMTP dialog. For the sake of clarity, I'll show the SMTP dialog here:

1. The sending machine issues a HELO (or EHLO) in which it identifies itself.

2. The sending machine issues a MAIL FROM in which it identifies the sender of the message.

3. The sending machine issues a RCPT TO in which it identifies the recipient of the message.

4. The sending machine issues a DATA to tell the receiving machine it is about to transfer the message.

5. The message is transferred, and the sending machine ends the message with a "." on a line by itself.

6. The receiving machine acknowledges that it got the message, usually by issuing a unique number.

Sendmail 8.8 included the following four check rulesets:

  • check_relay - this ruleset is called after step 1 in the SMTP dialog above. It is used to prevent unauthorized IPs from connecting to your machine.
  • check_mail - this ruleset is called after step 2 in the SMTP dialog. It is used to stop mail from known senders.
  • check_rcpt - this ruleset is called after step 3 in the SMTP dialog. It is primarily used to stop relaying (not to be confused with check_relay above.) Relaying occurs when an external user sends mail to your server meant for a different external user. They are using your server as a relay for their email. Spammers often do this in order to hide their identity or to take advantage of your resources. Since we know both the sender and recipient at this point, we can decide whether or not the email is relayed.
  • check_compat - this ruleset is called after step 5 in the SMTP dialog. It can be used to stop delivery of a message after it has been accepted.

    Although these check_* hooks were provided, it was left to the system administrator to actually develop rules using these hooks. Claus Assmann[1] and Robert Harker[2] maintain a set of effective rules based on these hooks.

    When Sendmail 8.9 was released, Eric Allman included some basic anti-spam features that could be configured into sendmail to take advantage of these hooks. By default, Sendmail 8.9 had relaying turned off (implemented in the check_rcpt ruleset). Furthermore, you could enable rejection of email based on either a DNS lookup or the results of a database lookup (implemented in the check_mail ruleset).

    The Problem

    The main problem with the anti-spam features included with sendmail is that the checks are made too early in the SMTP dialog. As configured by sendmail, both the DNS and database check are made in check_mail (SMTP step 2), after the sender has been identified. If the sender fails the checks, the mail is rejected.

    The rejection comes too early because we do not know whom the mail is meant for yet. Also, this means that mail will be bounced regardless of who the recipient was. This is a problem for corporations because there may be some addresses that must receive all email. Also, some users may actually want to get spam (true case)!

  • Linux Journal: Sendmail Setup for Your Home Network

    (Apr 19, 2001, 22:13 UTC) (2172 reads) (3 talkbacks) (Posted by kreichard)
    "In this article we will address a basic installation procedure (sort of a recipe for a quick set up of your mail server) for the average user. Assuming the system is a home or small company network with a Linux machine running Sendmail as the mail server, Sendmail's functions will be to receive mail messages from machines on the internal network, deliver local messages to their respective users and deliver to the Internet messages for external destinations. Additionally, the server will receive mail from the Internet."

    http://www.ActiveState.com/Products/PerlMx/index.html PerlMx is a Sendmail filter engine that allows you to quickly and easily use the power of Perl inside Sendmail to perform a variety of email filtering functions.

    This beta release is available for x86 Linux and SPARC Solaris. It also requires ActivePerl build 616, and either Sendmail v8.11.0 or Sendmail Switch v2.0.6 from Sendmail Inc.


    **** sendmail.net 000705securitygeneral -- Securing Sendmail

    Though the virus alerts have vanished from the evening news, Internet security remains a justifiably hot topic. Still, while hype, myth, and hysteria abound, useful information seems to be in short supply. Had enough of generalities? Time for something, um, practical? We think so.

    This two-part series on securing sendmail, based on the tutorial given by Eric Allman and Greg Shapiro at the recent USENIX technical conference in San Diego, begins by detailing the measures you can take to secure any sendmail installation. It continues tomorrow with a look at the specific roles sendmail can play - from timesharing systems to firewall installations - and how you can make those systems more secure. So dig in. Read on. And tell us what you think.

    Enhancing E-Mail Security With Procmail -- a very good paper

    There are four types of attacks on system security that can be carried out via electronic mail:

    LinuxFocus: Sendmail and Fetchmail: A local mail server

    (May 15, 2000, 03:37 UTC) (1373 reads) (0 talkbacks) (Posted by marty)
    "This article explains how to configure sendmail and fetchmail on your local computer connected to the internet via a PPP link."

    sendmail.net: From 8.9 to 8.10: Upgrade Made Easy

    (Apr 19, 2000, 22:31 UTC) (Posted by marty) (1 talkback posted) (704 reads)
    "In case you haven't heard, sendmail 8.10 is out at last. With SMTP authentication, multiple queues, better LDAP support, and more than 150 other new features, the new release lets us run faster, play harder, and stop more spam than ever before."

    Sendmail Security Without Source Code Changes

    [April 16, 1999]LJ #24 April 1996 XF-Mail by John M. Fisk

    If you have a dial-up connection to the Internet, one of your easiest options for getting and receiving e-mail is popmail. But to use popmail, you need a ``popmail client''. XF-Mail is a convenient, easy-to-use, and reasonably powerful popmail client that is worth a closer look.


    Recommended Links

    Softpanorama hot topic of the month

    Softpanorama Recommended


    Qmail

    qmail (www.qmail.org) is very well written and many people prefer it to sendmail. The author (Dan Bernstein) writes small and very concise code. Also, he checks return codes of all system calls... It can became annoying and hard to write a program that checks syscall return codes but he does it very well... Also, the design of the qmail system is very good. Small parts connected together make a fast, efficient and feature-rich system. For sheer robustness and attention to detail, the qmail source code is incredible. Dan started from first principles and does a great job (he reinvented many wheels, intentionally, since most of the libc string handling is insecure by his exacting standards). See also


     


    Procmail


    Reference


    Requests for Comments (RFCs)


    Newsgroups


    Books



    Microsoft platforms


    
    

    Etc.

     


    Etc

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

    ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

    Society

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

    Quotes

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

    Bulletin:

    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : 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.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-2016 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.

    The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    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 development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

    Disclaimer:

    The statements, views and opinions presented on this web page are those of the author (or referenced source) 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: June 04, 2016