Conference iosg::all-in-1_v30

    Here's more information...
    
      o	MR TIDY runs at 5:00 PM.  The fetcher and sender run evrey 15
    	minutes.  No delivery receipts for the ALL-IN-1 IOS node are sent
    	until MR TIDY runs.
    
      o	Note that the initial message comes from Australia to the United
    	States via MR/X.  I'm assuming that POSTMASTER is the originator
    	of the delivery receipt message, therefore must POSTMASTER be
    	defined in DDS?  Is it possible that since POSTMASTER is not in
    	DDS, then the delivery receipt is not being delivered since
    	POSTMASTER is an unauthorized user of the X.400 Gateway?  But if
    	this is true, why don't we see this error in the MR/X log file
    	and why doesn't MR/X generate an NDN?  If POSTMASTER is not in DDS,
    	why do the delivery receipts go through at 5:00 PM, or is
    	POSTMASTER not the originator of the message when MR TIDY runs?
    
    Food for thought...
    
    David
    

    I am the project engineer working with David Finkelstein,
    
    The MR$TIDY process does a "purge/service" which explains the
    delivery at 5pm.  It also explains why no error messages in MRX
    because POSTMASTER is not the sender.  When POSTMASTER is defined
    in DDS "AND" the original recipient is addressed 'normally', everything
    works fine as expected, except for one thing.
    - The TS is configured for "NOT" delivering service messages
      interactively which causes two delivery reports to be generated.
      - The first one from normal A1 IOS processing and the
        second one from MR$TIDY as a result of the original message staying 
        in the MR A1 mailbox with the same message id but its priority changed
        to "-1" and its timestamp updated.
    
         - Currently A1 is defined with "/nosuppress_delivery".  Should it
           be /"suppress_delivery"?
    
      The confusion I have is why does it matter how the original recipient
      is addressed.  For instance,
      - If the original recipient is addressed as USER@A1@NODE and delivery
        receipt was requested everything works as expected.
      - BUT if the original recipient was addressed as USER@A1@NODE@NODEX
        where NODEX is an intermediate node that performs some conversions
        on the message, the delivery report is never generated within 
        A1 IOS.
        - In this case the recipient receives the message (and able to 
          generate a read receipt) but when the fetcher run there is NO
          message added to the sender queue, DQ.  There is NO information
          in the sender/fetcher/mti* log files that indicate a problem with
          the message.  This is confusing.  Why does the address of the
          original recipient intefere in the generation of delivery
          reports?
    
    I realize some of this is MAILBUS related but the last part of it is
    A1 IOS related.  The message is delivered to the A1 recipient and a
    delivery report never appears in the sender queue.  Does ALL-IN-1
    perform any checking on received address versus network.dat/profile.dat?...
    And why cannot I find any trace/log/error data...
    
    Thanks for any information,
    
    /John

    Ahhh, THIS problem...
    
    Warning, long, tortuous, complicated, note follows:
    
    Here's the scoop...  ALL-IN-1 IOS talks NBS V1 protocols (yuck, gag). 
    It uses VENDor elements to request Delivery [CDELIV] and Read [RRECPT] 
    receipts, not the 'standard' PerRecipientFlag and ReportRequest elements.
    
    Message Router has built-in NBS V1<->V2 conversion routines. These
    conversions kick in based upon the encoding level of the message and the
    protocol level of the fetching agent. So, for direct IOS to IOS path
    messages, the VEND[CDELIV] is actioned by the Fetcher, which produces
    a TEXT delivery report message from POSTMASTER.
    
    In their case, they had an intermediate MRX hop. MRX talks NBS V2
    protocols to Message Router. On the outbound path (NBS->X409) MRX used
    to look for the CDELIV and if present would set the confirm bit in
    the perrecflg for all the recipients in the X409 file. This then
    arrives at the incoming MRX, which translates the X409 to NBS,
    producing an NBS V2 message with perrecflgs but no VEND[CDELIV]. When
    IOS fetches the message, the TS, seeing the Confirm flag, creates a
    _real_ delivery report (assuming the A1 mailbox does not have the
    SUPPRESS_DELIVERY_REPORTS attribute).
    
    Thus, the type and "source" of the delivery report is dependant upon
    a number of factors. NOTE that above I said "MRX used to...". Some time
    ago (S2.2-004?) some additional code was added to optionally create the 
    two IOS VEND elements CDELIV and RRECPT on incoming messages. That is,
    if the switch was set, MRX would look at all the perrecflgs and generate
    a VEND[CDELIV] if any(?) of them had the confirm bit set, and similarly
    would generate a VEND[RRECPT] if there were any ReportRequest elements.
    
    For the RRECPT case, this solved a long-standing issue; now if someone
    in X400 land requested a "Read Receipt" and the message was going to
    IOS, low-and-behold, they actually got something back. (A TEXT message
    rather than a true Receipt Notification, but at least it was something).
    
    Unfortunately, as was later discovered, the new CDELIV creation logic 
    had a side-effect; now people received _two_ delivery notifications for
    messages that came in from MRX. One from the Transfer service as
    directed by the perrecflg.Confirm bit, and one from the IOS Fetcher as 
    directed by the VEND[CDELIV] element. For direct IOS to IOS, only the
    CDELIV comes into play (hence only one pseudo-report), and for other
    agents like A1MAIL which use perrecflg.confirm, only the TS report occurs.
    
    Two other factors that further complicated the issue at this site were:
    1) Someone had added SUPPRESS_DELIVERY_REPORTS to the A1 mailbox
    2) MAILbus Conversion Manager was in the message path.
    
    What (1) meant was that _only_ the VEND[CDELIV] requested, Fetcher
    produced, delivery reports could occur. However, as you can see, this
    means that any other V2 NBS agent that uses the 'standard' perrecflg
    to request delivery reports wouldn't get them. That is, something like
    A1MAIL which talks NBS V2 and doesn't produce a VEND[CDELIV] would set
    the perrecflg.confirm bit, but because the A1 mailbox had Suppress_
    Delivery_reports set, the TS would not generate a delivery report.
    
    The significance of (2) is that MCM talks NBS V2. In fact, MCM uses the
    MRIF interface, which also has to do some contortions to try to make
    inter-operating with IOS "transparent". One of these contortions has to
    do with the CDELIV and RRECPT elements. (Here we go again). When MRIF
    is disassmebling a message with a CDELIV, it also does the "trick" of
    setting the perrecflg.confirm bit for all recipients. (It also creates 
    the ReportRequest elements when it sees a RRECPT). Thus, it "appears"
    to the application that the message was created by a NBS V2 application.
    
    However, MCM doesn't just DISassemble the message, it also REassembles
    a new one. Thus the CDELIV (which it can't see) doesn't get created on
    output, just the perrecflgs with the confirm bit. Now if the A1 mailbox
    _didn't_ have the Suppress_delivery_reports flag set, they would have
    gotten their TS generated delivery report. With it set on the A1 mailbox, 
    and without a CDELIV, NO delivery report is generated.
    
    Thus, a message that started off with NBS V1 and CDELIV, arrived at
    MRX which saw the CDELIV and produced the X409 with perrecflg.confirm. 
    This X409 arrived at another MRX, where the new logic created a CDELIV 
    _and_ perrecflg.confirm. This then went to MCM, where the CDELIV was 
    hidden by MRIF and perrecflg.confirm was (again) set. MCM then produced 
    a new message without the CDELIV but with perrecflg.confirm set. This
    arrived at the A1 mailbox, where SUPPRESS_DELIVERY_REPORT inhibited the
    TS delivery report. Since there was no CDELIV, the Fetcher didn't either.
    
    Oh, and the other confusion factor was that apparently some of the MR
    nodes had Service message generation deferred (for MR$TIDY), rather than 
    being generated 'on the spot'. Therefore, depending upon the message 
    source and destination, the MR config of the destination node, the version 
    and config of any intermediate MRXs, whether MCM was in the path, and
    whether the suppress_delivery_report flag was applied to the A1 mailbox,
    they would get zero, one, or two delivery reports, at varying times.
    
    Soooo, They need to:
    Take the SUPPRESS_DELIVERY_REPORTS option off the A1 mailbox,
    configure the TS for immediate service message generation and either
    (a) accept that in some cases they will get two delivery reports for
    messages from X400-land going to IOS, or (b) disable the MRX feature, in 
    which case they will only get one delivery report, but they also won't
    get "Read Receipts" for messages from X400-land going to IOS. (Note that
    for case (a), if the message goes through MCM, they will only get one,
    since it can't "see" the CDELIV element and hence doesn't create one).
    
    	Dave
    
    PS - I have filed a bug report against MRX, with a recommendation that
    the MRX switch controlling this be made a three-way (off, RRECPT, and
    RRECPT+CDELIV) rather than the current off/both behaviour.

    Oh, and one other factor/issue...
    
    For the IOS generated Text delivery notifications, which come from 
    POSTMASTER, you _will_ need a DDS entry that allows X400SEND if you
    want these to go back across the X400 hop to the originator.
    
    	Dave

    Actually, I simplified "the mess" in .11.
    
    Believe it or not, there is actually a third mechanism in TS for 
    requesting Delivery Reports, which I didn't mention... Thankfully,
    there is only one agent I'm aware of that uses it, and it is an
    undocumented feature for that agent.
    
    	Dave

    Yea,
    
    We have designated ADMIN/APPLICATION entries like this to allow this.
    
    Thanks,
    
    John

Will be posted in FORTY2::MAILBUS and IOSG::ALL-IN-1



Hi,

Some confusion has existed so far concerning the newly implemented 
A1_REQS_SUPRESSED parameter. In order to bring some light into the darkness 
and to correctly consult my customers I did some testing around this flag. 
First I used the MAILworks User Agent to send to ALL-IN-1 IOS and second I 
used ALL-IN-1 IOS to send to the ALL-IN-1 IOS system.

In both cases I tested with the A1_REQS_SUPRESSED flag not set (default) 
and set (visible when issuing MRXMAN>SHOW PARAM). The configuration was as 
follows:

                 PRMD A                                     PRMD B
        ----------------------------------            -------------------
        !  -----------    -------------  !            !   -------------  ! 
        !  ! A1 IOS  !    ! MAILworks !  !            !   ! A1 IOS    !  !
        !  -----------    -------------  !            !   -------------  !
        !       !               !        !            !         !        !
        !                                !            !                  !
        !  ----------------------------- !            !    ------------- !
        !         Message Router         !            !     Message Rtr  ! 
        !  ----------------------------- !            !    ------------- !
        !                !MRX A!         !<---------->!        !MRX B!   ! 
        !                -------         !    X.400   !        -------   !
        !--------------------------------!            !------------------!



Sent from ALL-IN-1 IOS in PRMD A to A1 IOS in PRMD B with the 
A1_REQS_SUPRESSED flag on MRX B set the test results were as follows: 

- When Delivery Receipt and Read Receipt in ALL-IN-1 was 
  requested (=YES) only a Delivery Notification was received back (no 
  Receipt Notification)

- When Read Receipt was requested nothing was received back (MRX in 
  PRMD B didn't send the request to A1 IOS)

- When Delivery Receipt was requested a Delivery Notification was 
  received

Sent from ALL-IN-1 IOS in PRMD A to A1 IOS in PRMD B with the 
A1_REQS_SUPRESSED flag on MRX B not set the test results were as follows: 

- When Delivery Receipt and Read Receipt in ALL-IN-1 IOS was 
  requested (=YES) a Receipt Notification and two (!) Delivery 
  Notifications were received back. One DN comes from MR (Postmaster) and 
  the other DN comes from ALL-IN-1 IOS Postmaster. Note that the ALL-IN-1 
  Postmaster has to be registered in DDS in PRMD B. Also note that only the 
  DN coming from MR in PRMD B is considered to be a Service Message. The DN 
  coming from A1 IOS is a message coming from Postmaster (or however the 
  DDS attributes are) and the Receipt Notification is a message coming from 
  the recipient.  

- When Read Receipt was requested a Receipt Notification was received  
  back (MRX in PRMD B did send the request to A1 IOS)

- When Delivery Receipt was requested two (!) Delivery Notifications 
  were received (one service message from MR and one DN from A1 Postmaster) 



Sent from MAILworks in PRMD A to A1 IOS in PRMD B with the 
A1_REQS_SUPRESSED flag on MRX B set the test results were as follows:

- When Delivery Notification and Receipt Notification in MAILworks was 
  requested (=FULL) only a Delivery Notification was received back (no 
  Receipt Notification)
 
- When Receipt Notification was requested nothing was received back (MRX in 
  PRMD B didn't send the request to A1 IOS)

- When Delivery Notification was requested a Delivery Notification was 
  received

Sent from MAILworks in PRMD A to A1 IOS in PRMD B with the 
A1_REQS_SUPRESSED flag on MRX B not set the test results were as follows: 

- When Delivery Notification and Receipt Notification in MAILworks was 
  requested (=FULL) a Receipt Notification and a Delivery 
  Notification was received back. The DN comes from MR (Postmaster) and     
  the Receipt Notification comes from the recipient. Remember that in this 
  case when sent out of ALL-IN-1 IOS two DNs were received.  

- When Receipt Notification was requested a Receipt Notification was received  
  back (MRX in PRMD B did send the request to A1 IOS)


- When Delivery Notification was requested a Delivery Notification 
  was received (with A1 IOS two were received)



Summary:

Be aware that whenever the A1_REQS_SUPRESSED flag is set, no Receipt 
Notifications will be sent by A1 IOS. On the other hand the flag prevents 
from receiving two DNs (one service message from MR and one DN from A1 IOS 
Postmaster). Be also aware that the problem with receiving two DNs only 
appears when sending from A1 IOS. 

Conclusion:

You only get what you requested (and not more !) when you use MAILworks on 
the sending end and have the A1_REQS_SUPRESSED not set. When using A1 IOS 
on the sending end you either get no RNs or two DNs...

Rene