The process of rewriting an address starts by extracting the first host/domain specification from the address. (Readers who are not familiar with RFC 822 address conventions are advised to read that standard, at least in a cursory fashion, at this point in order to understand the following discussion.) The order in which host/domain specifications in the address are scanned is as follows:
bangoverpercentkeyword is in effect on the channel that is doing the address rewriting. That is, if the channel which is attempting to enqueue the message is itself marked with the
Some highly hypothetical examples of addresses and the host name that would be extracted first are shown below:
|Address||First host/domain specification||Comments|
|user@a||a||a is a "short-form" domain name|
|email@example.com||a.b.c||a.b.c is a "fully-qualified" domain name (FQDN)|
|firstname.lastname@example.org||[0.1.2.3]||[0.1.2.3] is a "domain literal"|
|@a:email@example.com||a||This is a source-routed address with a a short-form domain name, the "route"|
|@a.b.c:firstname.lastname@example.org||a.b.c||Source routed address, route part is fully-qualified|
|@[0.1.2.3]:email@example.com||[0.1.2.3]||Source-routed address, route part is a domain literal|
|@a,@b,@c:firstname.lastname@example.org||a||Source-routed address with an a to b to c routing|
|@a,@[0.1.2.3]:user@b||a||Source-routed address with a domain literal in the route part|
|user%A@B||B||This non-standard form of routing is called a "percent hack"|
|user%A%B%C@D||D||A built up percent hack|
|user%A%%B||A%%B||Of questionable value|
|A!user||A||"Bang-style" addressing; commonly used for UUCP|
|@A,@B:C!user%D@E||A||Too grotesque to consider, really|
The special interpretation of repeated percent signs is used to allow percent signs as part of local usernames, which is used in handling PSIMail and other foreign mail system addresses. The interpretation of exclamation points conforms to RFC 976's "bang-style" address conventions and makes it possible to use UUCP addresses with PMDF.
The order of these interpretations is not specified by either RFC 822
or RFC 976, so the
nobangoverpercent keywords can be used to control the
order in which they are applied by the channel doing the rewriting.
Note that the default is more "standard", although the
alternate setting may be useful under some circumstances.
8 For instance, if this is a message being sent from a user agent, then the enqueuing channel --- the channel doing the rewriting --- would be the local, l, channel. If it is a message coming in from Message Router via PMDF-MR then usually it will be the mr_local channel doing the rewriting. And, if it is a message coming in from DECUS UUCP, then the vn_gateway channel will be doing the rewriting.