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(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp