Yet another (new-to-me) MIME utility problem.

All types of networks, network stacks, and protocols supported by OpenVMS.

Topic author
sms
Master
Posts: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Yet another (new-to-me) MIME utility problem.

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.

User avatar

volkerhalle
Master
Posts: 196
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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

Re: Yet another (new-to-me) MIME utility problem.

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: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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.

User avatar

arne_v
Master
Posts: 308
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Online
Contact:

Re: Yet another (new-to-me) MIME utility problem.

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).
Arne
arne@vajhoej.dk
VMS user since 1986


Topic author
sms
Master
Posts: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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

Re: Yet another (new-to-me) MIME utility problem.

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: 317
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Yet another (new-to-me) MIME utility problem.

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.

Post Reply