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