home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / vms / 13852 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.1 KB
  1. Path: sparky!uunet!pipex!unipalm!uknet!glasgow!unix.brighton.ac.uk!kej
  2. From: kej@unix.brighton.ac.uk (-* Terminal Rat *-)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Undocumented MAIL qualifier
  5. Message-ID: <1992Aug19.120646.9659@unix.brighton.ac.uk>
  6. Date: 19 Aug 92 12:06:46 GMT
  7. References: <1992Aug17.182226.29126@henson.cc.wwu.edu>
  8. Organization: Brighton Polytechnic, UK
  9. Lines: 40
  10.  
  11. n8846069@henson.cc.wwu.edu (Barry) writes:
  12. > There is an undocumented MAIL qualifier I have seen
  13. > people use to extract an image file from a message.
  14. > EXTRACT/FOREIGN is the usage they used.
  15. > 
  16. > How extactly does this work?  And how did they create
  17. > the special message to begin with?
  18. > 
  19. > -BarryB
  20.  
  21.  The /foreign qualifier is undocumented as you noted. As far
  22.  as I can tell if you MAIL or SEND a file from the DCL command
  23.  line or within MAIL itself specifying /FOREIGN then it will
  24.  treat the file as an image or binary file. If you know a little
  25.  about mail you will already know that "large" mail messages are
  26.  not actually stored within the recipients MAIL.MAI file but
  27.  are actually given a unique filename outside of the MAIL.MAI file
  28.  and then a pointer within MAIL is set to that filename.
  29.  
  30.  I assume that this prevents large overheads occuring while extending
  31.  the size of the MAIL file. Well anyway the /FOREIGN command just
  32.  appears to force this to occur because the file being sent is
  33.  assumed to be unreadable anyway. It sets a flag within the MAIL.MAI
  34.  file for that particular message which MAIL interprets and signals
  35.  with the special message you mention.
  36.  
  37.  The upstart of all this means that you can basically use MAIL to
  38.  send "any" type of file (Although I wouldn't recommend it) to a
  39.  user and when they EXTRACT it to a new file it will (hopefully)
  40.  be intact and usable ! I sometimes send test files to myself from
  41.  other usernames and find that it works fine.
  42.  
  43.  One question I'd like to know about it though is will it work over
  44.  a network ? As we only have access to JANET from our VMS system I
  45.  can test it for that but as for other nets ???????????
  46.  
  47.    Keith Jones
  48.  
  49.    [ kej@uk.ac.brighton.vms  ]
  50.    [ kej@uk.ac.brighton.unix ]
  51.