All types of networks, network stacks, and protocols supported by OpenVMS.
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Tue May 30, 2023 11:44 pm
Code: Select all
ITS $ tcpip show version
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4-2L3
ITS $ MIME anmac1789_1.mail
MIME> show version
MIME Version: V1.93
MIME> list
Message Headers:
Content-Type: multipart/related
Content-Transfer-Encoding: 7bit/8Bit ASCII
Attachment: 1
Content-Type: multipart/alternative
Content-Transfer-Encoding: 7bit/8Bit ASCII
Attachment: 2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit/8Bit ASCII
Attachment: 3
Content-Type: text/html
Content-Transfer-Encoding: Quoted-printable
Attachment: 4
Content-Type: image/png
Content-Disposition: inline;
filename="Screenshot from 2023-05-30 21-56-31.png"
Content-Transfer-Encoding: Base64
Attachment: 5
Content-Type: image/png
Content-Disposition: inline;
filename="Screenshot from 2023-05-30 22-02-59.png"
Content-Transfer-Encoding: Base64
MIME> extract /attachment = 4
%MIME-I-SAVEFILE, saving file . . .
SCREENSHOTFROM2023-05-3021-56-31.PNG
MIME> extract /attachment = 5
%MIME-I-SAVEFILE, saving file . . .
SCREENSHOTFROM2023-05-3022-02-59.PNG
MIME> [Ctrl/Z]
its $ dire /size
Directory ITS$DKA0:[SMS.IZ.anmac1789]
anmac1789_1.mail;1 525
MIME$204078FA_SCREENSHOTFROM2023-05-302.PNG;2
107
MIME$204078FA_SCREENSHOTFROM2023-05-302.PNG;1
265
SCREENSHOTFROM2023-05-3021-56-31.PNG;1
107
SCREENSHOTFROM2023-05-3022-02-59.PNG;1
107
Total of 5 files, 1111 blocks.
I've grown accustomed to renaming the extracted files to match the
original, mixed-case/extended names, and deleting the spurious
"MIME$<PID>_<whatever>" files, but in this case, the (misnamed?) noise
files conveyed some useful information. Compare the sizes of the two
different noise files with the sizes of the two not-different extract
files. (And attend to the names of the noise files.)
its $ diff SCREENSHOTFROM2023-05-3021-56-31.PNG -
SCREENSHOTFROM2023-05-3022-02-59.PNG
Number of difference sections found: 0
Number of difference records found: 0
DIFFERENCES /MERGED=1-
ITS$DKA0:[SMS.IZ.anmac1789]SCREENSHOTFROM2023-05-3021-56-31.PNG;1-
ITS$DKA0:[SMS.IZ.anmac1789]SCREENSHOTFROM2023-05-3022-02-59.PNG;1
So, mangling the original names causes the data to be lost, too, or
what?
The obsolete, MIME-unaware e-mail client program is lame enough, but
the result of stacking the still more lame MIME utility on top of it
ought to be embarrassing enough to have triggered some action before
now. I claim.
I haven't run this test on E9.2-1, but the MIME version is the same.
Last edited by
sms on Tue May 30, 2023 11:47 pm, edited 1 time in total.
-
volkerhalle
- Master
- Posts: 199
- Joined: Fri Aug 14, 2020 11:31 am
- Reputation: 0
-
Status:
Offline
Post
by volkerhalle » Sat Jun 03, 2023 4:01 am
Looks like this kind of problem also existed with MIME V1.9 (on OpenVMS Alpha):
Code: Select all
AXPVMS $ mime x.x
MIME> show vers
MIME Version: V1.9
MIME> list
Message Headers:
Attachment: 1
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-printable
Attachment: 2
Content-Type: image/png
Content-Disposition: attachment;
filename="Screenshot from 2023-06-02 08-17-00.png"; size=201407;
c
Content-Transfer-Encoding: Base64
Attachment: 3
Content-Type: image/png
Content-Disposition: attachment;
filename="Screenshot from 2023-06-02 08-18-00.png"; size=139287;
c
Content-Transfer-Encoding: Base64
MIME> extr/att=2
%MIME-I-SAVEFILE, saving file . . .
SCREENSHOTFROM2023-06-0208-17-00.PNG
MIME> extr/att=3
%MIME-I-SAVEFILE, saving file . . .
SCREENSHOTFROM2023-06-0208-18-00.PNG
MIME>
AXPVMS $ dir/siz .png
Directory USERDISK1:[HALLE]
SCREENSHOTFROM2023-06-0208-17-00.PNG;1
273
SCREENSHOTFROM2023-06-0208-18-00.PNG;1
273
Total of 2 files, 546 blocks.
AXPVMS $ dir/sin
Directory USERDISK1:[HALLE]
SCREENSHOTFROM2023-06-0208-17-00.PNG;1
SCREENSHOTFROM2023-06-0208-18-00.PNG;1 X.X;1
Total of 3 files.
AXPVMS $ diff SCREENSHOTFROM2023-06-0208-17-00.PNG SCREENSHOTFROM2023-06-0208-18-00.PNG
Number of difference sections found: 0
Number of difference records found: 0
DIFFERENCES /IGNORE=()/MERGED=1-
USERDISK1:[HALLE]SCREENSHOTFROM2023-06-0208-17-00.PNG;1-
USERDISK1:[HALLE]SCREENSHOTFROM2023-06-0208-18-00.PNG;1
Both attached PNG files clearly have a different size shown in the MIME file, but it looks like the 2nd attachment - instead of the 1st - is also extracted with MIME> EXTR/ATT=3
With this version of MIME, there is no MIME$<pid>filename.PNG file left around.
Volker.
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Sat Jun 03, 2023 8:58 am
Code: Select all
> MIME Version: V1.9
Thanks for looking.
> With this version of MIME, there is no MIME$<pid>filename.PNG file
> left around.
It's been a while since I tried using it on a Alpha, so I know
nothing. I have a dim recollection that a LIST command (alone) would
cause it, but you apparently did that, so what do I know?
Perhaps it's an enhancement in later versions.
-
sodjan
- Active Contributor
- Posts: 40
- Joined: Mon Apr 24, 2023 3:51 am
- Reputation: 0
-
Status:
Offline
Post
by sodjan » Sat Jun 03, 2023 10:06 am
Another interesting question is also what prio VSI should put on work on the MIME utility.
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Sat Jun 03, 2023 1:22 pm
Code: Select all
> Another interesting question is also what prio VSI should put on work
> on the MIME utility.
VSI could simply declare that e-mail has become too difficult a task
for its sophisticated OS to handle.
I've tried to use the TCPIP IMAP server in a very limited way with
Mail on a Mac, with, at best, limited success. Typical problems include
Mail on the Mac trying to allocate all the available memory on the Mac,
or displaying a blank Inbox, "Downloading Messages" forever. Perhaps
the Mac client is bad, but I'd put my money on the server as the source
of the bad behavior. Are any people at VSI actually trying to use this
stuff for their regular work? Why not? I'd call that "embarrassing".
Currently, these forums send out messages with subjects which MAIL
renders as, for example:
Subj: =?UTF-8?B?VG9waWMgcmVwbHkgbm90aWZpY2F0aW9uIC0gIkNvbXBsZWV0ZSBWbXMgIG5l?=
=?UTF-8?B?d2NvbW1lciI=?=
The MIME utility is approximately garbage, and has been since before
VSI. Assuming that it's written in C, if its sources were released,
even to dopes like me, I'd bet that at least some of the known bugs and
limitations could be resolved in a few days of part-time effort.
-
arne_v
- Master
- Posts: 368
- Joined: Fri Apr 17, 2020 7:31 pm
- Reputation: 0
- Location: Rhode Island, USA
-
Status:
Offline
-
Contact:
Post
by arne_v » Sat Jun 03, 2023 5:05 pm
I believe that producing a truly modern and good email capability on VMS would require new email client, new email server and new email storage.
That is what Innosoft (company behind PMDF) recommended 25 years ago. And the requirements have increased since then.
All indications say that VMS is considered a server only OS today, so it seems highly unlikely that such a total makeover will happen.
Obviously some problems could be solved within the existing context. But it would not make email on VMS uptodate. So whether VSI want to prioritize that is a good question. Maybe if someone in engineering has some interest in the topic.
From a practical user perspective, then I will recommend dropping VMS email and for any required email usage on VMS instead of DCL+MAIL+MIME use Java or Python talking to a non-VMS server (SMTP + POP/IMAP).
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Sat Jun 03, 2023 8:30 pm
Code: Select all
> I believe that producing a truly modern and good email capability on
> VMS would require new email client, new email server and new email
> storage.
More than I need. I could get by with the current old-and-crappy
stuff, but with fewer bugs and just a few more features.
Lest we forget:
https://forum.vmssoftware.com/viewtopic.php?f=9&t=8498
> [...] talking to a non-VMS server [...]
What I'd like to avoid.
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Sun Jun 04, 2023 10:31 am
Code: Select all
> All indications say that VMS is considered a server only OS today,
> [...]
A server-only OS which can't (securely) send an e-mail message to a
remote system manager? I'm not sure that I'd enjoy trying to sell that
OS to anyone who's paying attention.
-
sodjan
- Active Contributor
- Posts: 40
- Joined: Mon Apr 24, 2023 3:51 am
- Reputation: 0
-
Status:
Offline
Post
by sodjan » Sun Jun 04, 2023 3:27 pm
Sending e-mail *from* VMS should work and is needed. But I thought the issue here was to *read* mail (with attachments) on VMS, and I see very little need for that (on a server OS).
-
Topic author
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Sun Jun 04, 2023 4:14 pm
Code: Select all
> Sending e-mail *from* VMS should work and is needed. [...]
I agree. Sadly, ...
> Lest we forget:
>
> https://forum.vmssoftware.com/viewtopic.php?f=9&t=8498
> [...] But I thought the issue here was to *read* mail (with
> attachments) on VMS, and I see very little need for that (on a server
> OS).
And yet, programs such as MAIL and MIME _are_ provided; they're just
incompetent.