Usually, mail to hosts with fully-qualified-domain-names is delivered via Internet-style (SMTP) delivery based on the domain name server (DNS) configuration. The uucpxtable forces delivery via UUCP routing by converting the domainized name into a UUCP-style un-domainized remote hostname.
It is frequently used when you're a MX forwarder for a site or (sub)domain or when you wish to send mail via a direct and reliable UUCP link rather than potentially multiple hops through the default mailer and any intermediate systems and networks.
UUCP sites that talk to UUCP neighbors who use domainized mail headers would use this file to force delivery of the mail through the direct UUCP point-to-point link between the two systems rather than using the less direct route of through the RELAY_MAILER and RELAY_HOST or through the DEFAULT_MAILER.
Internet sites who do not talk UUCP probably would not use the uucpxtable.
Suppose you provide MX forwarding service to a system called 'foo.bar.com' in DNS and 'foobarcom' in the UUCP maps. You would need the following uucpxtable entry to force incoming mail for their host to go through your direct UUCP connection.
#======= /usr/local/lib/mail/uucpxtable ========== #Mail sent to email@example.com is rewritten to foobarcom!joe and #therefore delivered via UUCP # foobarcom foo.bar.com # #-------------------------
The pathtable is used to define explicit routing to remote hosts or networks. The pathtable file should be in pathalias-style syntax, sorted alphabetically.
Most systems will not need any pathtable entries.
#======== /usr/local/lib/mail/pathtable ========== # # this is a pathalias-style paths file to let you kick mail to # uucp neighbors to the direct uucp path so you don't have to # go the long way through your smart host that takes other traffic # # you want real tabs on each line or m4 might complain... # # pathalias-style routing through a system foo!bar!%s bar # # mixed mode address firstname.lastname@example.org foo # # # all mail for a network to a gateway (see the leading '.' ?) %email@example.com .UUCP firstname.lastname@example.org .BITNET # # #============ end of pathtable ===============
The domaintable is generally used to force certain behavior to occur after a DNS lookup has occurred. It permits the administrator to make shorthand names available for commonly referenced systems or domains by replacing the shorthand name with the proper one automatically. It can also be used to replace incorrect host.domain information with 'correct' information.
Most sites will not need any domaintable entries.
#========= /usr/local/lib/mail/domaintable ======= # #replace a wrong domain people are mailing to with the correct one # brokenhost.correct.domain brokenhost.wrong.domain # # #============ end of domaintable =============
Aliases permit a number of things to happen:
provide a shorthand or well-known name for mail to be addressed to in order to go to one or more persons
invoke a program with the mail message as the input to the program
send mail to a file
All systems require aliases for Postmaster and MAILER- DAEMON to be RFC-compliant. Always be extremely aware of security when defining aliases that invoke programs or write to programs since sendmail generally runs setuid-root.
Changes to the aliases file do not take effect until the '/usr/lib/sendmail -bi' command is executed to build the required dbm tables. This can also be done by executing the 'newaliases' command, usually from cron.
Details concerning mail aliases may be found in the aliases(5) manual page.
The following tables are available, but rather infrequently used. Consult with the documentation that comes with the sendmail+IDA sources for details.
The uucprelays file is used to 'short-circuit' the uucp path to especially well-known sites rather than using a multi-hop or unreliable path generated by processing the UUCP maps with pathalias.
genericfrom and xaliases
The genericfrom file hides local usernames and addresses from the outside world by automatically converting inside usernames to generic 'From' addresses that do not match internal usernames.
The associated 'xalparse' utility automates the generation of the genericfrom and aliases file so that both incoming and outgoing username translations occur from a master xaliases file.
The decnetxtable rewrites domainized addresses into decnet-style addresses much like the domaintable rewrites undomainized addresses into domainized SMTP-style addresses.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SourceClear Open
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide