The following example provides some sample rewrite rules and shows how some sample addresses would be rewritten by them. For more complete examples which take into account the interaction with the channel definitions, see Section 2.3 .
Suppose the configuration file for the system SC.CS.CMU.EDU contained the following rewrite rules shown in Example 2-1 .
Example 2-1 Rewrite rules for SC.CS.CMU.EDU
sc $U@sc.cs.cmu.edu sc1 $U@sc1.cs.cmu.edu sc2 $U@sc2.cs.cmu.edu * $U%$&0.cs.cmu.edu *.cs $U%$&0.cs.cmu.edu *.cs.cmu $U%$&0.cs.cmu.edu *.cs.cmu.edu $U%$&0.cs.cmu.edu@ds.adm.cmu.edu sc.cs.cmu.edu $U@$D sc1.cs.cmu.edu $U@$D sc2.cs.cmu.edu $U@$D sd.cs.cmu.edu $U@sd.cs.cmu.edu .cmu.edu $U%$H.cmu.edu@cds.adm.cmu.edu .edu $U@$H$D@gate.adm.cmu.edu [] $U@[$L]@gate.adm.cmu.edu
Initial address | Rewritten as | Routed to |
---|---|---|
user@sc | user@sc.cs.cmu.edu | sc.cs.cmu.edu |
user@sc1 | user@sc1.cs.cmu.edu | sc1.cs.cmu.edu |
user@sc2 | user@sc2.cs.cmu.edu | sc2.cs.cmu.edu |
user@sc.cs | user@sc.cs.cmu.edu | sc.cs.cmu.edu |
user@sc1.cs | user@sc1.cs.cmu.edu | sc1.cs.cmu.edu |
user@sc2.cs | user@sc2.cs.cmu.edu | sc2.cs.cmu.edu |
user@sc.cs.cmu | user@sc.cs.cmu.edu | sc.cs.cmu.edu |
user@sc1.cs.cmu | user@sc1.cs.cmu.edu | sc1.cs.cmu.edu |
user@sc2.cs.cmu | user@sc2.cs.cmu.edu | sc2.cs.cmu.edu |
user@sc.cs.cmu.edu | user@sc.cs.cmu.edu | sc.cs.cmu.edu |
user@sc1.cs.cmu.edu | user@sc1.cs.cmu.edu | sc1.cs.cmu.edu |
user@sc2.cs.cmu.edu | user@sc2.cs.cmu.edu | sc2.cs.cmu.edu |
user@sd.cs.cmu.edu | user@sd.cs.cmu.edu | sd.cs.cmu.edu |
user@aa.cs.cmu.edu | user@aa.cs.cmu.edu | ds.adm.cmu.edu |
user@a.eng.cmu.edu | user@a.eng.cmu.edu | cds.adm.cmu.edu |
user@a.cs.ohio.edu | user@a.cs.ohio.edu | gate.adm.cmu.edu --- route inserted |
user@b.cs.ohio.edu | user@b.cs.ohio.edu | gate.adm.cmu.edu --- route inserted |
user@[1.2.3.4] | user@[1.2.3.4] | gate.adm.cmu.edu --- route inserted |
Basically, what these rewrite rules say is: If the host name is one of our short-form names (sc, sc1 or sc2) or if it is one of our full names (sc.cs.cmu.edu, etc.), expand it to our full name and route it to us. Append cs.cmu.edu to one part shortform names and try again. Convert one part followed by .cs to one part followed by .cs.cmu.edu and try again. Also convert .cs.cmu to .cs.cmu.edu and try again.
If the name is sd.cs.cmu.edu (some system we connect to directly, perhaps) rewrite and route it there. If the host name is anything else in the .cs.cmu.edu subdomain, route it to ds.cs.cmu.edu (the gateway for the .cs.cmu.edu subdomain). If the host name is anything else in the .cmu.edu subdomain route it to cds.adm.cmu.edu (the gateway for the .cmu.edu subdomain). If the host name is anything else in the .edu top-level domain route it to gate.adm.cmu.edu (which is presumably capable of routing the message to its proper destination). If a domain literal is used send it to gate.adm.cmu.edu as well.
Most applications of rewrite rules (like the previous example) will not change the username (or mailbox) part of the address in any way. The ability to change the username part of the address is used when PMDF is used to interface to mailers that do not conform to RFC 822 --- mailers where it is necessary to stuff portions of the host/domain specification into the username part of the address. This capability should be used with great care if it is used at all.