Handling Envelop Recipient Addresses

The parameters presented in this section are used by avgated only.

Two orthogonal processings are at hand here: source routing (which normally is prohibited now ), and interpreting bangs and percents (which normally should be refused, but can be allowed for interoperability with UUCP or strange gateways) [RFC0821, RFC0976, RFC1123].

These processings are directed by the following configuration parameters:

     AllowSourceRouting             YES | NO
     InEnvelopAddressesBangIs       IGNORED | REFUSED | INTERPRETED
     InEnvelopAddressesPercentIs    IGNORED | REFUSED | INTERPRETED
     AcceptLooseDomainName          YES | NO   
        

AllowSourceRouting

When AllowSourceRouting is NO, if source routing is present in the given path, it's removed. When AllowSourceRouting is YES, then source routing is honored, and the messages is forwarded to the first host specified in the route (if relaying is allowed for it, see Chapter 3 "Access Control Lists").

Syntax:

     AllowSourceRouting    YES | NO
          

Default value:

     AllowSourceRouting    NO.
          

InEnvelopAddressesBangIs

This configuration parameter directs the interpretation of the bang character, "!", in the envelop recipient addresses.

When InEnvelopAddressesBangIs is REFUSED, the presence of an unquoted "!" in the recipient envelop address implies that the message will be refused.

When InEnvelopAddressesBangIs is IGNORED, any unquoted "!" will be processed as any other non-special character of the address.

When InEnvelopAddressesBangIs is INTERPRETED, then the address is rewritten in RFC821 standard form. An address such as:

hostA!hostB!hostC!user

is rewritten as:

@hostA,@hostB:user@hostC

Then, if source routing is allowed, the message is transmited to hostA, otherwise it's directly sent to hostC.

Thus, this rewritting allow us to discover the recipient host, in the case where all the UUCP gateways on the route would have interpreted the address the same way as us. (If that were not the case, then this parameters should be set to IGNORED).

Syntax:

              InEnvelopAddressesBangIs    IGNORED | REFUSED | INTERPRETED
          

Default:

              InEnvelopAddressesBangIs    REFUSED
          

InEnvelopAddressesPercentIs

This configuration parameter directs the interpretation of the percent character, "%", in the envelop recipient addresses.

When InEnvelopAddressesPercentIs is REFUSED, the presence of an unquoted "%" in the recipient envelop address implies that the message will be refused.

When InEnvelopAddressesPercentIs is IGNORED, any unquoted "%" will be processed as any other non-special character of the address.

When InEnvelopAddressesPercentIs is INTERPRETED, then the address is rewritten in RFC821 standard form. An address such as:

user%hostC%hostB@hostA

is rewritten as:

@hostA,@hostB:user@hostC

Then, if source routing is allowed, the message is transmited to hostA, otherwise it's directly sent to hostC.

Thus, this rewritting allow us to discover the recipient host, in the case where all the gateways on the route would have interpreted the address the same way as us. (If that were not the case, then this parameters should be set to IGNORED).

Syntax:

            InEnvelopAddressesPercentIs    IGNORED | REFUSED | INTERPRETED
          

Default:

            InEnvelopAddressesPercentIs    REFUSED
          

AcceptLooseDomainName

The AcceptLooseDomainName parameter allow to process domain names even if they don't respect strictly domain name syntax, that is: a domain name can contain only [-.0-9A-Za-z], each name being at most 63 characters not beginning nor ending with a '-', the last name not being digit-only and in total less than 256 characters.

When AcceptLooseDomainName is NO, if the name of the domain selected for delivery (depending on source routing) does not strictly conform it the domain name syntax,then it's refused.

When AcceptLooseDomainName is YES, then no check is done on the domain name, apart of interpreting the domain name syntax for numerical IP addresses.

In any cases, then domain name can be either a true domain name (a sequence of names separated by dots), or else a numerical IP address with either one of these syntax:

& <decimal-number> [ <small-number> . <small-number> . <small-number> . <small-number> ]

Note that we won't accept mixing IP addresses with domain names as would be allowed by the syntax defined in RFC0821, since no semantics are defined for these forms.

Syntax:

     
     AcceptLooseDomainName    YES | NO
          

Default value:

     AcceptLooseDomainName    NO
          

Examples

The "!", "%" and "@" can be combined in an address.

With the configuration paremeters set as:

                InEnvelopAddressesBangIs       INTERPRETED
                InEnvelopAddressesPercentIs    INTERPRETED
          


     PATH:       <host-b!host-c!user@host-a>
     FIRST-HOST: host-a
     LAST-HOST:  host-c
     LOCAL-PART: user
     RECIPIENT:  <user@host-c>
     ROUTE:      <@host-a,@host-b:user@host-c>


     PATH:       <user%host-c%host-b@host-a>
     FIRST-HOST: host-a
     LAST-HOST:  host-c
     LOCAL-PART: user
     RECIPIENT:  <user@host-c>
     ROUTE:      <@host-a,@host-b:user@host-c>


     PATH:       <@host-a:host-b!user%host-c>
     FIRST-HOST: host-a
     LAST-HOST:  host-c
     LOCAL-PART: user
     RECIPIENT:  <user@host-c>
     ROUTE:      <@host-a,@host-b:user@host-c>