Re: [UA-EAI] EAI Evaluation Widget
Allow me to explain, while refraining myself who is right or wrong.
https://eai.xgenplus.com is designed and evolving for users to test their own EMAIL ID for the support of EAI.
C:- mail from:<xn--11b7am1g.xn--41b5a5av9azf@xn--c2bd1gb.xn—h2brj9c> - SMTPUTF8 is always added , may be its displayed in next line due to length, please check again.
The system tries many combinations of FROM to the email address (including punycode) you submit and tries various combinations and shows how much EAI it supports.. … Details:-
punycode@punycode(optional) supported
ACE@punycode supported
punycode@unicode(optional) supported
unicode@punycode supported
unicode@unicode supported
That’s roughly what it says for my address too (arnt@gulbrandsen.priv.no) even though none of the software involved in receiving, storing or displaying mail has any idea that punycode exists.
=============== You will notice SMTPUTF8 is added in every FROM.
Yes. I also noticed that there was none in Martin’s test. Why not?
Regarding SPAM , antispam you are using is not ACE aware or considers it bad.
The latter. And the reason it’s considered bad is the way it behaves. Johm already explained that, search for “listwashing”.
Please share your email address with me, i will share the details with you. Happy to receive suggestions.
My email address is arnt@gulbrandsen.priv.no. Arnt
Please share your email address with me, i will share the details with you. Happy to receive suggestions.
My email address is arnt@gulbrandsen.priv.no.
Following up to offer some suggestions. But first a digression about a protocol called SIP. SIP is a Voice over IP protocol, very flexible, and it’s been bothered by poor interoperability. One of the reasons for that is instructuve. You see, SIP has optional bits, and a general syntax for declaring support for options and for using them. In EAI terms, “SMTPUTF8” would be a binary option, which would be declared as “SMTPUTF8”, but because the non-binary options all were declared as “MAXSIZE=57382”, it wasn’t long before the first implementation started sending SMTPUTF8=TRUE. This worked, because the existing implementation discarded the =TRUE as garbage. But then came an implementation that started sending SMTPUTF8=FALSE to mean that it did NOT wish to use the SMTPUTF8 option, and even requiring that peers send the =TRUE/=FALSE. My suggestions are: 1. Check all your statements about support against the relevant RFCs. When your code states that something is optional, there should be a comment in the source code naming the precise location of the corresponding MAY/SHOULD in the RFC. 2. Make some attempt to interpret the errors and determine whether the errors are related to EAI or not. The error codes help, they won’t be quite precise but they’ll be far better than assuming that all errors are due to lack of EAI support. 3. Check that your test’s results match reality for at least some software other than your own. And a fourth suggestion, which has nothing to do with EAI: 4. Please, please, please don’t ask people to enter their password with strangers. Arnt
1. Check all your statements about support against the relevant RFCs. When your code states that something is optional, there should be a comment in the source code naming the precise location of the corresponding MAY/SHOULD in the RFC.
Allow me to second this excellent advice. We tried hard to make the EAI documents as clear and as unambiguous as possible, and all tests should be referenced against the relevant standards section. As a concrete example, RFCs 6531 (sec 3.3) and 6532 (secs 3.1 and 3.2) make it utterly clear that the local part of an address is UTF-8, preferably unnormalized. It is not punycode. Any mail system that treats a local part as punycode has not correctly implented EAI, and will not interoperate with standard compliant software. Can we please end this unproductive digression now? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly PS: In a previous project at Standcore we developed an extensive DNS conformance suite, and we carefuly referenced each test against the relevant section of the standard documents. This let us be confident that the tests were correct, and helped test users bring their software into conformance if a test failed.
participants (2)
-
Arnt Gulbrandsen -
John R. Levine