Sorry about the late reply. I started cleaning up the windows on my
desktop, and there were many old windows behind the emacs. (There actually
was another eamcs hidden behind emacs, which I suppose shows that
"eventually mallocs all computer storage" is no longer correct.)
Kevin J. McCarthy writes:
On Fri, Sep 04, 2015 at 10:44:50AM +0100, Arnt Gulbrandsen wrote:
Kevin J. McCarthy writes: ...
Okay, this is clearer. So although we "may" use a-labels for the domain
part, we "should" use u-labels to ensure things are smooth.
The difficulty (as you mentioned in another email) is that we don't know
what the server supports until we actually try to send.
Right. But I don't think that's a big problem. People who receive EAI mail
generally have the server software to send.
Right now, IDNA is a compile-time option for mutt, and if it's compiled
in, we always use it. The problem is the same mutt binary may be used
with multiple SMTP servers: many people (including myself) have multiple
profiles, and one server may require IDNA while the other supports UTF-8
domains.
I've spoken to many/most of the people who worked/work on EAI, and my
impression is that there are no servers that require IDNA. My highly
unscientific guess is that supporting unicode in domains but not in
localparts wasn't attractice enough to get significant deployment, and that
that was a major reason for writing the current batch of EAI RFCs.
So, yes, that may be the case, but it's unlikely enough that "patches
welcome" is an acceptable answer.
Have you observed this in practice, or is there another part of the code
doing this that you've seen? (Even though I'm a developer, there are
unfortunately still large parts of the code I'm unfamiliar with...)
I saw it in the RCTP TO command when I tried to send mail to something like
ø@ø.no. I had a breakpoint in the SMTP server. But it's more than a year
ago, so I'm not sure whether the SMTP client was the mutt I compiled or one
built by one of the distributions I used.
I don't understand the question.
But I can perhaps comment. You may have seen my EAI test messages. The
most-used SMTP and IMAP servers often handle those exactly as a 6531 and
6855 say to, even though they haven't been extended. (6530 and 6855 was
written with that in mind.) Because of that compatibility,
just using the ...
This answers my question. When sending the email in smtp.c, I noticed
the patch only checked for UTF-8 characters in each address if the
server supported SMTPUTF8. So if the server didn't support SMTPUTF8 we
could end up sending UTF-8 email addresses to it. The RFC said not to
do that, but if it "just works" in many cases then it's worth it to at
least try. The SMTP server can always return an error code if it didn't
like it, right?
Yes, and IMO that error is good. Mutt wouldn't report the error any better
and wouldn't have a way to avoid the failure if it did detect the problem.
Arnt
