Conference virke::mrmemo

    RE: .0

    Hello Rainer,

    Thank you for the problem report and your testing efforts.
    I'm sorry about not giving any response earlier but we have
    had cooling problems in our development cluster computer room a couple
    of days but now we're up and running again.

.0> The message status (MEMO EXPAND COMMAND) was NOT YET CONFIRMED for
.0> some time. After a while the TS did send back a service message and the
.0> status changed to BEING SENT TO. This was with a single recipient
.0> (either using MRGATE, ALL-IN-1 or X.400 Mail UA). In the first two
.0> cases the service message was created by TS. Our X.400 Mail UA (new
.0> name ALL-IN-1 Mail) mailbox supresses service messages and the service
.0> message was created by the UA. 
    
    I haven't been able to reproduce this. It sounds very strange. Can you
    reproduce this at will?


.0> Then I made some tests with multiple recipients: 

.0> 1) four recipients using different UAs (MEMO, MRGATE, ALL-IN-1, X400MAIL)

.0> Three service messages were created and fetched by our MEMO gateway. But 
.0> only for the local MEMO user and the fastest service message the message 
.0> status changed. In my environment the first service message was created 
.0> by X400MAIL. Expanding the original message now displays the status 
.0> correctly only for two recipients. For the ALL-IN-1 and VMSmail recipient 
.0> I've still this incorrect NOT YET CONFIRMED message.

    I have found the problem behind this.
    In MEMO, there is something called receiver list position (RLP). This is
    a number used to quickly identify an entry in a distribution list by index.
    What we have done wrong is to send RLP:s to MEMO based on the contents
    in a service message from MR. A delivery notification from a UA only
    contains the recipients destined for that particular UA (I haven't checked
    X400MAIL). MRMEMO then numbers these recipients starting from 1 and sends
    the RLP:s to MEMO. When RLP:s are present in a status message, MEMO ignores
    the recipient names.

    So in your case, where you send 1 message to 4 different UA:s, each
    returning delivery notification from MR will send RLP=1 back to MEMO, which
    will mark the first recipient in the DISTRIBUTION LIST as "delivery
    confirmed".


.0> 2) two recipients using different UAs (MRGATE and ALL-IN-1)

.0> Here also the status changed only for one recipient (ALL-IN-1) but 
.0> surprisingly the first service message was created by MRGATE. 

    I guess (and hope) that your first recipient was ALL-IN-1. The explanation
    above will then fit the description.


.0> 3) two recipients using the same UA 

.0> The message status changed correctly for both recipients. Here I 
.0> tested against MRGATE, X400MAIL and ALL-IN-1.
    
    In this case, both recipient delivery notifications are contained in the
    same service message from MR. RLP=1, and RLP=2 will be sent to MEMO
    and change the status of distribution list entries 1 and 2 to "delivery
    confirmed".

----------------------------------------

    Well, that was the problem. Now, what to do about it?
    Unfortunately, there is no easy way to fix this. 

    We can't use the RLP:s since they refer to the complete distribution list,
    which is not known when a delivery notification message comes from MR.

    When the RLP:s are gone, MEMO will have to identify the notifications by
    name.  But this won't work except in special cases!  I'll explain:

    The REPORT part of a delivery notification service message only contains
    the mailbox and userid. E.g. A1 and ADAMS. But MEMO also wants the node
    name to be able to match the name 'VAX.ADAMS@A1@NODE in the distribution
    list. I guess we could dig up the node name from the trace part of the
    service message but that is not a very clean or safe way to do it.

    The only situation where it works fine is when the destination mailbox
    is on the same node as the MRMEMO server. Then the node name will be
    correct.

    Then we have DDS. Suppose a destination like "VAX.USER" or
    "VAX.SUR=ADAMS@GIV=JOHN" is used in MEMO. The DDS lookup and address
    translation will change the destination to something like
    USER@MAILBOX@NODE.  The original recipient address string will be
    completely lost when the MR delivery notification arrives and it will
    not be possible to tell MEMO which recipient the notification concerns.

    So, the short time choice we have is to either continue to send the RLP:s
    to MEMO. Confirmations will then work when there is only one destination
    UA. If we stop sending RLP:s to MEMO, only recipient addresses that look
    exactly the same when coming back in MR delivery notifcations will be
    identified and confirmed by MEMO.

    The only complete solution would probably be to make MRMEMO keep a database
    containing all outstanding messages. But if that is to be done at all, it
    will take time.

    I am sorry about this, but this is how it works.


    Anders, MRMEMO development

    Hi Anders,
    
    >    I haven't been able to reproduce this. It sounds very strange. Can you
    >    reproduce this at will?
    
    That's exactly how it should work. Normally TS sends back a delivery
    report as soon as the message is fetched by the application (this could
    be a UA or gateway). But some of our applications are also generating the
    service messages (X400mail is an example). Therefore we have to
    suppress the generations of delivery reports by TS (Mailbox Qualifyer
    /SUPPRESS_DELIVERY_REPORT). 
    
    
>>  .0> 2) two recipients using different UAs (MRGATE and ALL-IN-1)

>>  .0> Here also the status changed only for one recipient (ALL-IN-1) but 
>>  .0> surprisingly the first service message was created by MRGATE. 

>>    I guess (and hope) that your first recipient was ALL-IN-1. The explanation
>>    above will then fit the description.
    
    What do you mean with 'first'. In my test with 4 recipients the
    status looks like
    
    	LOCAL MEMO User   	SELECTED
        ALL-IN-1 User           EXCEPTION NOT YET CONFIRMED
        VMSmail User            EXCEPTION NOT YET CONFIRMED
        X400Mail User           BEING SENT TO
    
    The first service message sent to the gateway was created by X400mail.
    
1989101215111300,S472,MEMO                           
1989101215111500,E472,31115121019891/472@TSSCOS,52
1989101215111500,D472,MUNOSI,                      <-- ALL-IN-1 on MUNOSI
1989101215111800,D472,MRGATE,                      <-- VMSmail
1989101215111800,D472,X400,                        <-- X.400 Mail UA
1989101215113300,F472,X400
1989101215120500,S473,X400                         <-- Del. Rep X.400 MAIL
1989101215120500,E473,0500121512101989/A00004/UNHOLD,48
1989101215120500,D473,MEMO,
1989101215121000,F472,MRGATE                       
1989101215121200,S474,SERVICE_MESSAGE              <-- Del Report MRGATE
1989101215121300,E474,21215121019891/474@TSSCOS,18
1989101215121300,D474,MEMO,
1989101215133900,F473,MEMO
1989101215133900,K473
1989101215141300,F474,MEMO
1989101215141400,K474
1989101215330200,F472,MUNOSI
1989101215364100,S475,MUNOSI                       <-- Del Report ALL-IN-1
1989101215364300,E475,53835121019891/8939@MUNOSI,21
1989101215364300,D475,MEMO,
1989101215380200,F475,MEMO
1989101215380400,K475

    
    In the second example it looks like
    
        ALL-IN-1 User           SENT TO
        VMSmail User            EXCEPTION NOT YET CONFIRMED
    
    Here the first service message sent to the gateway was created by
    MRGATE. There is also a difference in the status of the confirmed 
    recipient. In example 1 we have BEING SENT TO whereas in example 2
    we have SENT TO.
    
1989101216443200,S486,MEMO
1989101216443300,E486,03446121019891/486@TSSCOS,37
1989101216443300,D486,MUNOSI,                    <-- ALL-IN-1 on MUNOSI
1989101216443700,D486,MRGATE,                    <-- VMSmail
1989101216445300,F486,MUNOSI
1989101216450800,F486,MRGATE
1989101216451000,S487,SERVICE_MESSAGE            <-- Del Report of MRGATE
    1989101216451000,E487,80546121019891/487@TSSCOS,18
1989101216451000,D487,MEMO,
1989101216461600,F487,MEMO
1989101216461700,K487
1989101216464700,S488,MUNOSI                     <-- Del Report of ALL-IN-1
1989101216464900,E488,25846121019891/8945@MUNOSI,21
1989101216464900,D488,MEMO,
1989101216475800,F488,MEMO
1989101216475800,K488

    
    Regards,
    
    Rainer
    
        

    Ok, now when I have more information I think I can make a clearer
    explanation.

.2> >>I guess (and hope) that your first recipient was ALL-IN-1. The explanation
.2> >>above will then fit the description.
.2>    
.2> What do you mean with 'first'. In my test with 4 recipients the
.2> status looks like
.2>         
.2>     LOCAL MEMO User   	SELECTED
.2>     ALL-IN-1 User           EXCEPTION NOT YET CONFIRMED
.2>     VMSmail User            EXCEPTION NOT YET CONFIRMED
.2> 	X400Mail User           BEING SENT TO
.2> 	    
.2> The first service message sent to the gateway was created by X400mail.

    MEMO numbers the entries in the distribution list like this:

    RLP (Receiver List Position)

    1		LOCAL MEMO User
    2		ALL-IN-1 User
    3		VMSmail User
    4		X400Mail User

    The first recipient (LOCAL MEMO User) is a passive recipient which means
    that MRMEMO doesn't set the ACTION bit in PERRECFLG for the recipient.
    The passive recipient still, however, occupies position 1 in the 
    distribution list. This is where MRMEMO does the wrong thing and ignores
    the passive recipient when sending the status message back to MEMO.
    MRMEMO erroneously tells MEMO that the status of entries 1,2 and 3 should
    be changed to 'SENT TO, DISTRIBUTION NOT YET CONFIRMED'. It should be
    entries 2,3 and 4. That's why the 4:th entry remains 'BEING SENT TO'.
    
    A workaround to this problem is to put the MRMEMO recipients first in the
    distribution list. This was mentioned in the MRMEMO V1.1 Release Notes but
    for some reason never made it into the V2.0 documentation: 

          2.2.6 Mixed MEMO distribution list restriction

             A MEMO user can use distribution lists to send one message
             to several recipients, local MEMO users as well as Message
             Router recipients connected through MRMEMO. However, if the
             two recipient categories are mixed in one distribution list,
             then all Message Router recipients must be listed BEFORE
             all local MEMO recipients. If not it will lead to unexpected
             behaviour by the MEMO internal message status control.

    
.2> In the second example it looks like
.2> 
.2>	ALL-IN-1 User           SENT TO
.2>	VMSmail User            EXCEPTION NOT YET CONFIRMED
.2>
.2>	Here the first service message sent to the gateway was created by
.2>	MRGATE. There is also a difference in the status of the confirmed 
.2>	recipient. In example 1 we have BEING SENT TO whereas in example 2
.2>	we have SENT TO.
    
    Here the MEMO distribution list numbers look like:

    1	ALL-IN-1 User           SENT TO
    2	VMSmail User            EXCEPTION NOT YET CONFIRMED

    When the delivery notification arrives from MRGATE, MRMEMO will build a
    status message for MEMO from the information in the service message. The 
    service message only contains one recipient so MRMEMO (erroneously) gives
    it number 1. MEMO then changes status of entry number 1, which is another
    recipient! When the notification from ALL-IN-1 arrives, it too will 
    "change" the status of entry 1 and entry number 2 will never be changed.

    A solution to these problems will at the top of list of things to
    do in next version of MRMEMO. But for now, to make notifications work
    properly, put the MRMEMO recipients first in the distribution list and
    only send to one UA at a time. 

    Anders

    The delivery notification problem is now fixed (in V2.0A, which will
    be a "available-on-request" patch release).

    In V2.0A, there is no restriction on how the distribution list in MEMO
    may be composed. Local MEMO users and various external (including MRMEMO)
    destinations can be mixed freely in a distribution list.

    The key to solving the problem was the NBS item EXTENSIONID, which is used
    as "receiver list position" to uniquely identify an entry in the
    distribution list.

    Delivery notifications passing through X.400 (MRX - X.400 - MRX) will NOT
    work because X.400 "destroys" the MEMO message identification when UACONTID
    is translated to the IA5 character set. We'll try to fix this in next
    version (V2.1?) by converting the MEMO message id to a character string
    that can pass unmodified through X.400.

    Anders

    We have a customer who wants to build a gateway to connect his MHS
    (based on SIEMENS systems) to our MAILbus. One of the strongest
    requirements is the interworking with VAX Mailgate for MEMO. The
    customer wants to extend the message header of his mail system to build
    some X.400 services (like delivery and receipt notifications). The
    X.400 red book says that UACONTID should be IA5 printable string. 
    The NBS X.400 Implementor's Guide says maximum of 16 characters.  
    
    The customer is planning to support a UACONTID with maximung length of
    16 characters but not to support EXTENSIONID within his MHS. Under
    these circumstances can we really be sure that the interworking with 
    the MEMO Mailgate V2.1 is failproof.
    
    Regards,
    
    Rainer 
    

    
    Hi Rainer,
    
>    The customer is planning to support a UACONTID with maximung length of
>    16 characters but not to support EXTENSIONID within his MHS. Under
>    these circumstances can we really be sure that the interworking with 
>    the MEMO Mailgate V2.1 is failproof.
    
    No. Actually we moved from relying too heavily on EXTENSIONID in V2.1.
    We discovered that EXTENSIONID isn't allowed on RECEIPTS. So we
    switched to introducing a Domain Defined Attribute to hold the Receiver
    List Position equivalent. As you know, a DDA is a composite element
    containing two TEXT attributes, TYPE and VALUE. So for this purpose we
    use the TYPE string "MRMRLP" to identify the attribute and a numeric
    string VALUE to represent the actual RLP.
    
    So, for any notification message (be it delivery or receipt) that
    arrives, we use the following "search order" to map the notified
    recipient to the intended one:
    
    1) DDA TYPE MRMRLP (always works if it's there)
    
    2) EXTENSIONID (works most of the time for delivery reports, but not
    		    receipts because it's not allowed)
    
    3) USERID+ROUTE(s) (very seldom works)
    
    
    So my advice is, try and return any DDA:s that you receive and you
    stand a fair chance that MRMEMO will recognize your notifications.
    
    (BTW we use DDA:s for other purposes as well. They are related to
    MEMO Delete Notifications, which is an internal MEMO feature. This
    means that we can support this functionality when messages are relayed
    from one MEMO system to another via MRMEMO (MAILbus backbone and all
    that). If your customer's MHS has a similar feature, then I suggest you
    have a look at this)
    
    
    About UACONTID, we have now a hashing scheme which makes sure that
    the values that MRMEMO generates are within the restrictions
    (printable, max 16 chars).
    
    For notifications delivered by MRMEMO V2.1, I think it's best to
    display the MRIF$EXAMPLE_DISASSEMBLE dumps of Contents files below (one
    delivery report and one Receipt Notification). The key elements here
    are: 
    
    1) The UACONTID in the Delivery Report (reflects UACONTID in the
       original message). 
    
    2) The REPORTED_ID in the Receipt Notification (same here, the original
       message was a MEMO one, this is a hashed ID) 
    
    3) ROUTEs + USERID (hopefully, this will help the originating UA to map 
       the actual recipients to the intended ones)
    
    4) DDNAME
    	TYPE	MRMRLP
        VALUE   1
       (this is what MRMEMO will look for first)
    
    
    
    Sorry for going on at such length. Don't hesitate to ask for
    clarification.
    
    Cheers,
    
    	Stefan
    
    ===========================================================================
    
    ********* DELIVERY REPORT CONTENTS FILE ********
    
Output of file mrmemo$dir:mrmemo5-notcnt
SERVICE-MESSAGE-CONTENT
   MESSAGE_ID:
      IDENTIFIER: avsaddr 01
   INTTRACE:
      MTA: MEMO/Gateway
      ARRIVALDATE:  1-OCT-1990 10:57:08.00
      TRACE_ACTION: %X00000000
   UACONTID: avsaddr 01
   INFO:
      DDNAME:
         DDTYPE: MRMRLP
         DDVALUE: 1
      ROUTE: VAXBOX
      ROUTE: MEMO5
      USERID: DGA.PERSSON
      PERRECFLG: %X00000090
         ACTION: Y
         MR_BASIC: N
         MR_CONFIRMED: N
         UA_BASIC: N
         UA_CONFIRMED: Y
      ARRIVALDATE:  1-OCT-1990 10:57:08.00
      DELIVERDATE:  1-OCT-1990 10:57:08.00
    
    
    ===========================================================================
    
    ********* RECEIPT NOTIFICATION CONTENTS FILE ********
    
    
Output of file mrmemo$dir:mrmemo5-rnotcnt
RECEIPT-NOTIFICATION
   RECEIPTINFO:
      RECEIPTDATE:  9-AUG-1990 14:11:26.00
      RECEIPTTYPE: %X00000001
   REPORTED_ID:
      IDENTIFIER: VxB7ia400Po9UFBM
   ACTUALRECIP:
      DDNAME:
         DDTYPE: MRMRLP
         DDVALUE: 1
      ROUTE: VAXBOX
      ROUTE: MEMO5
      USERID: DGA.PERSSON
    
    

	Hi Stefan,

	thanks for your fast reply. 

	I think I start to understand your problems. It seems that there 
	were several different problems:	

	1.	The UACONTID was distroyed by MRX. Therefore you lost the link
		between the delivery notification and the original message. 
		You tried to fix this by converting the UACONTID.
	2.	The intended recipient in the original message did NOT look
		like the recipient informations in the delivery info 
		(ROUTE + USERID very seldom works). You tried
		to fix this problem by using the EXTENSIONID (for the
		position). 
	3.	The solutions above don't work for receipt notifications 
		because 'EXTENSIONID' is not an element of receipt 
		notifications. Therefore instead of using EXTENSIONID you
		now are using DDAs. (In addition to this you have to use 
		the APPL_MSG_ID instead od UACONTID).

	If this is correct then the interworking with our customers gateway
	should work for delivery and receipt notifications (without using 
	DDAs) if

	1.	Wie support UACONTID and APPL_MSG_ID (up to 16 characters).
	2.	MEMO is able to identify the intended recipient in the
		distribution list. Our customer is planning to use DDS 
		validation and short form addresses within MEMO (8+8).
		Therefore the list position should not be necessarry.

	But I have one other concern with your solution. Sending a
	message through MRX could lose your DDAs (this is the case if 
	you don't use SAAs in the recipients O/R name). As soon as 
	MRX uses the USERID and ROUTE terms with keywords to build the 
	X.400 O/R Address the SAAs (and therefore your DDAs) are ignored.  
	But I guess that you will use USERID/ROUTE and SAA addressing
	for X.400 recipients. 	

	I've another question. For me it's not clearly stated in the 
	MRIF manual how the envelope of a Receipt notification has to look
	like. Is it the same as for a delivery report (I guess so) or like
	an Interpersonal Message (who is the SENDER ins this case)? 

	I just checked the MRIF Implementor's guide about UACONTID. There it
	is stated that you should use 16 DIGITS (nothing about IA5 printable).

	Regards 

	Rainer
	
		


		

    
    Rainer,
    
    Yes, you have understood the original problem correctly.
    
    >	If this is correct then the interworking with our customers gateway
    >	should work for delivery and receipt notifications (without using 
    >	DDAs) if
    >
    >	1.	Wie support UACONTID and APPL_MSG_ID (up to 16 characters).
    >	2.	MEMO is able to identify the intended recipient in the
    >		distribution list. Our customer is planning to use DDS 
    >		validation and short form addresses within MEMO (8+8).
    >		Therefore the list position should not be necessarry.

    Ah, there's a problem. MRMEMO does not do DDS lookups on reported
    recipients. If the original MEMO address was ABC.RAINER, and the
    reported recipient is ROSENBERGER@MRGATE@VAX1, with no qualifying
    numeric positioning (EXTENSIONID or DDA MRMRLP) then we have a no
    match situation.
    
    
    >	But I have one other concern with your solution. Sending a
    >	message through MRX could lose your DDAs (this is the case if 
    >	you don't use SAAs in the recipients O/R name). As soon as 
    >	MRX uses the USERID and ROUTE terms with keywords to build the 
    >	X.400 O/R Address the SAAs (and therefore your DDAs) are ignored.  
    >	But I guess that you will use USERID/ROUTE and SAA addressing
    >	for X.400 recipients. 	
    
    Well in this case I guess that's true provided the DDS record contains
    the proper data. But you're right it is a problem area.
    
    
    >	I've another question. For me it's not clearly stated in the 
    >	MRIF manual how the envelope of a Receipt notification has to look
    >	like. Is it the same as for a delivery report (I guess so) or like
    >	an Interpersonal Message (who is the SENDER ins this case)? 

    No, it is an Interpersonal message envelope (MRIF$K_ENVELOPE). I agree
    that the MRIF V3.1 documentation is not really clear on this, but table
    3-2 on page 3-19 should tell what you need to know. The SENDER, well I
    guess you could provide some general address here, but we use the
    actual recipient as sender also. It makes sense to us.
    
    
    >	I just checked the MRIF Implementor's guide about UACONTID. There it
    >	is stated that you should use 16 DIGITS (nothing about IA5 printable).

    Yes, but none of the products we've tested against so far choke on the
    printable chars (including MRGATE, ALL-IN-1 IOS, ALL-IN-1 Mail, MRX). Also
    the X.400 spec definitely states printables. We chose to ignore the
    Implementor's Guide on this one.
    
    
    cheers,
    
    	Stefan

    Hello Stefan,
    
    it seems that you are answering my questions faster than I can ask
    them. Now everything seems to be rather clear to me. 
    
    I think it's strange to use a user envelope for a Receipt Notification.
    Then you can request a delivery notification on a receipt notification. 
    Now I understand the bodypart RNOTIF in the content of a delivery report. 
    
    Our situation will not be as bad as in your example (send to 
    ABC.RAINER and return  ROSENBERGER@MRGATE@XYZ) In our sitiuation we 
    will send to ABC.RAINER and return ABC.RAINER@mbx@gwynode. 
    But I guess that even this quite good situation is not good enough. 
    So I'll try to support at least one DDA Name instead of EXTENSIONID. 
    
    Cheers,
    
    Rainer

    
    Rainer,
    
    > I think it's strange to use a user envelope for a Receipt Notification.
    > Then you can request a delivery notification on a receipt notification. 
    > Now I understand the bodypart RNOTIF in the content of a delivery report. 
    
    I agree, it would be more natural if the envelope were SRVENV. But as
    long as we have the option of not requesting delivery notifications I 
    guess that's not a real problem. And I'm sure there's someone out there
    in MRIFland that finds it real useful to have delivery reports on Read
    Receipts.
    
    
    > Our situation will not be as bad as in your example (send to 
    > ABC.RAINER and return  ROSENBERGER@MRGATE@XYZ) In our sitiuation we 
    > will send to ABC.RAINER and return ABC.RAINER@mbx@gwynode. 
    > But I guess that even this quite good situation is not good enough. 
    
    Correct.
    
    > So I'll try to support at least one DDA Name instead of EXTENSIONID. 
    
    Wise decision indeed.
    
    
    cheers,
    
    	Stefan