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

John R Levine <johnl@taugh.com> Tue, 15 June 2021 18:59 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2233A3A0C for <ietf-smtp@ietfa.amsl.com>; Tue, 15 Jun 2021 11:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=x6zKoN81; dkim=pass (2048-bit key) header.d=taugh.com header.b=MWRb3gv/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G35Cet4GYVqb for <ietf-smtp@ietfa.amsl.com>; Tue, 15 Jun 2021 11:59:19 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8483A3A18 for <ietf-smtp@ietf.org>; Tue, 15 Jun 2021 11:59:19 -0700 (PDT)
Received: (qmail 38793 invoked from network); 15 Jun 2021 18:59:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=9787.60c8f885.k2106; bh=riA2/OEbP8uo352KfhAsGRfsmeeW+LFl1EI2CpT1vqA=; b=x6zKoN81ibarkbXZuinPNhczTJKTYYIDkPwlUpx/avZH2gNzy9uxEdzF3cF4qorlhzwpR5DOHN3nCW21xH7dliq9gY4aD7ZRVUZ5umFbw8xXepLLe9viE7gCEzcRsYoFdDqPItRZiIpOsTJzznid7uWn1WM9kNBX0501UUduGu2iuf/JubnoKMvOQAKHKw8agd7Pa+hfoqX+ifoci7mgzvKbUtI152vGvBvgl2aUf3ghJTuM/Fa+KOhKfWBSGGcAhh9EsKeqxMJar5qrky+cpS6gxADgOup90E8ZLIOZkt63kas70mN0ColpuCrGlEH0A+l2V4aOiQpV9U/pK5xhng==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=9787.60c8f885.k2106; bh=riA2/OEbP8uo352KfhAsGRfsmeeW+LFl1EI2CpT1vqA=; b=MWRb3gv/7i/nZNnFA9OGFcwS0IbdYa/Sm4w6RpitwOk6G9yiuxs0tABCAEV90xunsNhNAHadSaOAE4oGGPuxxVeSSZquxCz+a6RJFV5h3S1Rc8vWHkoMkeHQl/YR2QVsA+IRGFl4ACh5LlO9N8I0lgOa5GNyJrE2lxY0uaQdHM2z4LVh+kYTRO0KqfA5kDTZ6RBTpW3VDcKQClMNRW4VoKeV6JO0w9qD6LLJqdLFarcXZRw8GVXkge9eKxLVlaMVh2bV8HkumSdoX3IEI/lbktXQVJWAfp6F0+mC71Rh+JK2rXL3InJ600EGVIm0c+qw+F7QNDugHAcqVdzRKdaS0g==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Jun 2021 18:59:17 -0000
Received: by ary.qy (Postfix, from userid 501) id C39BA114658B; Tue, 15 Jun 2021 14:59:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 6FF70114656B; Tue, 15 Jun 2021 14:59:16 -0400 (EDT)
Date: 15 Jun 2021 14:59:16 -0400
Message-ID: <fc6a3775-4ed7-2fbc-1d4a-6669c7c38a36@taugh.com>
From: "John R Levine" <johnl@taugh.com>
To: "Ned Freed" <ned.freed@mrochek.com>
Cc: "ietf-smtp" <ietf-smtp@ietf.org>
X-X-Sender: johnl@ary.qy
In-Reply-To: <01S09JUCB7XE0085YQ@mauve.mrochek.com>
References: <5bb26c2f-a94d-ccaf-8fc1-51684f25f48@taugh.com> <01S09JUCB7XE0085YQ@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/eHBHl6yfBVw9r0DbQhpO3bpOd2Q>
Subject: Re: [ietf-smtp] How is EAI mail implemented ?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2021 18:59:35 -0000

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, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly