Extracting the First Host/Domain Specification

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:

Hosts in source routes (read from left to right)

Hosts appearing to the right of the at sign (@)

Hosts appearing to the right of the last single percent sign (%)

Hosts appearing to the left of the first exclamation point (!)

The order of the last two items are switched if the bangoverpercent keyword is in effect on the channel that is doing the address rewriting. That is, if the channel attempting to enqueue the message is, itself, marked with the bangoverpercent channel keyword.

Some hypothetical examples of addresses and the hostnames that could be extracted first are shown in TABLE 3-1:

TABLE  3-1   Examples of Extracted Addresses and Hostnames

Address	First host domain specification	Comments
user@a	a	a is a "short-form" domain name
user@a.b.c	a.b.c	a.b.c is a "fully qualified" domain name (FQDN)
user@[0.1.2.3]	[0.1.2.3]	[0.1.2.3] is a "domain literal"
@a:user@b.c.d	a	This is a source-routed address with a short-form domain name, the "route"
@a.b.c:user@d.e.f	a.b.c	Source-routed address; route part is fully-qualified
@[0.1.2.3]:user@d.e.f	[0.1.2.3]	Source-routed address; route part is a domain literal
@a,@b,@c:user@d.e.f	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 nonstandard form of routing is called a "percent hack"
user%A%B%C@D	D	A built-up percent hack
user%A	A
user%A%B	B
user%%A%B	B
A!user	A	"Bang-style" addressing; commonly used for UUCP
A!user@B	B
A!user%B@C	C
A!user%B	B	nobangoverpercent keyword active; the default
A!user%B	A	bangoverpercent keyword active

RFC 822 does not address the interpretation of exclamation points (!) and percent signs (%) in addresses. Percent signs are customarily interpreted in the same manner as at signs (@) if no at sign is present, so this convention is adopted by IMTA.

The special interpretation of repeated percent signs is used to allow percent signs as part of local usernames; thus 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 IMTA.

The order of these interpretations is not specified by either RFC 822 or RFC 976, so the bangoverpercent and nobangoverpercent keywords can be used to control the order in which they are applied by the channel doing the rewriting. The default is more "standard," although the alternate setting may be useful under some circumstances.

---

Note - The use of exclamation points (!) or percent signs (%) in addresses is not recommended. It is preferable to convert them into regular internet addresses using the patterns $! or $%.

---