Please find attached a short note from Evan with a link to the latest versions of the testing proposal (including estimate for a pilot effort) and a link to the test cases and expected results. Please review if this is an area of interest. We’ll hold comments open through the 24th of August. Don Hi Don, Version 0.8 has been uploaded. Changes since the last publicized version, besides the usual typo and grammar fixes: * Update introductory text (1.1 and 1.2) * Notification of service provider (2.1) * Add required and advisory test classifications (2.3.1) * Add EAI phases and explanatory text (2.3.2) * Note exclusion of negative tests (2.4.4) * Add proposal and estimate for proof of concept evaluation (5) The EAI phases have been applied based on my understanding of recent discussions on the ua-eai list. If this changes, I'll update the test cases when I return. Regarding the length of this piece of string, the whole pilot as proposed is 120 hours, but that includes more than one component and the breakdown for any particular type of software is detailed in section 5, so those numbers can be used to extrapolate for any combination of software. Best, Evan https://seafile.catalyst.net.nz/d/4a7722d9db12406982bc/files/?p=/Email Address Internationalization - Discovery and Analysis - Report.pdf&dl=1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__seafile.catalyst.net.nz...> https://seafile.catalyst.net.nz/d/4a7722d9db12406982bc/files/?p=/Email Address Internationalization - Discovery and Analysis - Test Cases.xlsx&dl=1 [seafile.catalyst.net.nz]<https://urldefense.proofpoint.com/v2/url?u=https-3A__seafile.catalyst.net.nz...>
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@U, U@A, and A@U where A is ASCII and U is Unicode. I would ideally check all three, but at least U@U and U@A since I can easily imagine programmers misreading the spec and not handling U@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.
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@icann.org> On Behalf Of John Levine Sent: Thursday, August 9, 2018 13:55 To: ua-eai@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@U, U@A, and A@U where A is ASCII and U is Unicode. I would ideally check all three, but at least U@U and U@A since I can easily imagine programmers misreading the spec and not handling U@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@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
On 2018-08-09 22:02, Mark Svancarek (CELA) via UA-EAI wrote:
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.)
Yes, thanks. The tests currently use "ASCII" and "non-EAI" in reference to domains where "LHD" would have been more precise, but your point helps my own understanding. -- Evan Hanson Analyst and Programmer Catalyst IT - Open Source Technologists DDI: +64 4 803 2415 // Tel: +64 4 449 2267 // www.catalyst.net.nz
Hi John, Thanks for the feedback, much appreciated. I've made most of those changes now. A few responses below. Evan On 2018-08-09 16:55, John Levine wrote:
EAI-MUA-002, -006 what does validating addresses mean? Check syntax? Check domain?
Syntactic checks, yes. I've made this explicit now. If the software also validates the domain by hitting the DNS that's fine, but I didn't want to require that test executors set up working DNS for every single input.
EAI-MUA-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.
I took this requirement from RFC 6856 ("Clients MUST NOT issue the "STLS" command after issuing UTF8"), but I think you're right that this is overly specific and not really helpful for this project. I've dropped this and EAI-MDA-032, which is the server-side bit.
-035 message-id should always be ASCII, even for EAI servers. This isn't a fail but it suggests something is wrong if not.
I've made the EAI case an advisory one, per RFC 6532 3.3. Easy to include while in the neighbourhood.
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.
Always the MSA. I've tried to clarify this by now using the terms "client" for the MUA, "software" for the MSA under test, and "destination server" for the MTA to which it is relaying a message.
EAI-MTA-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.
Too true, I've added a note that DKIM should not be used for these test cases if the software applies recoding. Thanks again for the review. -- Evan Hanson Analyst and Programmer Catalyst IT - Open Source Technologists DDI: +64 4 803 2415 // Tel: +64 4 449 2267 // www.catalyst.net.nz
Hi again.
EAI-MTA-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.
Too true, I've added a note that DKIM should not be used for these test cases if the software applies recoding.
These days, if your MSA can't send mail with DKIM signatures, you're not going to get mail delivered. Perhaps split the test so that either the MSA passes through incoming signatures, or it applies them after any transformations. Regards, John Levine, john.levine@standcore.com Standcore LLC
I've seen recent angst about DMARC on the IPv6 mailing list, but nothing against DKIM -----Original Message----- From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of John Levine Sent: Tuesday, August 28, 2018 22:17 To: Evan Hanson <evanh@catalyst.net.nz> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] EAI Evaluation - Phase 1 Hi again.
EAI-MTA-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.
Too true, I've added a note that DKIM should not be used for these test cases if the software applies recoding.
These days, if your MSA can't send mail with DKIM signatures, you're not going to get mail delivered. Perhaps split the test so that either the MSA passes through incoming signatures, or it applies them after any transformations. Regards, John Levine, john.levine@standcore.com Standcore LLC _______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
I've seen recent angst about DMARC on the IPv6 mailing list, but nothing against DKIM
Mailing lists only have problems with DMARC, not with DKIM. The problem we're looking at in -009 through -011 is a fairly exotic one, MSAs that rewrite headers after signing. The more typical path is that the message comes in, the MSA cleans it up (adds missing headers, rewrites obsolete syntax, etc.) and then signs it. Any MSA that works that way should have no problems.
-----Original Message----- From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of John Levine Sent: Tuesday, August 28, 2018 22:17 To: Evan Hanson <evanh@catalyst.net.nz> Cc: ua-eai@icann.org Subject: Re: [UA-EAI] EAI Evaluation - Phase 1
Hi again.
EAI-MTA-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.
Too true, I've added a note that DKIM should not be used for these test cases if the software applies recoding.
These days, if your MSA can't send mail with DKIM signatures, you're not going to get mail delivered. Perhaps split the test so that either the MSA passes through incoming signatures, or it applies them after any transformations.
Regards, John Levine, john.levine@standcore.com Standcore LLC
_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai
Regards, John Levine, john.levine@standcore.com Standcore LLC
On 2018-08-29 1:17, John Levine wrote:
These days, if your MSA can't send mail with DKIM signatures, you're not going to get mail delivered. Perhaps split the test so that either the MSA passes through incoming signatures, or it applies them after any transformations.
Done, thanks. -- Evan Hanson Analyst and Programmer Catalyst IT - Open Source Technologists DDI: +64 4 803 2415 // Tel: +64 4 449 2267 // www.catalyst.net.nz
participants (4)
-
Don Hollander -
Evan Hanson -
John Levine -
Mark Svancarek (CELA)