From: brydon@asl.slb.com (Harvey Brydon (918)250-4312)
Newsgroups: comp.os.vms
Subject: Re: Undocumented MAIL qualifier
Date: 21 Aug 92 12:25:15 GMT
Reply-To: brydon@asl.slb.com
Organization: Schlumberger/Anadrill Sugar Land, TX

In article <1992Aug19.120646.9659@unix.brighton.ac.uk>,
kej@unix.brighton.ac.uk (-* Terminal Rat *-) writes:
>> There is an undocumented MAIL qualifier I have seen
>> people use to extract an image file from a message.
>> EXTRACT/FOREIGN is the usage they used.
>> 
>> How extactly does this work?  And how did they create
>> the special message to begin with?
>> 
>> -BarryB
>
> The /foreign qualifier is undocumented as you noted. As far
> as I can tell if you MAIL or SEND a file from the DCL command
> line or within MAIL itself specifying /FOREIGN then it will
> treat the file as an image or binary file. If you know a little
> about mail you will already know that "large" mail messages are
> not actually stored within the recipients MAIL.MAI file but
> are actually given a unique filename outside of the MAIL.MAI file
> and then a pointer within MAIL is set to that filename.

Actually it is partly documented in the PSI manual.  The DECwindows mail
interface shows an option for transport and shows its value but does not
document it.  The character cell interface command "MAIL> show all" will
display a non-null setting for transport but it is not mentioned if blank. 
There is an undocumented "MAIL> show transport" command.

> I assume that this prevents large overheads occuring while extending
> the size of the MAIL file. Well anyway the /FOREIGN command just
> appears to force this to occur because the file being sent is
> assumed to be unreadable anyway. It sets a flag within the MAIL.MAI
> file for that particular message which MAIL interprets and signals
> with the special message you mention.

Essentially correct.  Mail does not let you 'read' a foreign message with the
"MAIL> read" command.  The only things you can really do with it from mail are
extract it and delete it.  The 'message' is always stored as an external
MAIL$nnnn.MAI file.  It can have any of the newer file characteristics seen in
DDIF and related files.

> The upstart of all this means that you can basically use MAIL to
> send "any" type of file (Although I wouldn't recommend it) to a
> user and when they EXTRACT it to a new file it will (hopefully)
> be intact and usable ! I sometimes send test files to myself from
> other usernames and find that it works fine.

Not sure why you wouldn't recommend it.  This is the main purpose for the
feature and it works fine.  The only pet peeve I have about it is that all
binary information is sent about a file except for its name.  If you want to
send a number of files with the correct name association, it is up to the
receiver to extract them to the correct names, which is typically done
manually.  The subject field is the only place to put this information.  Of
course you can send multiple files in a  backup saveset, which can have any
name, and pull the files out of the saveset.  But a single message which is a
backup saveset can be quite large and difficult to send over poor network
connections.

> One question I'd like to know about it though is will it work over
> a network ? As we only have access to JANET from our VMS system I
> can test it for that but as for other nets ???????????

It will work end-to-end over any network connections that pass the full suite
of mail-11 datagrams correctly.
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
The sooner you fall behind, the more time you have to catch up!