Conference iosg::all-in-1_v30

    Yukiji,
    
    I think you're getting confused amongst a number of things and then
    trying to glue them altogether and then make sense of them - you can't
    unfortunately apply such logic to the mail subsystem.
    
    So let's try and seprate them.
    1) Answer to ALL will ALWAYS send you a copy if it can't find you on
       the distribution-list EXACTLY. This doesn't real tie into any
       behavious of DDS because you can see the same under many many
       different conditions such as use of MTS addressing, entries in
       NETWORK.DAT etc...
    2) the return of a remote address from DDS when it should be local is
       I thought an Introduced Bug in v2.3 (i'm sure it worked fine in v2.3)
       and happened whether you were a world-search node or not.
    3) the behaviour with different addresses being returned depends on
       whether or not you doing a directed serach (SMD or SOM) or a
       non-directed search (just off the mail header)
    
    So you really are going to get confused if you try and think about all
    3 at a time - which one is the real problem? If it's just Answer then
    it looks as if you've already figured it out.
    
    Regards,
    
    Andrew.D.Wicks 
    

	Thanks, Andrew. I know it's a mixed-up problem, but unless
      the returned address is remote, he won't have his own answer message.
 
>        3. ALL-IN-1 V2.4, OA$DDS_PRIME = 2, World Search Node returns
>		TO: Yukiji Nagura               ( NAGURA@A1@LocalNode )

	Further investigation has revealed this wasn't true. My subscriber
      entry has a different reverse lookup routing address from the value 
      of OA$GT_AREA_ROUTE. So it doesn't matter whether the node is
      world search or not.

	So all I want to know is just one thing. The result is different 
      only on the first lines of TOs and CCs. It has a routing information.
      Is this fixed in V3.0 ?
           					Yukiji

    Yukiji,
    
    I don't know whether it's fixed in v3.0 - maybe someone with the
    necessary setup can test that one for you.
    
    Regards,
    
    Andrew.D.Wicks

    
    Andrew, Yukiji,
    
    I don't think its fixed. Its not a bug, its a design issue.....
    See note 2644 in the 2.4 conference.
    When ALL-IN-1 gets real X400, problem might be gone.
    
    A customer of mine uses the following script to avoid the problem.
    Its not fool-/full-proof but it catches all "user at a1 at node"
    addressing.
    
    Good luck,
    
    Jan
    
    !+
! file		: remove_user_from_cc_list.scp
! created 	: 6 feb 1992
! author  	: Jan Schollaert
!-
!+
! Get remote address of local user
!-
     GET #USER = OA$USER "@" LOG$OA$MTI_MAILBX "@" LOG$OA$MTI_MR_NODE
!+
! Remove user from CC list
!-
     FOR CAB$ATTRIBUTES:"CC" WITH .VALUE <=> #USER DO -
     CAB DELETE_ATTRIBUTE OA$CURMES, "CC", .VALUE

    .EXIT
!-------------------------------------------------------------------------------
!+
! COPYRIGHT (c) 1988,1989,1990 BY
! DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS.
! ALL RIGHTS RESERVED.
! 
! THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
! ONLY  IN  ACCORDANCE  OF  THE  TERMS  OF  SUCH  LICENSE  AND WITH THE
! INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR  ANY  OTHER
! COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
! OTHER PERSON.  NO TITLE TO AND  OWNERSHIP OF THE  SOFTWARE IS  HEREBY
! TRANSFERRED.
! 
! THE INFORMATION IN THIS SOFTWARE IS  SUBJECT TO CHANGE WITHOUT NOTICE
! AND  SHOULD  NOT  BE  CONSTRUED  AS A COMMITMENT BY DIGITAL EQUIPMENT
! CORPORATION.
! 
! DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE  OR  RELIABILITY OF ITS
! SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
!-


    

	Jan, your solution is good, but it deals with another issue.
      My concern is not that, but inconsistent result from address 
      validation on TO: and CC:.

	Anyway, thanks for your reply.

						Yukiji