From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 24-APR-1989 22:25 To: MRGATE::"ARISIA::EVERHART" Subj: Re: new version of MAILUAF.COM? Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Mon, 24 APR 89 08:43:32 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Mon, 24 Apr 89 08:16:52 PDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA19494; Mon, 24 Apr 89 08:00:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 89 03:09:45 GMT From: munnari!vuwcomp!wnv!gpwd!gpwrmdh@uunet.uu.net (Martin D. Hunt) Organization: Government Printing Office, Wellington, New Zealand Subject: Re: new version of MAILUAF.COM? Message-Id: <472@gp.govt.nz> References: <24211@ames.arc.nasa.gov> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In article <24211@ames.arc.nasa.gov>, howells@krypton.arc.nasa.gov ("Mr. Neutron") writes: > Does anyone have a new version SYS$EXAMPLES:MAILUAF.COM which will work with > VMS 5.0 VMSMAIL_PROFILE.DATA? > No, I don't have a V5 version of MAILUAF.COM, because DEC no longer wants to tell us about the format of VMSMAIL_PROFILE.DATA, but with nothing better to do one day, I decoded VMSMAIL_PROFILE.DATA from a dump of it. It was actually quite easy once I got the hang of it. The following is my documentation of it, I hope it is of some use to someone. MAIL PROFILE UNDER VMS V5 ------------------------- M.D.Hunt 10-APR-1988 Under V4, VMS stored information on each user of mail in a file called SYS$SYSTEM:VMSMAIL.DAT. This contained such things as the user's mail directory name, and new mail count. It was in a known format (although not documentated, several command files in SYS$EXAMPLES gave clues about its format), and several privileged programs used here have used the informmation contained in this file. Under V5, the same information is contained in a file, now called SYS$SYSTEM:VMSMAIL_PROFILE.DATA. The format of this file has also changed, meaning that Bytes 0 to 30 contain the 31 byte key, which is the VMS username. After this, are all the flags and profile information. The format of this is that there will be a two byte flag type indicator, followed by a two byte length indicator. This will be followed by some bytes of information, which could be text or numeric data. Then there will be further flag types and lengths, etc., until the end of record is reached. Flags can appear in any order, although the new mail count has always come first in all the records I have looked at. The following is the definition of the flag codes: 0001 - New mail count follows. The length code will always indicate two bytes. 0002 - Bit-mask flag follows, indicating such things as copy-self status, follows. The interpretation of this bit-mask follows. It actually lists the hex codes for the two bytes of the flag. To work out what the value should be, add the hex codes together: 0010 - CC prompting is enabled. 0001 - Copy-self on send enabled. 0002 - Copy-self on reply enabled. 0004 - Automatic message purge disabled. The following flag indicators have ASCII data following them, so the length will not necessarily be zero: 0003 - Mail sub-directory name follows. 0004 - Forwarding address follows. 0005 - Personal name follows. 0008 - Default editor name follows. 0009 - Default queue name follows. 000D - Default form type (for printing) follows. Example: Record number 2 (00000002), 48 (0030) bytes 20 20 20 20 20 20 20 20 20 20 20 20 20 4E 4F 44 DON 000000 01 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 . 000010 53 43 44 52 57 50 47 00 07 00 04 00 00 00 02 00 .........GPWRDCS 000020 In the above, the first 31 bytes are the key, padded with spaces. In the above, this has an ASCII value of "DON". This is followed by 0001 (reading left to right), meaning "New mail count follows". 0002 means that the new mail count occupies 2 bytes, and the 0000 indicates no new mail messages. 0004 indicates "Forwarding address follows". 0007 is the length in bytes of the forwarding address. The last 7 bytes contain the ASCII text value of the forwarding address (GPWRDCS). Record number 3 (00000003), 77 (004D) bytes 20 20 20 20 20 20 20 20 20 53 43 44 52 57 50 47 GPWRDCS 000000 01 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 . 000010 44 00 13 00 05 00 13 00 02 00 02 00 01 00 02 00 ...............D 000020 56 6F 72 63 69 4D 20 65 68 74 20 6E 6F 20 6E 6F on on the MicroV 000030 5D 4C 49 41 4D 2E 5B 00 07 00 03 58 41 AX....[.MAIL]... 000040 Record number 4 (00000004), 124 (007C) bytes 20 20 20 20 20 20 20 20 20 48 44 4D 52 57 50 47 GPWRMDH 000000 01 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 . 000010 5B 00 07 00 03 00 17 00 02 00 02 00 00 00 02 00 ...............[ 000020 52 54 53 55 4C 43 00 0F 00 04 5D 4C 49 41 4D 2E .MAIL]....CLUSTR 000030 49 52 50 00 07 00 09 48 4E 49 54 52 41 4D 3A 3A ::MARTINH....PRI 000040 44 20 6E 69 74 72 61 4D 00 16 00 05 52 45 54 4E NTER....Martin D 000050 00 08 58 41 56 B5 20 6E 6F 20 74 6E 75 48 20 2E . Hunt on 5VAX.. 000060 5A 59 58 00 03 00 0D 55 50 54 00 03 ..TPU....XYZ.... 000070 This example can be interpreted in a similar fashion to that for the previous records, but contains every type of field which I know about. I will not spell this one out, but will leave it to you to go through the dump and verify it against the summary shown below. Key GPWRMDH. New mail count of zero. Bit mask indicates CC prompting, Copy-self on send and reply, No automatic message purge. Mail subdirectory name is [.MAIL]. Forwarding address of CLUSTR::MARTINH. Default printer queue of PRINTER. Personal name of "Martin D. Hunt on 5VAX". Default editor of TPU. Default form type of XYZ. -- -------------------------------------------------------------------------------- Martin D. Hunt Government Printing Office Wellington New Zealand USEnet address : MARTINH@GP.GOVT.NZ PSI address : PSI%0530147000028::MARTINH --------------------------------------------------------------------------------