| Previous | Next | Contents | Index |
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.EXAMPLE.COM contained the following rewrite rules shown in Example 2-1.
| Example 2-1 Rewrite Rules for SC.CS.EXAMPLE.COM |
|---|
sc $U@sc.cs.example.com sc1 $U@sc1.cs.example.com sc2 $U@sc2.cs.example.com * $U%$&0.cs.example.com *.cs $U%$&0.cs.example.com *.cs.example $U%$&0.cs.example.com *.cs.example.com $U%$&0.cs.example.com@ds.adm.example.com sc.cs.example.com $U@$D sc1.cs.example.com $U@$D sc2.cs.example.com $U@$D sd.cs.example.com $U@sd.cs.example.com .example.com $U%$H.example.com@cds.adm.example.com .com $U@$H$D@gate.adm.example.com [] $U@[$L]@gate.adm.example.com |
| Initial address | Rewritten as | Routed to |
|---|---|---|
| user@sc | user@sc.cs.example.com | sc.cs.example.com |
| user@sc1 | user@sc1.cs.example.com | sc1.cs.example.com |
| user@sc2 | user@sc2.cs.example.com | sc2.cs.example.com |
| user@sc.cs | user@sc.cs.example.com | sc.cs.example.com |
| user@sc1.cs | user@sc1.cs.example.com | sc1.cs.example.com |
| user@sc2.cs | user@sc2.cs.example.com | sc2.cs.example.com |
| user@sc.cs.example | user@sc.cs.example.com | sc.cs.example.com |
| user@sc1.cs.example | user@sc1.cs.example.com | sc1.cs.example.com |
| user@sc2.cs.example | user@sc2.cs.example.com | sc2.cs.example.com |
| user@sc.cs.example.com | user@sc.cs.example.com | sc.cs.example.com |
| user@sc1.cs.example.com | user@sc1.cs.example.com | sc1.cs.example.com |
| user@sc2.cs.example.com | user@sc2.cs.example.com | sc2.cs.example.com |
| user@sd.cs.example.com | user@sd.cs.example.com | sd.cs.example.com |
| user@aa.cs.example.com | user@aa.cs.example.com | ds.adm.example.com |
| user@a.eng.example.com | user@a.eng.example.com | cds.adm.example.com |
| user@a.cs.example1.edu | user@a.cs.example1.edu | gate.adm.example.com --- route inserted |
| user@b.cs.example1.edu | user@b.cs.example1.edu | gate.adm.example.com --- route inserted |
| user@[1.2.3.4] | user@[1.2.3.4] | gate.adm.example.com --- 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.example.com, etc.), expand it to our full name and route it to us. Append cs.example.com to one part shortform names and try again. Convert one part followed by .cs to one part followed by .cs.example.com and try again. Also convert .cs.example to .cs.example.com and try again.
If the name is sd.cs.example.com (some system we connect to directly, perhaps) rewrite and route it there. If the host name is anything else in the .cs.example.com subdomain, route it to ds.cs.example.com (the gateway for the .cs.example.com subdomain). If the host name is anything else in the .example.com subdomain route it to cds.adm.example.com (the gateway for the .example.com subdomain). If the host name is anything else in the .com top-level domain route it to gate.adm.example.com (which is presumably capable of routing the message to its proper destination). If a domain literal is used send it to gate.adm.example.com 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.
| Previous | Next | Contents | Index |