Conference iosg::all-in-1_v30

    
    Sang,
    
    The FUN field is used to 'carry function calls around which might be
    executed after reading a Mail Message'. I think the best example is the
    'Invitation to a meeting'. Once you've read the mail message
    'something' modifies your calendar. This something is the function (at
    least I think it is) CALREMOTE.
    
    Check the MACRO MAILFUN in OAGBL.BLI which indicates which functions
    are valid ones.
    
    I don't think it's a good idea to use this field to ship 'your own
    information' around. The SUBJECT or TITLE field might be a better
    place.
    
    HTH,
    
    	Simon

    
    Thanks for the prompt reply, Simon.  From the code that you've directed
    me to, the possibility of getting around it without code level
    modification seems pretty slim, right ?
    
    Sang.

    And it's meant to "break" autoforward.
    
    As .1 said, it was primarily meant to be used for calendar functions -
    these are assumed not to work if (auto-)forwarded (since the user's
    calendar wouldn't be at the address the message was auto-forwarded to),
    so they aren't auto-forwarded.
    
    There's nothing to stop you adding functions to the MAILFUN table in
    OAGBL.BLI, _except_ that it's in Bliss and so you need a compiler.
    
    Also, think carefully about security implications of anything you add.
    If you look at the shipped MAILFUN table, you'll notice an entry for DO
    which is commented out. This is because if DO was allowed, a user could
    send a message to another user containing a FUN like the following:
    
    FUN DO mynode::mydisk:[me]naughty.scp
    
    where naughty.scp could do anything - in the context of the receiving
    user! (You could send it to the MANAGER or other privileged user).
    
    As you say, you'd probably need to define a new function, which would
    mean Code Level modifications - it could be a pretty simple function,
    which for example just ran a local script. In v3 it's much easier to
    add new functions.
    
    Dave.

    
    Thanks for the information.  The problem here may require a bit of
    explanation.  We have a customer here in Hong Kong who had acquired a
    "turn key" solution base on ALL-IN-1 Desktop software (actually it was
    the field test kit that further development/modification was based).
    This is something before my time and thus I may missed some details. 
    The customer themselves had developed a very different PC front-end
    using their own NOS.  Mailbags are still passed back and forth.  One
    special requirement from the customer is to include an additional piece
    of info in the mail -- Your reference and My reference.  Somehow
    they've used the FUN field to include this info.  With only PC front
    ends and no user on ALL-IN-1 IOS, the problem I mentioned in the base
    note was never uncovered.
    
    However, now that this customer has acquired another  company who
    happens to be using ALL-IN-1 IOS, that's when the problem was
    uncovered.  
    
    I was thinking of a way to clear this FUN field before sending the mail
    to non PC users, however due to the share nature of mails in ALL-IN-1,
    I can't think of one that can be implemented at ALL-IN-1 level.
    
    Has anyone any idea ?
    
    Sang.  

    
    Could their application be modified to include the additional
    information in the 'extra' space in the subject field?  Only the
    first 61 or so characters are visible to the user.
    
    If so, this would be a _much_ safer place to transport the information.
    
    HTH,
    
    Jack

    
    Thanks for the suggestion, Jack.  How much 'extra space' is available
    in the subject field ?
    
    Sang.

    Broadly speaking, almost infinite (I think the theoretcial limit for
    any attribute is 1920 bytes).
    
    However, you'll run into other limits - max size of an ALL-IN-1 symbol
    etc.
    
    Also be aware that certain networks won't carry subject fields of
    unlimited length - in particular, X.400 is restricted to 128 bytes, I
    think. So if your messages might travel via X.400, be careful. If they
    stay within a Message Router network, you can exceed these limits.
    
    Dave.