[Emailcore] Re: Posting draft-ietf-emailcore-as-30

[Viktor Dukhovni <[e-mail]>]

On Mon, Sep 07, 2026 at 05:17:44PM +0200, Steffen Nurpmeso wrote:

>   *  Internationalized Email [SMTPUTF8]
>   ...
>   Internationalized email is similarly ubiquitous, to the extent that
>   its non-use degrades the basic user experience in modern Internet
>   messaging, hence support for it in MTAs is encouraged.
> 
> I do not know how anyone can come to this conclusion, really.

Well ubiquitous does not mean either universal or even most common, and,
while perhaps other adjectives might be closer, this editorial nit does
not really seem to be your real issue (which remains unclear in the
below).

> If it was "detected" by doing these unbelievable large-scale scans
> that anyone believes has a right to perform, then hopefully also
> reaching out behind STARTTLS (surely), then no.

No specific measurements are reported or implied.  The "ubiquity" of EAI
is perhaps more of a consensus impression shared by the working group,
but the substance of the quoted text is a recommendation to support EAI
( at least to the extent of not getting in the way).  Whether it is or
is not "ubiquitous" is secondary.

> I only comment on that no further context on message/global etc.

The message/global (non-transparent MIME encoding) design error should
be corrected, but that's out of scope for this I-D.

> The point is that, aside those giants which the western world
> currently still uses the way it does, which possibly support
> SMTPUTF8.  The point is that massively used "everybodies'"
> software started enabling this by default, for example postfix:
> 
>   smtputf8_enable (default: yes)
>    Enable preliminary SMTPUTF8 support for the protocols described
>    in  RFC 6531,  RFC  6532,  and  RFC 6533. This requires that
>    Postfix is built to support these protocols.
> 
> This means that whenever you upgrade an existing installation of
> this software, you get this thing enabled, so that these monstrous
> scans will turn the "does it use SMTPUTF8" green.

No scans were employed in the of developing this draft.  If you object
to academic or other active deployment surveys, this is not the right
forum for those objections.

> But this does *NOT* mean that the MUAs, or any other software
> behind that MTA which does use these in parts broken protocol
> extensions, actually can deal with such messages, shall they enter
> the system.

Yes, EAI support is spotty, and a number of ubiquitous software stacks
don't handle at all EAI gracefully.  This is why a plea for broader
support is needed.  By way of anecdotal evidence in support of both the
I-D and your observations:

  - My own Postfix server and "mutt" MUA support EAI well enough to
    allow correct delivery of <[e-mail]>
    in both directions between my server and Gmail.

        F311693559C: from=<EAI-was-here>, size=764, nrcpt=1 (queue active)
        F311693559C: to=<[e-mail]>, relay=gmail-smtp-in.l.google.com[172.217.221.26]:25, delay=3.9, delays=0.02/0.01/2.6/1.2, tls=encrypt, dsn=2.0.0, status=sent (250 2.0.0 OK  1789445239 d2e1a72fcca58-86b262bb91esi24702246b3a.7 - gsmtp)

        433A793559C: from=<[e-mail]>, size=6048, nrcpt=1 (queue active)
        433A793559C: to=<internal-address>, orig_to=<EAI-was-here>, relay=virtual, delay=1.1, delays=1.1/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)

  - My up-to-date MacOS laptop's Mail.app on the other hand butchered
    the the EAI address beyond recognition:

        NOQUEUE: reject: RCPT from [...]: 550 5.1.1 <=?utf-8?B?base64?=@a-label.org>: Recipient address rejected: User unknown in virtual alias table; from=<[e-mail]> to=<=?utf-8?B?base64?=@a-label.org> proto=ESMTP helo=<smtpclient.apple> sasl_method=GSSAPI sasl_username=viktor

    How the maintainers of Mail.app decided that the local part of an
    SMTP envelope address is subject to RFC2047 display name encoding is
    a mystery to me.  Also replacing the recipient domain's U-label with
    the corresponding A-label is not expected behaviour.

> [ Gripes about EAI friction ]

Well, this is why it is important to advocate for the problem
software to be fixed.

> So .. "no" regarding the above statement.  And understandably so.
> I mean, you do not even need to respond, just let it in.
> But it is utter nonsense.

Even if you feel that "ubiquitous" is the wrong adjective, it is
then even more apparent that advocacy to improve support is apt.

> Having said that, i hate the way the RFC 822 References: field has
> been insensitively and unnecessarily and blinders-wearing
> mutilated in RFC 2822. [...]

I don't think this gripe is relevant to the AS draft.  If you
have improvements in mind perhaps the "mainmaint" list is a
more appropriate forum, if there's room in the charter for such
concerns.

-- 
    Viktor.  🇺🇦 Слава Україні!