Re: Subaddressing

Let's look at two conceptual variants of IMAA (called IMAA-ACE-OPAQUE 
and IMAA-ACE-SPLIT) and how they affect current SMTP servers that do 
sub-address processing before writing received messages to a data 
store.

We all agree that the LHS is opaque to the MTA according to the 
protocol. This means that, if the MTA wants to do any sub-address 
processing, it inherently makes the LHS non-opaque.

In sub-address processing, the MTA parses the LHS, usually looking 
for delimiters, but sometimes looking for non-delimiter flags at the 
beginning or end of the name.

Neither IMAA-ACE-OPAQUE and IMAA-ACE-SPLIT require any change to 
current MTAs unless the MTA parses the LHS.

IMAA-ACE-OPAQUE always requires that the MTA that parses the LHS 
first perform ToUnicode before it parses the LHS.

IMAA-ACE-SPLIT does not require the MTA to parse the LHS if the 
IMAA-ACE-SPLIT protocol uses exactly the same delimiters and flags as 
the MTA uses when parsing. If the delimiters or flags used by the MTA 
and IMAA-ACE-SPLIT are different, the MTA must perform ToUnicode 
before it parses the LHS.

Thus, the advantage of IMAA-ACE-SPLIT is only for a subset of the 
MTAs out there. Further, I am not convinced that we can make an 
IMAA-ACE-SPLIT that sanely handles more than one delimiter (although 
I suspect Adam will try and I may be proved wrong). Regardless, 
IMAA-ACE-SPLIT will be a more complex protocol than IMAA-ACE-OPAQUE. 
The question is whether the additional complexity of the protocol is 
worth the advantage of preventing the MTAs that do sub-address 
processing to not need to add the ToUnicode step to the beginning of 
the processing.

--Paul Hoffman, Director
--Internet Mail Consortium