Softpanorama

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

Mail aliases

News

See also

Recommended Links DNS RFCs MUA MTA
Sendmail Postfix MTA Log Analysers spam uucp Listservers MX records checking
Forwarding Perl scripts Phishing Etiquette History Humor Etc

An alias is an alternative name. For electronic mail, you can use aliases to assign additional names to a user, to route mail to a particular system, to define mailing lists, to send e-mail through programs for processing, and to append e-mail messages to a file for later use.

You can create a mail alias for each user at your site to specify where the mail is stored. Providing a mail alias is like providing a mail stop as part of the address for an individual at a large corporation. If you do not provide the mail stop, the mail is delivered to a central address. Extra effort is required to determine where the mail is to be delivered within the building, and the possibility of error increases. For example, if two people named Kevin Smith work in the same building, the probability is high that each Kevin will receive mail intended for the other.

Use domains and location-independent addresses as much as possible when you create alias files. To enhance the portability and flexibility of alias files, make your alias entries as generic and system independent as possible. For example, if you have a user named ignatz on system oak in domain Eng.sun.com, create the alias as ignatz instead of ignatz@Eng or ignatz@oak. If the user ignatz changes the name of the system but remains within the engineering domain, you do not need to update any alias files to reflect the change in the system name.

When creating aliases that include users outside your domain, create the alias with the user name and the domain name. For example, if you have a user named smallberries on system privet in domain Corp.sun.com, create the alias as smallberries@Corp.

 Programs that read mail, such as /usr/bin/mailx, can have aliases of their own, which are expanded before the message reaches sendmail.

As system administrator, you should choose a policy for updating aliases and forwarding mail messages. You might set up an aliases mailbox as a place for users to send requests for mail forwarding and changes to their default mail alias. If your system uses NIS or NIS+, you can administer forwarding instead of forcing users to manage it themselves. A common mistake users make is to put a .forward file in the home directory of Host A that forwards mail to user@host-b. When the mail gets to Host B, sendmail looks up the user in the NIS or NIS+ aliases and sends the message back to user@host-a, resulting in a loop and more bounced mail.

Uses for Alias Files

You create mail aliases for global use in the NIS+ aliases table, in the NIS aliases map, or, if your site does not use a nameservice, in local /etc/mail/aliases files. You can also create and administer mailing lists with the same alias files.

Depending on the configuration of your mail services, you can administer aliases with the NIS or NIS+ nameservice to maintain a global aliases database or by updating all of the local /etc/mail/aliases files to keep them in sync. See Chapter 4, "Setting Up and Administering Mail Services" for information on how to create aliases.

In general, only the mail hub for an e-mail domain contains the full list of aliases. The client systems and gateways have no idea how to deliver e-mail to individuals. They forward or relay e-mail to the mail hub for handling. Unless you have multiple mail hubs, you don't need to put aliases into NIS or NIS+.

Users can also create and use aliases. They can create aliases either in their local .mailrc file, which only they can use, or in their system's local /etc/mail/aliases file, which anyone can use. Users cannot create or administer NIS or NIS+ alias files. Users cannot administer the local /etc/mail/aliases file unless they have access to the root password on their system.

Including Files in Aliases

You can keep an alias list in a separate file and include a reference to it in the aliases file with the following syntax.

mailinglistname: :include:pathname

The following example includes an alias named engineers that is located in the /etc/mail/includes/engineers file.

engineers: :include:/etc/mail/includes/engineers

If you want to delegate the administration of aliases to others, use the chown command to change the ownership of the included file to the name of the user. Then, with the following syntax, create an alias that designates the owner of the alias.

owner-mailinglistname: username

mailinglistname is the name of the mailing list and username is the login name of the person responsible for administering the alias. The following example assigns ownership of the alias named engineers to user winsor.

owner-engineers: winsor

Individuals can then use the owner-engineers alias to send e-mail to the person responsible for administering the alias.

Sending Mail to Files and Programs

You also can have aliases send e-mail to files and programs.

The following example appends all e-mail sent to listings-log to /proj/dev/logs/listings-log.

listings-log: /proj/dev/logs/listings-log

The following example sends all e-mail sent to weblogs as standard input to the program /usr/local/bin/analyze-web-logs.

weblogs: "/usr/local/bin/analyze-web-logs"

For program aliases, the program must provide an appropriate exit status that is returned to sendmail; otherwise sendmail bouces all e-mails sent to this kind of aliases. sendmail is very picky about these return values. The appropriate values are listed in /usr/include/sysexits.h.

Syntax of Aliases

The following sections describe the syntax of NIS+, NIS, and .mailrc aliases.

NIS+ Aliases

The NIS+ aliases table contains all of the names by which a system or person is known, except for private aliases listed in users' local .mailrc files. The sendmail program can use the NIS+ Aliases database instead of the local /etc/mail/aliases files to determine mailing addresses. See the aliasadm(8) and nsswitch.conf(4) manual pages for more information.

The NIS+ aliases table has the following format.

alias: expansion [options#  "comments"]

The NIS+ aliases table columns, are described in Table 6.

Table 6 Columns in the NIS+ Aliases Database

Column Description
alias The name of the alias.
expansion The value of the alias as it would appear in a sendmail /etc/aliases file.
options Reserved for future use.
comments Use to add specific comments about an individual alias.

The NIS+ Aliases database should contain entries for all mail clients. You list, create, modify, and delete entries in the NIS+ Aliases database with the aliasadm command. If you are creating a new NIS+ aliases table, you must initialize the table before you create the entries. If the table already exists, no initialization is needed.

When creating alias entries, enter one alias per line. You should have only one entry that contains the user's system name. For example, you could create the following entries for a user named winsor on system castle.

winsor: janice.winsor
jwinsor: janice.winsor
janicew: janice.winsor
janice.winsor: winsor@castle

You can create an alias for local names or domains. For example, an alias entry for the user fred, who has a mailbox on the system oak and is in the domain Trees, could have the following entry in the NIS+ aliases table.

fred: fred@Trees

To use the aliasadm command, you must be root, a member of the NIS+ group that owns the Aliases database, or the person who created the database.

See Chapter 4, "Setting Up and Administering Mail Services" for information on how to create NIS+ alias tables.

NIS Aliases

Aliases in the NIS aliases map have the following format.

name: name1, name2, . . .

.mailrc Aliases

Aliases in a .mailrc file have the following format.

alias aliasname name1 name2 name3 . . .

/etc/mail/aliases Aliases

Distribution list formats in a local /etc/mail/aliases file have the following format.

aliasname: name1,name2,name3 . . .

The aliases in the /etc/mail/aliases file are stored in text form. When you edit the /etc/mail/aliases file, run the newaliases program to create a DBM database to make the aliases available to the sendmail program in binary form.

The Solaris 8 release provides the new /usr/bin/praliases command that you can use to display the contents of the /etc/mail/aliases file as key:value pairs. If you specify an argument on the command line, the command displays any matching key:value pair.

The following example uses the praliases command to display all of the aliases on the system paperbark.

paperbark% praliases
mailer-daemon:postmaster
postmaster:root
winsor:winsor@paperbark
nobody:/dev/null
ignatz:ignatz@paperbark
@:@
paperbark%

The following example uses the praliases command with a username argument to display the alias for user ignatz.

paperbark% praliases ignatz
ignatz:ignatz@paperbark
paperbark%

Contents of the /bin Directory That Are Used for Mail

Name Type Description
mail File A mail user agent.
mailcompat File A filter to store mail in SunOS 4.x mailbox format.
mailq Link Link to /usr/lib/sendmail.
mailstats File Mail statistics generated by the /etc/mail/sendmail.st file (if present).
mailx File A mail user agent.
newaliases Link Link to /usr/lib/sendmail that is used to rebuild the database for the mail aliases file.


 Contents of the /etc/mail Directory

Name Type Description
Mail.rc File Default settings for the mailtool user agent.
aliases File Mail-forwarding information.
aliases.dir File Binary form of mail-forwarding information (created by running newaliases).
aliases.pag File Binary form of mail-forwarding information (created by running newaliases).
mailx.rc File Default settings for the mailx user agent.
main.cf File Sample configuration file for main systems.
sendmail.cf File Configuration file for mail routing.
sendmail.hf File Help file used by the SMTP HELP command.
sendmail.pid File File containing the /usr/lib/sendmail -b -q1h command.
sendmail.st File The sendmail statistics file. (If this file is present, sendmail logs the amount of traffic through each mailer.)
sendmailvars File Table that stores macro and class definitions for lookup from sendmail.cf.
sendmailvars.org_dir Table NIS+ version of sendmailvars table.
subsidiary.cf File Sample configuration file for subsidiary systems.

Mail Files in the /usr/lib Directory

Name Description
mail.local Mailer that delivers mail to mailboxes.
sendmail The routing program, also known as the mail transport agent.

 

Spooling directories for delivered mail are located in the /var/mail directory, as shown in Table 12. Mail that has not been delivered is stored in the /var/spool/mqueue directory.

Contents of the /var/mail Directory

Name Type Description
mailbox1 File Mailboxes for delivered mail.
mailbox2 File Mailboxes for delivered mail.
mailbox3 File Mailboxes for delivered mail.


 

Reference

Purpose

Contains alias definitions for the sendmail command.

Description

The /etc/mail/aliases file contains the required aliases for the sendmail command. Do not change these defaults, as they are required by the system. The file is formatted as a series of lines in the form:

name: name_1, name_2, name_3,...

The name: is the name of the alias, and the name_n are the aliases for that name. Lines beginning with white space are continuation lines. Lines beginning with a # (pound sign) are comments.

Aliasing occurs only on local names. System-wide aliases are used to redirect mail. For example, if you receive mail at three different systems, you can use the /etc/mail/aliases file to redirect your mail to one of the systems. As an individual user, you can also specify aliases in your .mailrc file.

Aliases can be defined to send mail to a distribution list. For example, you can send mail to all of the members of a project by sending mail to a single name.

The sender of a message is not included when the sendmail command expands an alias address. For example, if amy sends a message to alias D998 and she is defined as a member of that alias, the sendmail command does not send a copy of the message to amy.

The /etc/mail/aliases file is a raw data file. The sendmail command uses a database version of this file. You must build a new alias database by running the sendmail -bi command or the newaliases command before any changes made to the /etc/mail/aliases file become effective.

Berkeley DB support is now available on AIX 5.1for Sendmail 8.11.0. As long as you do not rebuild the aliases database, sendmail will continue to read it in its old DBM format. This consists of two files: /etc/mail/aliases.dir and /etc/mail/aliases.pag. However, the moment you rebuild the aliases database, sendmail will change this format to Berkeley DB. This file will be stored in /etc/mail/aliases.db.

Note:

Upper case characters on the left hand side of the alias are converted to lowercase before being stored in the aliases database. In the following example, mail sent to the testalias user alias fails, since TEST is converted to test when the second line is stored.

TEST: user@machine
testalias: TEST

To preserve uppercase in user names and alias names, add the u flag to the local mailer description in the /etc/mail/sendmail.cf file. Thus, in the example above, mail to the testalias user alias would succeed.

Files

 

/etc/mail/aliases Contains systemwide aliases.
/etc/mail/aliasesDB directory Contains the binary files created by the newaliases command, including the DB.dir and DB.pag files.
/etc/mail/aliases.db Contains the binary file storing the aliases database in Berkeley DB format, created by the newaliases command

Related Information

The newaliases command, sendmail command.

The .mailrc file.

.mailrc file

The .mailrc file can be placed in your $HOME directory to personalize the Mail program. You can create the .mailrc file with any ASCII editor. Once the file is created, the Mail program reads the file when you send or read mail, and applies the options you have set. In the file, you can define aliases for other users' mail addresses. You can also change the way mail is displayed and stored on your system.

The Mail program uses a master file in the same format, /usr/share/lib/Mail.rc. Options you set in your $HOME/.mailrc file override comparable options in the Mail.rc file.

A line that begins with a # (pound sign) followed by a space is treated as a comment. The Mail program ignores the entire line and any entries or options it contains.

Entries

Use the following mail subcommands as entries in the .mailrc file:

mail Subcommand Definition
alias NewAlias { Address... | PreviousAlias... }
  Defines an alias or distribution list. The alias can be defined as an actual mail address, or as another alias defined in a previous entry in the .mailrc file. To define a group, enter multiple addresses or previous aliases separated by spaces.
ignore FieldList Adds the header fields in the FieldList parameter to the list of fields to be ignored. Ignored fields are not displayed when you look at a message with the type or print subcommand. Use this subcommand to suppress machine-generated header fields. Use the Type or Print subcommand to print a message in its entirety, including ignored fields.
set [OptionList | Option=Value...]
  Sets an option. The argument following the set option can be either an OptionList giving the name of a binary option (an option that is either set or unset) or an Option=Value entry used to assign a value to an option.
unset OptionList Disables the values of the options specified in OptionList. This action is the inverse of the set OptionList entry.

Binary Options for the set and unset Entries

Use the set entry to enable options and the unset entry to disable options. Add the options you want to set or unset to the $HOME/.mailrc file. The options and the actions they generate are as follows:

append Adds messages saved in your mailbox to the end rather than to the beginning of the $HOME/mbox file.
ask Prompts for the subject of each message sent. If you do not wish to create a subject field, press the Enter key at the prompt.
askcc Prompts for the addresses of people who should receive copies of the message. If you do not wish to send copies, press the Enter key at the prompt.
autoprint Sets the delete subcommand to delete the current message and display the next message.
debug Displays debugging information. Messages are not sent while in debug mode. This is the same as specifying the -d flag on the command line.
dot Interprets a period entered on a line by itself as the end of a message you are sending.
hold Holds messages that you have read but have not deleted or saved in the system mailbox instead of in your personal mailbox. This option has no effect on deleted messages.
ignore Ignores interrupt messages from your terminal and echoes them as @ (at sign) characters.
ignoreeof Sets the mail command to refuse the Ctrl-D key sequence as the end of a message.
keepsave Prevents the Mail program from deleting messages that you have saved with the s or w mailbox subcommand. Normally, messages are deleted automatically when you exit the mail command. Use the keepsave and hold options to hold messages in your system mailbox. Otherwise, the messages are placed in your personal mailbox ($HOME/mbox).
metoo Includes the sender in the alias expansion. By default, expanding the alias removes the sender. When this option is set in your .mailrc file, sending a message using an alias that includes your name sends a copy of the message to your mailbox.
noheader Suppresses the list of messages in your mailbox when you start the Mail program. Instead, only the mailbox prompt (&) is displayed. To get a list of messages, use the h mailbox subcommand.
nosave Prevents retention of interrupted letters in the $HOME/dead.letter file.
quiet Suppresses the printing of the banner when the Mail program starts. The banner is the line that shows the name of the Mail program.
Replyall Reverses the meaning of the reply subcommand and the Reply subcommand.
verbose Displays the actual delivery of messages on the terminal. This is the same as specifying the -v flag on the command line.

Value Options for the set Entry

You can use a set entry to assign values to the following options. For example, enter set screen=20 to limit headers to 20 lines per screen.

crt=Lines Defines the number of lines of a mail message the Mail program displays before pausing for input (this option starts the pg command to control the scrolling).
EDITOR=Editor Gives the full path name of the editor to be started with the e mailbox subcommand or the ~e mail editor subcommand. The default editor is /usr/bin/e.
escape=Character Changes the escape character used for mail editor subcommands. The default character is ~ (tilde).
folder=PathName Gives the path name of a directory in which to store mail folders. Once the directory is defined, you can use the + (plus sign) notation to refer to it when using the FileName parameter with mailbox subcommands.
record=FileName Defines a file in which to record outgoing mail. The path name must be absolute (that is, a full path name), or be given relative to the current directory.

Note:

If you set up a file to record outgoing messages, read the file periodically with the mail -f command and delete unnecessary messages. Otherwise, the file will grow and eventually use all of your storage space.
screen=Lines Defines the number of lines of message headers displayed (for example, in response to the h mailbox subcommand) before pausing for input.
toplines=Lines Defines the number of lines displayed by the top mailbox subcommand.
VISUAL=Editor Gives the full path name of the editor to be started with the v mailbox subcommand or the ~v mail editor subcommand. The default editor is /usr/bin/vi.

Examples

  1. To ignore the Message-ID field and the Received field, place the following entry in the .mailrc file:
    ignore message-id received

    When messages are displayed in the mailbox, the machine message ID number and the date your system received the message are not displayed.

  2. To set a folder directory, place the following entry in the .mailrc file:
    set folder=/home/kaye/notes

    To save message 1 from the mailbox in the folder procedures, enter the following at the mailbox prompt (&):

    s 1 +procedure

    Message 1 is saved in the /home/kaye/notes/procedures file (if the file already exists, the message is appended to the file).

  3. To record outgoing mail in a folder directory, place the following pair of entries in the .mailrc file:

     

    set record=/home/pierre/letters/mailout
    set folder=/home/pierre/letters

    Outgoing mail is placed in the /home/pierre/letters/mailout file, and can be read with the following command:

    mail -f +mailout
  4. To combine the delete and print commands and also instruct the Mail program to include your user ID when expanding aliases, enter the following in your .mailrc file:
    set autoprint metoo

    The autoprint option causes the next message to be displayed whenever you delete a message. The metoo option causes the Mail program to send a copy of messages to you when it expands mail aliases. By default, the Mail program discards your user address when it expands an alias, so that you do not get a copy of mail you send.

  5. To unset an option that is set in the /usr/share/lib/Mail.rc file, enter the following in your .mailrc file:
    unset askcc

    This entry prevents the mail editor from requesting a carbon copy list when you create messages, even if the askcc option is set in the Mail.rc file.

  6. To set aliases for two users and a distribution list that includes several users, enter the following in your .mailrc file:
    alias george george@thor.valhalla.dbm.comm
    alias bill @odin.UUCP:@depta.UCCP:@deptb:bill@deptc
    alias mygroup amy@cleo george bill

    To send mail to user bill using his alias, enter:

    mail bill

    To send mail to everyone in the mygroup list, enter:

    mail mygroup

    When you complete and send the message, the mail command actually addresses it as follows:

    amy@cleo george@thor.valhalla.dbm.comm @odin.UUCP:@depta.UCCP:
    @deptb:bill@deptc

Files

/usr/share/lib/Mail.rc Contains systemwide defaults for the Mail program.
$HOME/.mailrc Contains user-specific defaults for the Mail program.

Old News

Creating a mail alias

Instead of creating a new user account, we will only create an alias. For sendmail these are kept in /etc/aliases. The syntax is defined in the man page...

man aliases

In our example the username of the mail address is confctrl which posts to the local newsgroup ietf.confctrl, so we add a line like ...

confctrl:   |" /usr/local/bin/mail2news.pl ietf.confctrl "

The double quotes are required. There cannot be a space between the first double quotes and the | (pipe) character, or sendmail will complain "User unknown". Huh?

Whenever you modify the /etc/aliases file you need to notify sendmail.

sendmail -bi

After you send an e-mail, check the /var/log/maillog to see if it worked. The log may contain a useful error message. I found it convenient to open up another terminal window to follow the log with

tail -f /var/log/maillog

 

Recommended Links

Mail Editor Subcommands for the mail, Mail Command.

Mailbox Subcommands for the mail, Mail Command.

Creating and Sending Mail, Customizing the Mail Program, Mail Overview, Receiving and Handling Mail in AIX 5L Version 5.3 System User's Guide: Communications and Networks.

Building the Alias Database, Creating Local System Aliases for Mail, Managing Mail Aliases in AIX 5L Version 5.3 System Management Guide: Communications and Networks.


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