[UA-EAI] EAI Evaluation - Phase 1

[Mark Svancarek (CELA)]

In RDAP calls recently we got back into the old "if ASCII is encoded as UTF8, but doesn't include an ACE prefix, is it a U-Label" discussion, so you might run into questions about that.  
(We eventually settled on "there are 3 things: LHD, A-Label and U-Label", which I hope is correct.)

-----Original Message-----
From: UA-EAI <ua-eai-bounces at icann.org> On Behalf Of John Levine
Sent: Thursday, August 9, 2018 13:55
To: ua-eai at icann.org
Subject: Re: [UA-EAI] EAI Evaluation - Phase 1

I took a look at the test cases, comments below.  Most of the suggested changes are pretty small.

R's,
John

Comments on test cases:

There are three kinds of EAI addresses, U at U, U at A, and A at U where A is ASCII and U is Unicode.

I would ideally check all three, but at least U at U and U at A since I can easily imagine programmers misreading the spec and not handling U at A correctly.
(The A should not be an A-label, just something like réné@orange.fr)

MUA tests:

EAI-MUA-002, -006 what does validating addresses mean?  Check syntax? Check domain?

-009 Unicode has been valid in unstructured fields since MIME was invented 20 years ago so I'd be surprised if this ever failed.

-016 remove reference to "punycode-equivalent row".  There's no such thing.

-020 to -023.  MUAs connect to submission servers, not SMTP servers.

-020 an A-label is just an ASCII address, nothing to test

-024 need to check that AUTH to submission server allows Unicode user names and passwords

-028, -029 MUST send EAI addresses as UTF-8 to EAI submission server unless the user specifically said to send the message as ASCII (if it's even possible to say that).  If it gratuitously downgrades, it fails

-035 message-id should always be ASCII, even for EAI servers.  This isn't a fail but it suggests something is wrong if not.

-042, -043 if it shows the headers, it should show the actual headers and not attemtpt to recode them

-049 "POP connection" should be to authenticate the IMAP connection

-078 It would be more useful to check that you can do STLS before UTF8.  It's not up to the MUA to enforce POP server semantics.

MSA tests:

In a lot of these it's not clear what you're testing, the MUA or the MSA to which it is submitting mail.

-003 remove reference to "reencoding".  There's no such thing.

-005 how can you test this?  Don't we assume the MSA is EAI capable?  Or is this really a MUA test?

-006, -007 A-label and U-label apply only to domain part of addresses, NOT local part

-012 see MUA-035

MTA tests

-003 remove reference to "reencoding".  There's no such thing.

-007 A/U-label applies only to the domain part

-008 I would fail an MSA/MUA that encoded text other than UTF-8

-009, -010, -011 If this means you expect MSAs to re-code addresses or headers on the fly, they should not unless you can verify that they didn't break DKIM signatures when doing so.

MDA tests

I would separate MDA from POP or IMAP tests.  On most systems the MDA is one program, the POP/IMAP server is another.

For POP and IMAP I would check that you can do STARTTLS or STLS and then the EAI tests.  Or that you're connecting using POPS or IMAPS (ports
995 and 993) which do it when they start up.  This is the opposite of test -032 which I would skip.

_______________________________________________
UA-EAI mailing list
UA-EAI at icann.org
https://mm.icann.org/mailman/listinfo/ua-eai