Conference iosg::all-in-1_v30

    Rick,
    
    I believe ALL-IN-1 is innocent here. It's unlikely that ALL-IN-1 has
    started doing this all by itself and you probably haven't upgraded
    ALL-IN-1 recently more likely you've just upgraded MRGATE from
    v3.1 to v3.2
      
    It is MRGATE v3.2 that is doing this to you.
    in fact it's even announced I believe in the new features.
    FORTY2::MAILBUS is the conference.
    
    I dodn't believe that VMSmail Import gives you this additional text
    but i'm prepared to be embarrased on this one.
    
    Regards,
    
    Andrew.D.Wicks
    
    Regards,
    
    Andrew.D.Wicks

    Is there any way that the "feature" can be turned off?  Also, another
    point - if the addressees are listed in a separate attachment does this
    mean that there are two SDAF entries and two text files in the mail
    shared areas per message that arrives via MRGATE?  If so, this seems to
    me to be a potential problem on large ALL-IN-1 systems.
    
    Just curious, Tony

    Andy's right, it is the new version of the MR VMSmail gateway that is
    doing this and not ALL-IN-1.
    
    We were already running V3.0 (an earlier baselevel of course) on our
    production system when we upgraded to MR V3.2 which instantly caused
    this to happen.
    
    I'm in two minds about this new feature. Firstly it's obviously useful
    to have the extra addressing information available, but it rapidly
    occurred to me that making it an attachment would have a couple of 
    disadvantages. First with printing as .0 complains, but also each of
    those attachments will be a <disc cluster size> block file in the
    shared areas a directory entry and SDAF records.
    
    But I couldn't see how else it could have been handled, since the CC
    addresss on VMSmail messages aren't always valid (Nicknames and local
    distribution lists aren't expanded for example) so MRGATE obviously
    couldn't put the CCs straight into the message header or you'd get
    non-deliveries when you answered it.
    
    with V3.0 you might be able to get round the printing problem by doing
    Index of Attachments (IA) and missing the last one off. But this
    requires user intervention of course. Perhaps someone could do a
    customisation to printing to drop these attachments?
    
    An another thing that occurred to me was that since this extra address
    information was available, it would be nice to have a customisation
    that tried to pick up the addresses and add them to a reply that was
    being generated:
    
    	NODE::NAME could be turned into NAME @ NODE @ MRGATE
    	NAME could be turned into NAME @ <Sender's Node> @ MRGATE
    	DLs could be turned into ???
    	etc....
    
    Anyone care to write one?
    
    Graham

    DLs couldn't be turned into anything without access to the original senders
    login.com... 
                
    The best you could do is send it to the sender, and ask them to forward
    it to the distribution list that teh name represents to them.
    
    Winton                                                         

    
    I believe there's a switching mechanism in MR to stop the
    append of that information at the bottom...I'll try to get info on
    this...
    
    
    
    Kevin.
    ~~~~~~

    By chance reading of a MRGATE'd mail sent to VMS interest, I noticed
    that you can specify a remote file spec in a distribution list. We
    could certainly do something with those!
    
    E.g.:
    
    ---------------------------------- ATTACHMENT ---------------------------
    VMSmail To information: @SQM::sys$info:vmsinterest
    VMSmail CC information: BRIDE
    Sender's personal name: 18-Mar-1992 1115
    
    
    
    Anyone going to write this for me?
    
    Graham

    It can be turned off... but only on a per-system basis. We have the
    same thing on ROCKS, and I've done a survey to see what opinion was.
    
    Many thought it usefull, but didn't want it printed.
    
    those FOR keeping it	4
    Those AGAINST keeping it	7
    
    Makes you wonder why the developers bothered ?. 
    
    Richard

    According to the MRGATE V3.2 Release Notes, there is a new
    configuration option, which is described in the Gateway Management
    Guide:
    
    	Whether you want to include VMSmail header information in messages
    	received in Message Router. The header information is the To: and CC:
    	information as the VMSmail sender typed it in, together with the
    	sender's personal name. The Gateway includes this information as an
    	attachment at the end of the message.
    
    	The default is that header information from VMSmail is included in the
    	message.
    
    Perhaps someone who has the book could post the details...
    
    Graham

    Hello Graham,
    
>    Perhaps someone who has the book could post the details...
    
    The book does not contain more info than your note...
    
    Regards,
    
    Jan

:>    Perhaps someone who has the book could post the details...
:    
:    The book does not contain more info than your note...
:    

The book you need is the Management Guide. This explains that there are many 
configuration parameters which control what the Gateway does. If you 
reconfigure the Gateway (see Chapter 4) it gives you the chance to change the 
value of these parameters. I THINK (I haven't tried it) you:

$ @sys$manager:mb$config

MBC> sho mrg		! This shows you the current values

MBC> set mrg		! This should allow you to change them

MBC>exit

Personally, I think the MRG developers had a difficult problem to solve here, 
and they've done the best they could. Ideally they needed another FC attribute 
in which to store the info . . . but then you'd need a new A1 and a new MRG to 
get it to work.

grahame

    Re .-1
    
    <<< Personally, I think the MRG developers had a difficult problem to solve
    <<< here, and they've done the best they could. Ideally they needed another
    <<< FC attribute in which to store the info
    
    I agree, and I hope you didn't think I was saying otherwise.
    
    I think that we in ALL-IN-1 ought to have co-oridinated better with
    this change, by offering some options to suppress the printing, or stop
    it being an attachment, or stopping the attachment causing a new page,
    or somehow sucking the address info into the header, or .......
    
    Graham