Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

NEW! UNIX Email Software Survey FAQ [Part 1 of 3]
Section - Glossary

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum archive ]


Top Document: NEW! UNIX Email Software Survey FAQ [Part 1 of 3]
Previous Document: Electronic mail - A General Overview of Structure
Next Document: Do's and Don'ts:
See reader questions & answers on this topic! - Help others by sharing your knowledge

Rather than alphabetic, this glossary tends to group terms
referring to similar functionality together.

Transport Medium:

    UUCP (Unix to Unix Copy Program):
	Back in the mists of time, UNIX systems communicated only
	over RS232 serial lines, usually over modems.  UUCP is a
	suite of programs developed back in the early 70's to
	provide this communications link.  All that UUCP does is
	transfer files from one system to another.  There is an
	additional mechanism where one system can direct the
	destination system to run a file through a specific program.
	Electronic mail in UUCP is simply requesting the destination
	machine to run "mail" on a data file.

	UUCP communicates by means of "protocols", the most common
	being "g", a method for transmission of data over telephone
	lines and ensuring that the data is not corrupted.  There
	are several other protocols, none universally available,
	and most oriented towards communication media other than
	telephone voice lines (such as dialup X.25, PAD X.25, or
	LAN connects).

	UUCP operates over fixed system-to-system links, so sending
	mail from one system to another often has to traverse
	other intermediate systems.

|	If you like source, Taylor UUCP is an excellent full-featured
|	implementation of UUCP, with many enhancements to deal with higher
|	modem speeds.  It is FreeWARE.

|	UUCP mail protocols (bang paths) are now being deprecated, because
|	DNS and MX etc., are making it wholly unnecessary.


    TCP/IP (Transmission Control Protocol/Internet Protocol):
	TCP/IP is a protocol that allows any system on a network to
	talk "directly" to any other, by passing packets of
	information back and forth.  TCP/IP (and its later relative
	OSI) is usually used over networks built on top of Ethernet,
	Token-Ring, Starlan and other LANS.

    SMTP:
	Or, "Simple Mail Transfer Protocol", is the communications
	protocol used most commonly over TCP/IP links in UNIX
	environments for mail.  SMTP usually operates directly between
	the source and destination machines, so intermediate machines
	don't get involved (except for gateways, see below).  SMTP
	is usually part of the MTA.

    SLIP (Serial Line Internet Protocol):
	SLIP is an implementation of TCP/IP designed for use over
	RS232 serial lines (ie: modems).  The other difference is
	that some SLIP implementations have the ability to "dial the
	phone" to make a connection for a specific transfer, whereas
	LAN TCP/IP is physically continuously connected.  You'd also
	need TCP/IP to run a SMTP mail connection.

    PPP (Point-to-Point Protocol):
	A successor to SLIP.

    X.25/X.29:
	X.25 is a packet switched data network which is usually
	half-duplex.  In this context, it's really an alternative
	to dialup over voice telephone lines with modems.  X.25
	is available in several "flavours", either direct X.25
	trunk connects over leased lines, through "PAD" interfaces,
	or by ordinary dialup modem access to X.25 "ports".

	To be useable in the context of mail transfers, you also
	have to use a file transfer protocol/mechanism of some
	sort on top of X.25.  The most common being UUCP "f" protocol
	(through PADS or dialup), or "x" with direct X.25 connects.

	Whether you use X.25 or phones plus modems depends on a number
	of factors - usually the determining factor is cost.  In North
	America, high speed modems (eg: 9600 baud and above) over telephone
	lines tends to be less expensive.  However, Europe's really
	wierd phone system structure usually makes X.25 more cost-effective,
	and therefore, X.25 use in UNIX mail systems is much more common
	in Europe than North America.

	X.29 is the command set used to configure and establish
	X.25 connections when you're using asynchronous connections
	to a PAD.

Networks:

    Internet:
	An "internet" is a network comprised of computers that talk
	to each other using TCP/IP, and usually SMTP for mail.

	The "Internet" is a vast network of hundreds of thousands of
	machines using SMTP protocol mail, communicating with
	each other over relatively high speed lines.  But not all
	"internets" are connected to *the* Internet.
	
	The Internet grew out of a US government funded project in
	inter-computer communications that grew into an enormous network
	of systems.

|	One of the principal characteristics of this network is that
	machines are addressed by domain names which identify the
	destination, rather than addresses that are constructed out
	of the route from machine-to-machine-to-machine.

    UUCP Network:
	The UUCP network is that set of machines that talk to each other
	via UUCP.  Sending mail through this network requires that the sender
	know the network topology of UUCP links, and specify a path from one
	machine to the next.  (There are, of course, ways around this.
	See the section on "do's and don'ts".)

Mail addresses:

    Addresses:
	An email address is a method of specifying a given person on
	a specific machine.  There are scads of conventions, usually
	determined by the presence of "@"'s, "!"'s and other special
	characters in the name.  An address usually consists of
	two parts: a userid/name and a machine specification.

	A Domain address usually looks like:
	    userid@domain-address
	Whereas a UUCP address usually looks like:
	    siteA!siteB!siteC!userid

    Domain Addresses:
	Domains are a way of uniquely specifying a destination.
	Much like a postal address, a domain specifies a set of
	progressively more restrictive "domains" of the potential
	address space.  It would perhaps be illustrative to give an
	example:

	    clewis@ferret.marketing.fooinc.com

	You read these things right to left: "com" means the
	commercial domain.  "fooinc" is the name of an organization
	within the commercial domain.  "Marketing" is the name of a
	suborganization within fooinc, and ferret gives the name of
	a machine (usually).  Domains can have any number of levels.

	The top level domain (com in the above example) has many
	possible values.  In the United States, "com", "mil", "edu",
	and "gov" are fairly standard.  Elsewhere, the top level
	domain tends to be a country code, the second level tends to
	be a province or state, OR a classification like "edu" or "ac"
	for academic (such as ac.jp, go.jp, ac.uk, edu.au, etc)
	and the third an organization.  But, for example, there are
	many .com and .edu sites in Canada and other countries.

    FQDN
	A fully-qualified-domain-name (FQDN) has a entry for each
	level of the domain, from individual machine to top-level
	domain.  In many cases, an organization has implemented an
	organizational "gateway" at a higher level of domain, so
	that people from outside don't have to specify FQDN's to get
	to a specific person.  In the above example, for instance,
	"fooinc.com" may be sufficient to get to anyone inside
	fooinc, and "ferret.marketing" may not be necessary.

	On the other hand, people sometimes leave out the higher
	levels of the address, as in "ferret.marketing".
	This is a bad idea - because if the mail is cc'd out of the
	organization, chances are the external recipient cannot reply,
	because "ferret.marketing" is incomplete.  So use addresses
	that are specified sufficiently for external users to use.
	(fooinc.com if a organizational gateway is used, the whole
	ferret.marketing.fooinc.com if not)

    NIC
	Internet TOP-LEVEL domains (edu, com, gov, mil) are controlled
	by a single organization, the NIC (internic.net).  An organization
	"gets a piece" of the namespace by registering with the NIC, and
	then they are free to administer their own namespace (everything
	under fooinc.com) as they choose.  The same is true for foreign
	countries; Once they have their top-level domain (usually the
	two-letter ISO country code) registered with the NIC, they do
	the rest, and divide it as they see fit.
 
	In contrast, on UUCPnet, all machine names everywhere share a
	single flat namespace.  So it is important to choose a name
	that has not been used before. (See do's and don'ts).  This is
	why FQDN's help.  We can tell the difference between
	ferret.fooinc.com and ferret.blah.edu by their full names.
	(Instead of UUCP paths which may turn out to be wrong, and
	autorouting will probably send the mail to the wrong machine)

    MX record:
	A non-SMTP/Internet site that wishes to register on the Internet
	will need to get a "nearby" Internet site to set up a MX
	record for them.  An MX record is essentially a domain-server
	database record that (effectively) registers your domain name
	on the Internet, and indicates that the Internet site knows
	how to forward mail to you.  Usually via some non-SMTP/Internet
	route, such as UUCP.  You can get an MX record for one site, or
	a "wildcard" MX record so that you can have your own subdomains.

    Bang-Paths:
	With UUCP mail, the MTA has to specify a route to get from one
	machine to another.  "A!B!C!userid" means go to machine A,
	then B, then C, then user "userid" on C.  You should strive,
	however, for a MUA that allows you to use domain addressing,
	and let the MTA figure out the bang routing as appropriate.

Miscellaneous:

    Gateways:
	There are several meanings of this term, only three are relevant
	here.

	The first is a mechanism for getting from one network to another
	network that uses different protocols.

	The second is a mechanism for getting from one logical (often
	organizational) network to another using the same protocol.
	Often for example, there will be a LAN in one department of
	an organization, and one machine in the LAN has the connection
	to another LAN in another department.  This means that mail from
	one LAN to the other has to pass thru the gateway machine.

	Another form, which we'll mention later is that of mail to
	news gatewaying.

    Routers:
	There are several definitions, but the most important is that
	part of the TA that figures out how to send a message to
	a given machine.  This often uses a database that provides
	routes from one machine to the other machines on the network.

    Smarthost:
	In many cases, your machine won't know how to get to a specific
	destination.  You can usually set up your mail system to send mail,
	that it doesn't know how to deliver, to a machine that is more
	likely to.

    RFC's:
	A set of documents that include formal descriptions of mail
	formats used on the Internet, and are adhered to by many
	non-Internet systems.  More specifically, in the "worldnet"
	of Usenet, Internet and UUCP, the RFC's set the standards
	for mail exchange.  RFC822, 1123 and 976 are the most important
	for Internet/UUCP mail.

	It should be pointed out, however, that there are some
	regions where the RFC's are not entirely respected.  For example,
	the British academic email networks (JANET) uses domains, but
	they're specified backwards (they drive on the wrong side of
	the road too ;-).

    MIME:
	Mime is the official proposed standard format for multimedia Internet
	mail encapsulated inside standard Internet RFC 822 messages.  Facilities
	include sending multiple objects in a single message, character sets
	other than US-Ascii, multi-font text messages, non-textual material
	such as images and audio fragments, and other extensions.  For an
 	overview of Mime, see ftp.uu.net:networking/mail/metamail/MIME-overview.txt.Z.
	The defining document is Internet RFC 1341: N Borenstein & N Freed,
	``Mime (Multipurpose Internet Mail Extensions) mechanisms for specifying
	and describing the format of Internet message bodies'' (June 1992).
	Also see RFC 1344: N Borenstein, ``Implications of Mime for Internet
	mail gateways'' (June 1992).
	RFC1341 and 1342 have since been superceded by RFC 1521 and 1522.

	Mime covers only message bodies, not message headers; to see how to
	represent non-Ascii characters in message headers, see Internet
	RFC 1342: K Moore, ``Representation of non-Ascii text in Internet
	message headers'' (June 1992).
    
    X.400:
	A CCITT standard for email formats, more or less an alternative
	to RFC 822/976/1123.  This format will probably start taking over
	from RFC 822/976/1123 mail.  It is likely to (already has?) become an
	ISO/IEEE standard along with OSI etc.

    "The Maps":
	A set of files describing machine-to-machine links distributed
	over Usenet in the group comp.mail.maps.  These are usually posted
	on a monthly schedule, and can be automatically received and
	transformed into a routing database that describes the "optimal"
	route to each machine.  These are operated by the "UUCP Mapping
	Project".  See the README posted along with the maps for
	more details.

    Aliases:
	Aliases are a mechanism by which you can specify the destination
	for mail on your machine.  Through the use of aliases you can
	redirect mail to "virtual userids".  For example, you should
	have a mail destination on your machine called "postmaster", which
	is aliased to send the mail to the System Administrator (ie: you
	probably).  Aliasing often also permits you to send mail to groups
	of users (not necessarily on the same machine as you) pipelines of
	commands or to specific files.

    Mailing lists:
	Are similar to Usenet newsgroups.  They are usually aliases
	pointing to groups of users, and allow mail to be sent to the
	whole group at once.  Mailing lists are set up to carry certain
	subjects.  The difference between a mailing list and a Usenet
	newsgroup is that the messages are sent by mail, probably as
	a copy to each recipient, rather than broadcast.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: NEW! UNIX Email Software Survey FAQ [Part 1 of 3]
Previous Document: Electronic mail - A General Overview of Structure
Next Document: Do's and Don'ts:

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
mailfaq@ferret.ocunix.on.ca (Mail FAQ commentary reception)





Last Update March 27 2014 @ 02:11 PM