SMTP doesn't allow"number" domains

[Willem Grooters]

(VMS 8.3 (AXP), TCPIP 5.6)

I just ran into a behaviour of SMTP I cannot recall having seen before.

Over here, a number of years ago "personal domains" were introduced in the form of "..nl", so somethinmg like "myname.100.nl"

Addresses like this will NOT be accepted by MAIL, or better: SMTP:

MAIL> send
To: willem@grooters.100.nl
%TCPIP-E-SMTP_BADADDR, recipient address is illegal; unparsed string: parse error
%TCPIP-E-SMTP_ABORT, SMTP session aborted

Such an address is accepted on any other OS I'm working on. It might be that previous versions of TCPIP had no problem either.

[Hoff]

IIRC, the MAIL utility client has an embedded lib$table_parse state table that processes the To: and cc: specifications, and it looks like there's a bug lurking in there somewhere. (I borrowed the basic design of that state table for use within another application, so that other application is probably similarly broken, too. Bummer.)

Assuming no ECO is available for MAIL and pending resolution of a formal report against the MAIL software aimed at HP, you might try the old SMTP%user@domain transport syntax as a workaround. That path might avoid the lib$table_parse state table. Might. It's probably also worth trying out the IP host address here, just for grins, to see if that works. (I don't recall the details of the state table, it's been a couple of years.)

[Willem Grooters]

> Assuming no ECO is available for MAIL and pending resolution of a formal report against the MAIL software aimed at HP

No supporty contract = no way to officially notify HP, let alone getting a solution. (The second I can understand, the first, I don't. But that's another story)

> you might try the old SMTP%user@domain transport syntax as a workaround. That path might avoid the lib$table_parse state table. Might. It's probably also worth trying out the IP host address here, just for grins, to see if that works.

Could do that if, and only if you know the IP address. Which is not always the case (though you may find out).
Second - it's not just a problem with MAIL but also for EVERY software that connects to SMTP - either directly (like PHP packages I use) or indirectly (via VMS-MAIL, like my webclient does). That makes usage of the 'old' format impossible, I would have to hack into the PHP engine - and though the sources are available, the building files are not ;-(
Nevertheless, I will give it a try in VMS-MAIL directly and see what happens.
BTW: I just checked, and Quintara's webmail may have EXACTLY the same problem: I got Internal Server Error there.

[Steven Schweda]

> No supporty contract = no way to officially
> notify HP, let alone getting a solution.

What's "official"? From time to time, I've
gotten helpful responses using:

http://h71000.www7.hp.com/doc/fb_doc.html

Follow the "Send us your comments" link on
the VMS main page:

http://h71000.www7.hp.com/

(or others).

It's not official _support_, but it's also
not ignored.

[Willem Grooters]

Thanks for these hits, Steven. I'll note them

[Hoff]

The code that is likely tipping over here is the MAIL parsing code that selects the SMTP% transport. If you should explicitly specify the SMTP transport followed by the target email address, you may well avoid what is probably a failing path within the associated state table.

As for accepting and logging problem reports, there are cases both for and against this. Good ones, too. Software support -- even free support -- isn't free. HP expects to profit from its software support contracts, after all. Many operating systems are now low-cost or free or bundled, and it is the software support that is the costly (and hopefully also profitable) component of the transaction.

Oh, the various tales that could be told of what has arrived via that doc email address. But that is fodder for another time... :-)

[Willem Grooters]

> If you should explicitly specify the SMTP transport followed by the target email address, ...

Might be - but that would requiree the USER to know about that. Of course I could hack into the code but I would have to do so in all packages (not that much) or in the PHP-engine delivered by HP - and no building instructions are delivered with that.

I still think HP should take care of that - and this platform is, AFAIK, the only way I can address issues like this.
Just a confirmation that the problem is read and will be addressed in some future TCPIP patch. Why would I need to pay for that?

[Willem Grooters]

Just hoping it will be solved in an ECO on TCPIP....