Conference iosg::all-in-1_v30

    
    By the way,
    
    I realize that this is a current "feature".  In the note 1811, by 
    doing a MH, is not acceptable.
    
    Is it going to be "fixed" in the next release or should I sell 
    consulting services to work around this?  Are there any ideas on how?
    
    
    Being a novice in ALL-IN-1 programming, here's my idea -
    
    Since ALL-IN-1 checks OA$USER for locally sent messages, could 
    
    1. ALL-IN-1 be set up to check DDS REVERSE LOOKUP and the OA$USER
    2. Search the cc: list for the sender's DDS name and/or username
    3. When found, delete it from the cc: list 
    
    This procedure may need to be implemented for all messages being sent
    (i.e., after the users press "SEND".)
    
    
    Desparate for help,
    
    Jane

You correctly spot that ALL-IN-1 won't put the sender on the CC list if the
sender appears as a local addressee, but that the sender may appear there if
they are a remote addressee.  The reason that ALL-IN-1 doesn't remove the user
in this case is:

It can't be done reliably.  The user's address could be in several different
forms; for example, I could appear as a remote addressee in the forms:
    MARSHALL @ A1
    MARSHALL @ A1 @ IOSG
    Scott Marshall @ REO
    MARSHALL @ A1 @ MRGATE @ IOSG @ MRGATE @ SUBURB @ REO
    ...etc...

There is no way that ALL-IN-1 could check for all the possibilities.  More
importantly, if ALL-IN-1 does get a match, there is no way that it can be 100%
certain it has found the right user, as ALL-IN-1 has no knowledge of what all
the different message router routing terms mean.

Your suggestion that ALL-IN-1 could do a DDS reverse lookup might catch some
of the cases, but what about people without DDS?  Also, it would only work if
the address string exactly matched that in DDS, which I think the majority
of cases it won't.

ALL-IN-1 could also use OA$MTI_AREA, etc, but again exact matches are unlikely.

So the bottom line is: it's a *lot* of extra work (ie longer response time for
the user) for ALL-IN-1 to do this, and it would fail most of the time, so it's
not worth it.

Sorry to be so negative, but that's the way it is...

Scott

    
    IF
    
    ALL users are entered in DDS (this includes the customers entire
    ALL-IN-1, Soft*Switch and X.400 mail community of users)
    
    THEN
    
    I could check DDS and catch "all" users.
    
    
    What kind of performance hit could result from this check?
    
    I just need to know what my options are and their "cost".
    
    Thanks,
    
    Jane

Jane,

Summary of my phone call with your colleague:

IF all users are in DDS
AND the entire mail network uses the same DDS database
AND a person's DDS entry cannot change in between someone sending them mail
    and them answering it
AND people always use DDS to add mail addressees to a message

THEN it might just work.  Basically, you need a small, tightly controlled
network for it to be feasible.  Even then it might not always remove the
unnecessary entry, and even worse may still end up removing an addressee it
shouldn't.

The performance hit would be:

    time taken for one DDS lookup (that of the person sending the reply)
PLUS
    time taken to compare one addressee against the value fetched from DDS
    MULTIPLIED BY the number of addressees.

IE: you take the hit of the DDS lookup once, but the time taken to do the
comparisons is proportional to the length of the distribution list.  As you have
to search the distribution list in a script (rather than in code, which is where
I think ALL-IN-1 does the search for the local username) then this could take
quite a long time!  You'd need to put a suitable script together and time it
to get some exact figures.


FWIW it happens to me all the time; you just learn to accept is as one of the
necessary side-effects of having such a flexible mail addressing system.

HTH,
Scott

    well Scott's done an excellent job (sorry i opened A1INFO first)
    but I wonder if this couldn't be a revenue opportunity?????? 
    
    given certain other details about this customer that weren't mentioned
    in this note (but maybe Scott herad about them on the phone) i'd urge
    caution before telling this particuarly customer anything
    
    JANE - I'm back in Atlanta - call me - stop cluttering up all these
    notes files (:==:)
    
    Regards,
    
    Andrew.D.Wicks 

    
    Just on a more philosophical line of questioning... outside the context
    of this particular customer:
    
    I gather that part of the architectural problem here is that Fetcher
    uses Envelope data from Message Router to help deliver the message and
    that data disappears as soon as the message is delivered?? 
    
    If this is not the case, couldn't the same logic as in the MTI delivery
    code be used to determine if the sender is on the distribution list?
    
    It seems that this problem is a more general instance of the problem
    subsystems like TM have when trying to handle MAIL. Send a Meeting
    notice off node to a user and then try to figure out who the response
    is from when they reply! Not easy to say the least - and at present -
    not generally possible.
    
    As has been suggested, you can use the DDS information provided that
    there is enough of it, but I have one question in all of this:
    
    	How do you generate the DDS address string (i.e. reverse lookup)??
    
    I could probably write some fairly disgusting script or named data but
    looking this up to find the DDS entry corresponding to a MAIL address
    is going to be mighty slow when you have to sequentially search DDS!!!
    
    If you don't use the address as the basis of lookup, then how can you
    deal with COMMNAME ambiguities? You might not even get the COMMNAME
    information to look for in some cases?
    [I haven't even begun thinking about any problem with convolutions like
     Area Routing although this customer might not be using it admittedly.]
    
    It would be a lot easier if you could strip these addressees out at
    delivery time. Problem there is that you don't know if they are on the
    list deliberately! Could this be a site wide option? And if the reply
    MAIL has gone right through the network, then it is very hard to match
    up the FROM_ADDRESS against the TO/CC entries [back to problem #1].
    
    One interesting observation... the OUTBOX message and INBOX copy should
    have the same Message Router ID. The problem is that Sender/Fetcher
    never sees what is already in the user's DOCDB. By the time this
    information is available to check - it's too late - the message has
    been delivered. Again - nice idea - shame about the architecture!
    
    I wish you all luck... It might be a plane that you build - but frankly
    I don't expect it to fly! Maybe I'm wrong, but I've lost some sleep
    before now over this exact problem.
    
    Paul.