Linux Network Administrator Manual (13)
2000-07-30 20:06
Publisher: NetBull Readings: 1143 Translation: Zhao Wei GoHigh@shtdu.edu.cn Chapter 13 Email Since the first network is designed, one of the most significant purposes is email. It starts from a simple service that copies a file from a machine to another machine and adds the copy of the file to the recipient's mailbox file. In essence, this is still all of the work made by Email, although the growing network and its complex routing needs and its increasing message load have prompted the requirements for more careful production. Various mail exchanges have been designed. The site on the Internet always adheres to the design in the RFC 822 and is expressed in some RFCs that are not related to the machine-independent transmission special character method. More think about "Multimedia Mail" has also been made, which involves containing graphics and sounds in the mail message. Another standard, X.400, has also been defined by ccitt. Mail Transfer Programs with many UN * X systems are implemented. The most famous is the SENDMAIL of the Berkeley University, which is used in many platforms. The initial author is Eric Allman, and he is now actively working in the Sendmail team. There are two Linux transplanted versions of Sendmail-5.56C, one of which will be discussed in Chapter 15. The Sendmail version currently under development is 8.6.5. Linux's most commonly used mail agent is SMAIL-3.1.28, written and copyright by Curt Landon Noll and Ronald S.karr. This program is included in most Linux distributions. Below, we will abbreviate it as SMAIL, although there are other completely different versions, but we don't discuss them here. SMAIL is very simple compared to Sendmail. When a small site that does not have a complex route requires a message, the performance of both is very similar. However, for large sites, Sendmail can always be higher because it is very flexible. SMAIL and Sendmail are enough to support a family profile, they all need to perform custom (custom). In addition to the information necessary for the mail subsystem (such as the local host name), there are many parameters to be adjusted. The main configuration file of Sendmail is very difficult to understand. It looks like your cat hits it on the keyboard that presses the Shift key. SMAIL profile is very structured and is easier to understand than Sendmail, but no user has strong ability to adjust mailbox performance. However, for small UUCP or Internet sites, their configuration is basically the same. In this chapter, we will discuss what is email and what questions you have to involve as an administrator. Chapter 14 and Chapter 15 will give guidance for the first setting of SMAIL and Sendmail. The information provided there is enough to let a small site work, but there are many options that you can spend a lot of happiness at your computer to configure these wonderful features. At the end of this chapter, we will summarize the ELM settings, which is a very common mail user agent that many UN * X systems (including Linux). For more information on email issues on Linux, please refer to Vince Skahan's Electronic Mail HowTo, which is scheduled to be delivered to comp.os.linux.announce. ELM, SMAIL and SENDMAIL Source Processing also contains very wide documentation, and can answer most of the issues encountered when they are set. If you are looking for general information about email, there are many RFCs involving this aspect. They are listed in the reference books after this book.
13.1 What is an mail message? A mail message is made by a message - it is the text written by the sender, as well as the specific data, transmission media, etc. of the recipient, the information you have seen very like a letter. These management data can be divided into two categories; the first category is data related to a particular transmission medium, just like the address of the sender and the recipient. Therefore they are called Envelope. They may be converted in the messaging path. The second category is any of the data required to process the message message, which is not for any transmission mechanism, such as the Subject Line, all the recipient list, and the date of sending. In many networks, these data have been added to the mail message, which has become a standard to form a so-called mail header. It is separated from the mail body. [1] Un * x Many mail transmission software in the world uses the headed [Title] format specified in the RFC 822. Its initial purpose is to specify a standard on the use of ARPANET, but because it is designed to be independent of any environment, it is easily adopted by other networks, including many UUCP-based networks. However, RFC 822 is only the greatest common groundstone. More standards have been conceived to cope with growing demand, such as data encryption, support, and multimedia mail extensions (MIME). In all of these standards, the title [head] consists of several lines, and is divided by a lift. Each row is consisting of a field name starting from the first column, and a field of a colon and a space divided. The format and semantics of each field varies depending on the character name. If the next line begins with a Tab, it is indicated as the continuation of the title field. The order of each field is random. A typical email title looks like this: from brewhq.swb.de! Ora.com! Andyo Wed Apr 13 00:17:03 1994 Return-path: receive: from brewhq.swb.de by monad.swb.de With uucp
(SMAIL3.1.28.1 # 6) ID M0PQQLT-00023AB; WED, 13 APR 94 00:17 Met DST
Received: from ora.com (ruby.ora.com) by Brewhq.Swb.de with smtp
(SMAIL3.1.28.1 # 28.6) ID
; Tue, 12 APR 94 21:47 MEST
Received: by ruby.ora.com (8.6.8 / 8.6.4) ID RAA26438; Tue, 12 ARP 94 15:56 -0400
Date: Tue, 12 Apr 1994 15:56:49 -0400
Message-ID: 199404121956.paa07787@ruby
From: Andyo@ora.com (andy oram)
TO: okir@monad.swb.de
Subject: Re: Your RPC Section
Typically, all required titles fields are generated by the mail program interface you are using, like ELM, PINE, MUCH, or Mailx. However, some fields are optional and can be added by the user. For example, ELM allows you to edit some message headers [Title]. And others are added by the mail transfer software. The common title fields and their meanings are as follows:
From: With the email address of the sender, and may have a "real name". Here is a complete zoo in a format.
TO: This is the address of the recipient.
Subject: Describe the contents of the message with several words. At least this is what should be done.
Date: Date of mail sent.
Reply-to: The sender specifies the address sent by the recipient reply. For you have a few accounts, but just want to receive a lot of emails under your usual account, this field is very useful. This field is optional. Organization: The organization to which the machine generated by the mail is generated. If your machine belongs to you, you can empty the field or insert "personal" or some completely meaningful thing. This field is an optional field.
Message-id: The string generated by the mail transfer program generated by the system generated by the message. For this message, it is unique.
Received: Handle each site of your message (including the sender and receiver machine) inserted in the title, give its site name, a message ID, receive the time and date of the message, which site Come and use which transfer software. Based on this, you can track the routing of the message, and if you have a mistake you can complain about the responsible person.
X-Anything: It does not work with any mail-related programs with the title line of X-beginning. It is used to implement additional features that have not been written or impossible to write RFC. For example, it is used in the LINUX Activists mailing list, where is the use of the X-Mn-Key: Title field to select the channel.
One exception to this structure is the most beginning. It starts with keyword from, it is a space but a colon. In order to distinguish from a normal from: field, it is usually referenced to from_. It contains routing of the UUCP in the UUCP participated in the message (hereinafter will be explained below), the last time and date of the last received message, and the optional part indicating which host receives. Since each system is handled, this field is generated, it is usually included under the envelope data.
So the FROM_ field is backward compatible with some old-fashioned mail programs, but no longer used, in addition to the mail user interface program, depending on it, determines the beginning of a message in the user mail box. It is also to eliminate the potential problems caused by the rows in the message body starting with "from", placing ">" before it is to avoid any such phenomenon, which has become a standard method.
13.2 How is the mail delivery?
Generally speaking, you want to use a mail interface programmail icon Mail or Mailx to write an email; or use more complex icons ELM, Mush or Pine. These programs are collectively referred to as mail user agents, or simply as MUA. If you send a message message, then in most cases the interface (interface) program will pass it to another program to deliver. This program is called the mail transport agent, or simply referred to as MTA. In some systems, there are different mail transport agents for local and remote delivery; only one is available on other systems. The remote delivery command is often referred to as RMAIL, and the other is called LMAIL (if present).
Of course, the delivery of local messages is just that the message will be attached to the recipient's mailbox. Typically, the local MTA is an understanding of an alias (set the address of the recipient to other addresses), and forwarded (redirect the user's mail to some other destination). Similarly, messages that cannot be delivered usually have to rebound back, that is, the incoming information is included with the sender.
For remote delivery operations, the transmission software used is dependent on the properties of the link. If a message must be delivered on the network using TCP / IP, SMTP is often used. SMTP represents Simple Mail Transfer Protocol, which is defined in RFC 788 and RFC 821. SMTP is usually connected directly to the recipient's machine, and negotiates the transmission of messages with the remote SMTP background program (Daemon). In a UUCP network, emails are usually not delivered directly, but forward them from a series of intermediate systems to the destination host. In order to send a message on the UUCP link, sending MTA usually performs RMAIL using UUX in forwarding systems, and feeds the message to the forwarding system on the standard input.
Since this is to operate separately for each message, this will produce a considerable workload on the main mail hub, and hundreds of small files consisting of hundreds of small files consumed in unprivorable disk space. [2] So some MTA allows you to collect several messages from the remote system with a batch file. If you use a direct SMTP connection, this batch file usually contains the SMTP command to be issued by the local host. This is called BSMTP, or BATCHED SMTP. At this point, this batch will be sent to the RSMTP or BSMTP program in the remote system, and the remote system will process the input as normal SMTP connection.
13.3 Email Address
For email, the address is at least the name of the machine that handles the person's mail, and the code of the user that can identify the user. This can be the registered name of the recipient, but it can also be any other code. Other mail address schemes, like X.400, use a more general "property" set, used to query the recipient's host in an X.500 directory server.
A machine name is explained, that is, which site your message will eventually end, and how to combine this name with the recipient's username, which depends largely on your network.
The Internet site is compliant with RFC 822 standard, it requires use of user@host.domain, here Host.Domain, full-owned domain name (Fully Qualified Domain Name). The symbols are called "in" ("at") symbol. Because this representation does not contain routes that have to the host host, it gives a (unique) host name, which is called an absolute address.
In the initial UUCP environment, the popular form is PATH! Host! User, where Path describes a series of hosts that have been received before the host. This structure is called the Bang Path representation, because an exclamation mark is approximately called a "Bang". Today, many UUCP-based networks have used RFC 822 and can understand such address types.
Today, these two address types cannot be fused well. Suppose there is an address hosta! User @ hostb. This is not clear whether the '@' symbol is preferred on this path; if we must send the message to Hostb, then send it to Hosta! User, or send it to Hosta, forward to user @ hostb?
However, there is a method specified by RFC 822: <@ hosta, @ hostb: user @ hostc> Indicates the address of User on Hostc, where Hostc will pass through Hosta and HostB (in this order). This type of address is often referred to as Route-AddR address.
Also, there is a '%' address operator: user% hostb @ Hosta will first be sent to Hosta, which will extend the rightmost (in the case of only here) into a '@' symbol. Now this address has become user @ hostb, and the mail program will forward your message to Hostb, and then deliver it to user. This type of address is sometimes referred to as "Ye Olde ArpaNet Kludge, which is not approved. However, many mail transport agents produce such an address type. Other networks have different address schemes. For example, a DECNET-based network uses two colons as a splitter of the address, generating a host :: user address. [3] Finally, the X.400 standard uses a completely different solution, which is the same as the national and organizations described by using a recipient by using a family attribute-value.
On Fidonet, each user is determined to use a code icon 2; 320 / 204.9, consisting of four numbers, indicating that the area zone (2 represents Europe), network NET (320 represents Paris and suburbs), Node Node (local HUB) ) And point POINT (personal user PC). The address of the FIDONET can be mapped to the RFC 822; the above address can be written as thomas.quinot@p9.f204.n320.z2.fidonet.org. Now I have not said the domain name?
With these different address types have some implicit, this will be discussed in the following sections. However, in an RFC 822 environment, in addition to absolute address like User@host.domain, you rarely use other address types.
13.4 How does the mail rout work?
The process of oriented a message to the recipient host is called routing. In addition to finding a path from the sending site to the destination, it also includes error detection and speed and cost optimization.
The method of the UUCP site handling routing and the Internet site is very different from the Internet site. On the Internet, the main task of oriented to the recipient's host (determined by its IP address) is done by the network layer of IP, and in the UUCP area, the route must be provided by the user, or transmitted by mail Agent generation.
13.4.1 Mail Routing on the Internet
On the Internet, it completely relies on whether the destination host is to perform any specific mail routing. The default is to deliver the message to the destination host by finding the IP address of the destination host, and works the routing of the actual data to the IP transport layer.
Many sites typically want to guide all inbound messages into an efficient and stable mail server, which can process all of these data traffic and let it distribute emails locally. To declare this service, the site publishes a so-called MX record for their local domain in the DNS database. The MX representative mail switch is basically means that server hosts are willing to act as a mail forwarder for all machines in this domain. MX records can also be used to handle traffic traffic from hosts that are not connected to the Internet, such as a UUCP network, or a host that carries confidential information.
The MX record also has a preference related to it. This is a positive integer. For a host if there are several mail switches, the mail transfer agent will try to transfer messages to have a minimum priority exchanger, and try a high-level priority when doing this failure. Value host. If the local host itself is a mail switch of the destination address, it does not have to forward messages to any host that is high than yourself; this is a safety method to avoid mail loop (loops). Suppose there is a company named FooBar Inc., you want all of them to handle them from their machines called Mailhub. Then they should have a MX record like this in the DNS database:
Foobar.com in mx 5 mailhub.foobar.com
This announced that mailhub.foobar.com is a mail switch with priority 5 on foobar.com. A host who wants to deliver a message to joe@greenhouse.foobar.com to check the foobar.com's DNS, which will find that the MX record points to Mailhub. If there is no other MX that is less than 5 at this time, this message will be delivered to mailhub and then distributed to Greenhouse.
The above is actually only a contour of how MX records work. For more information on messaging on the Internet, please refer to RFC 974.
13.4.2 Mail Routing in the UUCP World
The mail routing on the UUCP network is much more complicated than the Internet, because the transfer software itself does not perform any route selection functions. In the early days, all emails have to be addressed in bang paths. Bang Paths specifies a list of hosts, and each host name is separated by exclamation mark, and the message is forwarded by these hosts, and the username is resembled. In order to add a letter to the Janet user on the machine called Moria, you have to use the path EEK! Swim! Moria! Janet. This will send your email from your host to EEK, and then send it from EEK to SWIM last to MORIA.
This technique is obvious, it requires you to remember a lot of details about the network topology, fast links, etc. Worse, the change in the network topology - the link is deleted or the host is removed - the failure of the message transmission, simple reason is just because you don't know the network structure. Also, if you move to a different place, you are likely to update all of these routes.
However, there is also a thing that causes the source routing to become an unclear (polyfang) hostname: for example, suppose there are two sites named Moria, one in U.S., and another in France. So what is Moria! Janet refers to? This can be clear by indicating the path to MORIA.
The first step in eliminating the multi-master name is the establishment of the UUCP Maping Project. It is located in RUTGERS universities, registers all official [official] UUCP hosts and records their uucp neighbors and their geographic location, and believes that there is no host name to be used twice. The information collected by the mapping plan group is published as the USENET MAPS, which will periodically release. [4] A typical system entry in Map looks like this (after deleting the comment statement).
Moria
Bert (Daily / 2),
Swim (Weekly)
This entry indicates that Moria has a connection to the BERT - MORIA calls twice a day, and a connection to Swim-Moria calls it once a week. Below we will discuss the format of the mapping file in more detail.
With the connection information provided in the mapping file, you can automatically generate a full path to your host to reach any destination site. This information is typically stored in the Paths file, sometimes also known as the path, Database. Suppose the mapping indicates that you can reach the BERT through Ernie, then generate the path to the MORIA from the above mapping looks like this: Moria Ernie! Bert! Moria% s
If you give a destination address janet@moria.uucp, your MTA will get the above routing and use Bert! Moria! Janet as the envelope address to Ernie.
However, it is not a good idea to create a PATHS file from a complete USENET image. The information provided is usually misleading, and sometimes it is too time. Therefore, only a few major hosts use a complete UUCP world map to create their PATHS files. Most sites only maintain their routing information of their surrounding sites and send any messages that need to be sent to the site that can not be found in their databases to a sensitive host with more complete route selection information. This solution is called a sensitive-host routing (Smart-Host Routing). Only a UUCP message connection host (that is, the so-called page site (Leaf seats) itself does not do any route selection; they are completely dependent on their sensitive-host.
13.4.3 Mixed UUCP and RFC 822
The best solution for the UUCP network mail routing problem so far is that the domain name system is used in the UUCP network. Of course, you can't query a name server on UUCP. However, many UUCP sites have formed a small domain that coordinated with routing selection inside. In the map, these fields claim that one or two hosts as their mail gateway, so there is no need to have a mapping entry for each host in the domain. The gateway will handle all messages inflows and outflow. The routing option in the domain is completely invisible for the outside world.
This method is very good with the above-mentioned sensitive-host route options. The global routing information is only maintained by the gateway; a domain with very few hosts will have only one small handwritten paths file, which lists the routes in their domain, and the route to the mail HUB. Even if the mail gateway no longer needs to have routing information in the world, except for the full routing information of the domain they serves, only the routes in their database are required to be included in their databases. For example, the path-name entry (Pathalias Entry) will route the mail of all sites in the Sub.org domain to smurf:
.sub.org swim! smurf!% s
Any message addressed to claire@jones.sub.org will be sent to SWIM as the envelope address as the envelope address.
The hierarchical organizational structure of the domain name space allows the mail server to mix very specific routes with a general route. For example, a system in France may have a specific route to the FR domain, but will route messages in the US domain to a system in U.S.. In this way, the domain-based routing (as referred to as this technology) greatly reduces the size of the route selection database and the required management burden.
However, the main benefit of using domain names in a UUCP environment is that the compatibility between the RFC 822 makes the gateway between the UUCP network and the Internet become simple. Many UUCP fields today have a link to act as their sensitive-host. The message is sent faster through the Internet, and the route selection information is more reliable because the Internet host can use DNS instead of the USENET mapping.
In order to pass from the Internet, the UUCP-based domain usually has its own Internet gateway to declare a MX record (the MX has been discussed above). For example, suppose MORIAs belong to the OrcNet.org domain. GCC2.Groucho.edu as their Internet gateway. Thus Moria uses GCC2 as its sensitive-host, all messages sent to the external domain have passed through the Internet. On the other hand, GCC2 will declare an MX record for ORCNET.org and deliver all inbound mail entering the ORCNET site to Moria. There is also a problem that the problem is that the UUCP transfer program cannot handle the wholly-owned domain name. Most UUCP sites are designed to cope with some of the site names that are more than eight characters, and some are less, and the characters that use non-alpantuous numbers are completely impossible.
Therefore, there is a need for RFC 822 names between the UUCP hostname. The mapping method is completely dependent on implementation. A common way to map FQDN to UUCP names is to use path alias:
Moria.orcnet.org ernie! bert! Moria!% s
This will generate a pure UUCP style Bang Path from the address of a full-restriction name. Some mail programs provide a special file for this; for example, Sendmail uses uucpxtable for this.
When you need to send an email to the Internet from a UUCP network, it is sometimes necessary to reverse conversion (commonly referred to as domain name). Since the message sender uses a full-scale domain name in the destination address, this problem can be avoided by deleting a domain at the forwarding message on the envelope address. However, there are still some UUCP sites that do not belong to any domain. They are usually dominated by an additional pseudo-domain uuCP.
13.5 path alias and mapping file format
The path alias database provides the main routing information in the UUCP-based network. A typical entry looks like this (the site name and the path are separated):
Moria.orcnet.org ernie! bert! Moria!% s
Moria Ernie! Bert! Moria!% s
This allows any messages of MORIA to be delivered through Ernie and Bert. If the mail program does not map independent methods of mapping between these names, Moria's wholly-owned name and its UUCP name must be given.
If you want to direct all the messages sent in a domain to its mail relay, you also need to specify a path in the path retrieval database, give the domain name as the target, and place a point before the domain name. For example, if all hosts in Sub.org arrive with Swim! Smurf, the path alias looks like this:
.sub.org swim! smurf!% s
It is feasible to write a path alias file only when you run the site without a lot of routing. If you want to route a large number of hosts, then a better way is to create this file from the mapping file using the Pathalias command. Mappings can be easily maintained because you can easily join and remove a system by editing a mapping entry, and recreate the mapping file. Although mapping published by UseNet Mapping Project is no longer used for routing, smaller UUCP networks can still provide routing information in their own mapping.
A mapping file is mainly consisting of a list of sites, lists sites for each system query and query. The system name starts from the first column, followed by a comma-separated linked list. The list can continue if the next line begins with a tab. Each link consists of a price that is hosted by a bracket after name. The cost is an arithmetic expression that consists of a quotation of numbers and symbols. The rows starting with HASH symbols will be ignored.
As an example, consider MORIA, it queries Swim.Twobirds.com every day, query bert.sesame.com once a week. What's more, the link to the BERT only uses a low speed 2400 bps modem. Moria will release the following mapping entry: moria.orcnet.org
Bert.Sesame.com (Daily / 2),
Swim.twobirds.com (Weekly Low)
Moria.orcnet.org = Moria
The last line also makes it known under its UUCP name. Note that it must be daily / 2, because the call is intempt twice a day in fact that this connection is halved.
Using the information in the map of Pathalias can calculate the optimized path to any destination site in the path file, and generate a path-name database, then this database can be used to go to the route selection of these sites.
Pathalias also offers several features such as a site hidden (i.e., let the site can only access the gateway). See the Pathalias handbook for details and link costs.
Note in the mapping file typically contains additional information for the description site. Note There is a fixed format, so this information can be drawn from the mapping file. For example, a program called UUWHO displays this information using a database created from the mapping file.
When you register your site when you issue a map of your members, you want to fill in such a mapping entry.
Below is a sample of mapping entries (actually, it is my site):
#N monad, monad.swb.de, monad.swb.sub.org
#S at 486dx50; linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U Brewhq
#W okir@monad.swb.de (OLAF KIRCH); Sun Jul 25 16:59:32 Met DST 1993
#
Monad Brewhq (Dally / 2)
# Domains
Monad = monad.swb.de
Monad = monad.swb.sub.org
The space behind the first two characters is a patriotic Tab. Most of the paragraphs mean very clearly; you will receive a detailed description from the domain you registered. The L field is very interesting: it gives your geographic location with latitude and latitude to draw a map showing all sites in each country and maps around the world. [5]
13.6 Configuring ELM
ELM represents "Electronic Mail" means one of the very reasonable named UN * X tools. It provides a full-screen interface and has a good help feature. Here we don't discuss how to use ELM, but in detail its configuration options.
In theory, you can run ELM without configuring you, and you have a good job - if you are lucky. But there are several options that must be configured, although it is only necessary.
When the ELM starts running, it reads a family configuration variable from the ELM.rc file in / usr / lib / ELM /. Then it will try to read the file in your home directory .elm / Elmrc. This file is generally not written by you. It is created when you select "Save Options" from the option menu of ELM.
The option set of private ELMRC files also exists in the global ELM.RC file. Many of your private ELMRC files will overwrite the options in the global file.
13.6.1 Global ELM Options
In the global ELM.RC file, you must set an option that belongs to your hostname. For example, in a virtual winery, this file of Vlager will contain the following information: #
# The local hostname
Hostname = VLAGER
#
# Domain Name
Hostdomain = .vbrew.com
#
# Full QUALLIFIED DOMAIN NAME
HostfullName = VLAGER.vbrew.com
These options set the concept of the local host name of the ELM. Although this information is rare, you should set these options. Note that these options are only valid in the global configuration file; they will be ignored when they exist in the private ELMRC.
13.6.2 National Character Set
Recently, there have been proposed to fix RFC 822 standards to support various types of packets, such as plain text, binary data, postscript file, etc. Standard sets and RFCs are commonly referred to as MIME, or multi-purpose internet mail extensions. In other aspects, this also enables the recipient to know whether the non-standard ASCII code is used when writing messages, for example, using French accent or German vagado symbols. ELM supports these extensions to some extent.
The character set used inside Linux indicates that characters is usually referred to as ISO-8859-1, which is the name of the standard it complies. It also known as Latin-1. Any message using this character set should be below the title section:
Content-Type: Text / Plain; Charset = ISO-8859-1
The receiving system recognizes this field and takes certain measures when displaying information. The default value for Text / Plain information is a value of US-ASCII.
In order to display information about non-ASCII character sets, ELM must know how to print these characters. By default, when the ELM receives information that the CHARSET field is non-US-ASCII (or Conten Type is not a text / place), it tries to display information using a command called Metamail. The information you need to use Metamail displays one 'm' in the first column of the viewing window.
Since the character set of Linux is ISO-8859-1, calling Metamail Use this character set to display information unnecessary. If the ELM is notified that it is possible to understand ISO-8859-1, it will not use Metamail, but directly display information. This can be done by setting the following options in the overall ELM.RC:
Displaycharset = ISO-8859-1
Note that even when you never send and receive information containing any non-ASCII, you should set this option. This is because people often configure their mail programs to place the appropriate content-type: fields in the message of the message, regardless of whether they only send ASCII information.
However, setting this option in ELM.RC is not enough. The problem is when the information is displayed with the built-in profile program, ELM calls a library function for each character to determine if the character is printed. By default, this function will only recognize the ASCII character as the printable character, and display all other characters as "^?". You can overcome this problem by setting an environment variable lc_cType to ISO-8859-1, which is notified that the library function is prinable. The library supports this and other features from LIBC-4.5.8.
When sending information with special characters in ISO-8859-1, you should be sure to set up two variables in the ELM.rc file:
Charset = ISO-8859-1
TEXTENCODING = 8bit This allows ELM to report the character set in the message header is ISO-8859-1, and transmit it as an 8 bit value (the default is to strip all characters into 7 bits).
Of course, any of these options can be set in private ELMRC files in addition to the global ELM.RC file.
Comment
[1] Usually habitually adds a signature or .sig, usually contains information about the author, as well as a joke or a right. It is separated from the mail message to a line with "-".
[2] This is because the distribution of disk space is usually in units of 1024 bytes. So, even if you have a maximum of 400 bytes of messages, you have to eat a full KB space.
[3] When trying to reach a DECNET address from an RFC 822 environment, you can use "Host :: User" @relay, here is a known Internet-Decnet relay.
[4] The mapping of the site registered in the UUCP mapping plan is released through newsgroups moduil.maps; other organizations will also publish mappings of their network.
[5] They regularly deliver to News.Lists.ps-Maps. Note that they are very huge.
source:
Linux free pigeon
