Re: [ietf-smtp] How is EAI mail implemented ?

[John R Levine <[e-mail]>]

On Tue, 15 Jun 2021, Ned Freed wrote:
>> On my system I turn addresses into A-labels on the way in, and back into
>> U-labels on the way out (only if there is a UTF-8 local part) and handle
>> all the local routing and deliveries with A-labels.
>
> It sounds to me like this doesn't allow for UTF-8 domains in aliases. If so,
> that's not very friendly.

My system is qmail underneath and local domains are all mapped to 
sub-addresses before delivery.  If you put an address in a .qmail file, 
the envelope is normalized so U-labels work.

>> But a lot of MTAs don't even do that, they just allow any IDN in the 
>> domain, and if you want the U-label and A-label versions of an address 
>> to deliver to the same place, you have to configure them both.

> In our case configuring either one is sufficient. Of course this leaves 
> open the question of comparing local parts. We haven't really solved 
> this one yet.

I think we agree that even though the spec is unclear, routing U-label 
and A-label addresses differently is a bug.  I haven't seen anyone try to 
normalize local parts beyond perhaps NFC.

>> A lot of MTAs add the SMTPUTF8 MAIL FROM tag to all outgoing mail to 
>> servers that offer SMTPUTF8, because why not.

> Because it's possible that regardless of what you have observed, that 
> server may then refuse to relay an EAI-tageed but actually non-EAI 
> message to a non-EAI server?

Hey, don't shoot. I'm just the messenger.  I do minimal EAI, only tag it 
if it needs it.

>> I think they all notice if an EAI message is
>> sent to a non-EAI server, and a few in that case do odd things like
>> turning a UTF-8 local part into a MIME encoded word in the envelope.
>
> Yuck. Frankly, it would be better to just send UTF-8 in this case than 
> to come up with a private encoding for an address that likely belongs to 
> the server you're sending to.

This was their own MAIL FROM which they are presumably prepared to 
unscramble.  They didn't appear to rewite other people's addresses.

>> This approach is a lot easier to code than trying to tag all the queued
>> messages, and it can deliver more mail if, e.g., an incoming message has
>> an ASCII bounce address and UTF-8 recipients but is relayed to an ASCII
>> recipient, the relay doesn't need EAI.
>
> IME the tagging part was trivial. The canonicalization was considerably 
> harder.

Depends on the way your mail system is set up, in my case it was the other 
way around.

>> remarkably well.  It often seems even to find strings in unencoded UTF-8
>> headers which I wasn't expecting, perhaps again something that works by
>> mistake.
>
> I don't think it's a mistake, exactly. More like the optimum handling
> for invalid messages turns out to align with the proper handling
> for SMTPUTF8 messages.

Not so much mistake as code that happens to work because byte strings are 
byte strings.

> I don't have enough feedback from actual use to be able to say anything
> definitive, but my guess is the document EAI needs is something that the IETF
> would not be willing/able to write: One that says what parts of the standard
> should be followed, what parts should be outright violated, and when.

It'd be interesting to try an applicability statement.  We could shade the 
advice as "here's what we have observed to work."  It's no more of a 
stretch than a BCP that describes guesses that have never been 
implemented, and we have lots of those.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly