Conference iosg::all-in-1_v30

    Hi Glyn,
    
    >The problem is that when the sender on system 1 requests a delivery
    >receipt, it is generated when the message is received by the
    >autoforward account on system 2. I expected it to be generated either
    >by the X.400 gateway or the destination users X.400 MTA.
    
    Well the user did request a delivery receipt and it was delivered to
    the account on system 2.  That's how it's suppose to work !!!  You
    could SPR this unless someone gives a reason why this cannot be
    changed.
    
    >As soon as I send messages thru the MR/X gateway but bypassing the
    >autoforward account everything seems to work OK.
    
    My question is why are they using the 2nd system to autoforward ?  Why
    can't they just use the MR/X gateway ?
    
    Regards,
    
    Sunil

    Sunil,
    
    
    The customer is using an autoforward account because the want an
    ALL-IN-1 user to be able to address an X.400 user in the same way as if
    they were addressing another ALL-IN-1 user.
    
    They do not have a corporate DDS environment.
    The X.400 addresses are too logn for nicknames (They have not yet gone
    to V3.0
    
    As a test I modified they autoforward account so messages were
    autoforwarded to another ALL-IN-1 account. THis time the delivery
    notification was issued by the final destination ALL-IN-1 account and
    not the autoforward account.
    
    Any ideas?
    
    regards,
    
    Glyn

No, this isn't going to work.

When ALL-IN-1 does an auto-forward to a remote account (MRX in this case), it 
builds a new envelope, and discards the one it received from the originator. 
Unfortunately, I think that's where your delivery report request gets lost. 
I'd say that's a bug, and you could SPR it, but as the whole remote mail area 
is undergoing reconstruction at the moment, I don't think you'd get a fix 
(before the next release.)

Read receipts are different. The RR request only goes on the content, which is 
not mangled by the AF mechanism. However, you have to set up MRX correctly to 
ensure that the request is honoured as it goes to X.400 and back. Read the MRX 
doc very carefully (and see the MAILBUS conf) to ensure you have it all set up 
right.

grahame

    Well, this is very odd.

    The delivery notice should be issued by the final destination account,
    as you found in your second test.

    ALL-IN-1 can't tell the difference between an auto-forawrd to another
    ALL-IN-1 account and an auto-forward to a gateway (assuming they're
    both "remote" as far as ALL-IN-1 is concerned, that is the addresses
    contain @ routing terms).

    Are you sure that the auto-forwarding account sent the delivery notice
    in the gateway case? Is it a normal auto-forward (not using some AMTS)
    -- that is, is the MAIDES of the forwarding accounts' profiles set to
    ALL-IN-1 (or [sic] ALLIN1), or to something non-standard?

    As to read receipts, I believe this is something to do with the gateway
    not translating the wierd ALL-IN-1 read receipt request into the
    standard X400 one. If no-one here can remember quickly, I'm sure this
    has been discussed over in FORTY2::MAILBUS.

    Dave.
    

    I have tested delivery receipts again and they are definately being
    generated as soon as the message hits the autoforward account.
    
    Here is the receipt that is generated:
    
                                          From:
                                                      POSTMASTER
                                            Dept:
                                            Date:     28-Jul-1993 03:16pm
    BST
                                            Tel No:
    
    
    
    Subject: Message Delivery Report
    
    RE  Message ID: 14415182703991/7359@PTZV15
    Generated by node: PTVV17
    
    
    Attempted delivery to:
    
        Route                 : @A1         <--
        Userid                : DAVIES.G
        Arrival date          : 28-JUL-1993 15:15
    
        Deliver date          : 28-JUL-1993 15:16
    
    This delivery was successful
    
    Regards,
    
    Glyn

That delivery receipt was issued by Message Router when the message arrived at 
the A1 mailbox of the first system. i.e. before the fetcher ran. I think you'd 
agree it's unfair to expect MR to know that the eventual recipient has 
auto-forward set?!

However, are you also saying that you didn't get an ALL-IN-1 delivery receipt 
from either the first or the second account? (As I said earlier, I don't think 
you'll get one from the 2nd, but I can't remember what should happen if a DR 
is requested from an account with AF set)

grahame

    Two things here -
    
    1. As Grahame says, that receipt was issued by Message Router. However,
    it isn't supposed to do that for ALL-IN-1 mailboxes! (Because it knows
    that ALL-IN-1 does its own.) 
    
    Soooo - is there something funny about the message router configuration
    on that node (/REPLACE or /ROUTE terms on the mailbox, for example?)
    
    2. As I said before, ALL-IN-1 won't issue a receipt when it
    auto-forwards a message, as it expects the final destination to do it.
    Since, as Grahame said in .-<a few>, the gateway doesn't issue delivery
    receipts, that explains why you don't get one in this case.
    
    Dave.

>          <<< Note 3074.8 by IOSG::SHOVE "Dave Shove -- REO2-G/M6" >>>
>                          -< Curiouser and curiouser >-

>    1. As Grahame says, that receipt was issued by Message Router. However,
>    it isn't supposed to do that for ALL-IN-1 mailboxes! (Because it knows
>    that ALL-IN-1 does its own.) 
    
Rats, I knew there was something else! Yes, you need to:

MRMAN> modify a1/SUPPRESS_DELIVERY_REPORTS

grahame

    Graham, Dave,
    
    I believe one piece that is missing from the picture is MCM. From
    dealings with Glyn in another conference, and thinking about the
    previous replies, I suspect that MCM is "in-between" the two IOSs,
    which would result in the V1 NBS being upconverted to V2, hence the
    VEND[CDELIV] was expanded to perrecflg.confirms by the MCM hop. This
    would explain the TS generated delivery report.
    
    Given the complexity of the NBS V1/V2 up and down conversions and the
    characteristics of CDELIV and RRECPT handling by the various entities,
    this might not be solvable. At least _I_ don't want to think about it!
    
    Dave

    Dave,
    
    As you guessed, MCM is being used in this environment. I though I had
    done my testing without routing through MCM but I have gone back and
    found that this was not the case.
    
    The bottom line is that if messages are not routed thru MCM, delivery
    receipts get generated by the remote X.400 MTA. If messages are routed
    via MCM, delivery receipts get generated by the ALL-IN-1 autoforward
    account IF the suppress_delivery_reports attribute is not enabled on
    the A1 mailbox. If it is enabled, no delivery notifications get
    generated anywhere.
    
    Based on what you said in .10, I did an MRNBSDMP on a message that had
    gon thru MCM and one that hadnt. The one that hadnt had a VEND[CDELIV]
    attribute in it, the one did go thur MCM didnt.
    
    Can you just explain in a little more details why MCM modifies/removes
    this attribute.
    
    Regards,
    
    Glyn

    Dave,
    
    Thanks for explaining that for me. I am sorry I had to put you through
    it!
    
    
    Read receipts seem to be acting differently however. The following
    lists the tests I have done and the outcome:
    
    1. Message sent via MCM and then ALL-IN-1 autoforward.
    	Remote X.400 MTA does not recognise that a RR has been requested.
    
    2. Message sent via MCM bypassing ALL-IN-1 autoforward.
    	Remtote X.400 generates RR when message is read
    
    3. Message bypasses MCM but sent via ALL-IN-1 autoforward
    	Remote X.400 MTA does not recognise that a RR has been requested.
    
    4. Message bypasses both MCM and ALL-IN-1 autoforward.
    	Remote X.400 generates RR when message is read
    
    Any comments?
    
    Regards,
    
    Glyn

    Groan - You all are going to make me think about it, eh?
    
    It isn't MCM removing it - If you did NBS dumps, I'm sure you noticed 
    a lot of other differences between the original IOS message and the 
    MCM processd one. This is because IOS uses an ancient version of the 
    NBS encodings (ie NBS V1). Most other MR applications expect NBS V2, 
    including all MRIF (Message Router Programmers Kit) based one. In
    order to handle the differences, the transfer service does NBS V1<->V2
    conversions on the fly based on the encoding of the message and the
    protocol level of the agent. These conversions are not perfect; MRIF
    also tries to hide some of these differences. 
    
    VEND[CDELIV] is an example - There is no corresponding NBS V2 or X409
    element to this NBS V1 element. The closest that it can be approximated
    is to set the Env.To.PerRecflg.Confirm bit for all actionable recipients
    in the message. This is fine as far as it goes (ie for V1->V2 conversion)
    and is what MCM *sees* since it is an MRIF (ie NBS V2) application. So
    MCM faithfully reproduces what it sees - an NBS V2 message. Now when
    the MCM processed message arrives at the A1 mailbox, of course now it
    has to be _down_ converted to NBS V1. Herein lies the problem - what
    kind of algorithm is the transfer service supposed to use, such that 
    by looking at a bunch of flags for a bunch of recipients it can deduce
    that it shouldn't actually _action_ the perrecflg.confirm bits, but that
    the NBS down conversion should produce a VEND[CDELIV] to make IOS happy?
    
    Hence, there are limits... 
    
    	Dave
    
    PS  MCM has an undocumented switch to cause it to produce a VEND[CDELIV]
    if all the recipients in the message have the same specified perrecflg 
    bit setting, but whereas this _might_ solve your IOS problem, it might
    also cause problems going to other destinations - ie an untested feature.

    Dave,
    
    It seems these replies have got out of sync.
    
    Have you any comments on .12
    
    Can you give me some more info on the undocumented switch you hinted at
    in .13 so at least I can evaluate it.
    
    Thanks again.
    
    Glyn

    In case anyone is womdering .12 is a reply to an earlier version of .13
    A classic case of Notes collision.
    
    re: .12
    
    A similar, but of course differant, manifestation of the same problem.
    
    IOS produces a VEND[RRECPT] element - MRIF presents this as a bunch of
    Report Request elements. (Also note that differant versions of MRX have
    handled these IOS elements differantly.) What the various stages of up 
    conversion, down conversion, message processing, etc are doing here are,
    unfortunately, more that I have time to go into here.
    
    Suffice it to say (again) that you probably ought to seek another
    approach to your customer problem (at least until a PFR of IOS).
    
    	Dave

    Sorry to come back to this problem.
    
    I have done some more tests but this time just looking at Read
    Receipts.
    
    
    I have two VAX's, VAXA and VAXB.
    
    VAXA is a standard ALL-IN-1 IOS system
    VAXB is an MR/X gateway.
    
    At this stage, no other products are being used.
    
    Test 1
    ------
    
    On VAXA I use the ALL-IN-1 X400 form to address a message to an X.400
    user via the MR/X gateway on VAXB I also request a read request.
    
    Result 1
    --------
    
    When the message is read by the remote X.400 user, a read receipt is
    generated as expected.
    
    
    Test 2
    ------
    
    ALL-IN-1 is noe configured on VAXB and an ALL-IN-1 user created with an
    autofoward set to the X.400 user addressed in Test 1.
    
    On VAXA I address a message to the autoforward acount on VAXB
    
    Result 2
    --------
    
    When the remote X.400 user reads the message, no read receipt is
    generated.
    
    Test 3
    ------
    
    I modify the autofoward address of the ALL-IN-1 user created in Test 2
    so that messages are forwarded to an ALL-IN-1 user on another VAX, VAXC.
    
    A message is then sent to the autoforward account
    
    
    Result 3
    ----------
    
    When the ALL-IN-1 user on VAXC reads the message a read receipt is
    generated.
    
    Questions
    ---------
    
    1. Why do messages sent to an X.400 user via an ALL-IN-1 autofoward
    account loose the read receipt requests.
    
    2. Why should this be different from when a mail is autoforwarded to
    another ALL-IN-1 account.
    
    With regard to earlier reply's I can not see how the difference between
    V1 NBS and V2 NBS come into effect here as by my understabding in both
    tests 2 and 3 V1 NBS is being presented to the MR/X gateway.
    
    Regards,
    
    Glyn
    

    A couple questions:
    
    What version of MRX (in particular which S-kit)?
    
    Does the autoforward user address have an associated DDS entry?
    
    	Dave

    Dave,
    
    When i run MRXMAN it say's that:
    
    	'This is MRXMAN S2.2G005'
    
    The autoforward account does not have a DDS entry. The originating
    ALL-IN-1 account however does. This enables the originating user to be
    validated at the gateway.
    
    Regards,
    
    Glyn

    Create a valid DDS entry. You need an entry to allow MRX to lookup 
    and translate the P2 ORname(s) (which it does if they are 'plain' MR 
    address strings). If it can't translate a P2 orname, MRX will normally 
    just drop it. If it drops it, there is no place to store the X409 
    translation/expansion of the IOS RRECPT request, as it is an element
    associated with the P2 ORname.
    
    Dave

    BTW, your earlier comment about NBS V1 & NBS V2
    
    Keep in mind that MRX works at the V2 level, which means that TS has to
    do a V1->V2 up-conversion prior ro handing the message to MRX (which
    then has to do a NBS V2 -> X400'84 conversion, which is then passed to
    your Route400 'thing' and who knows what it does with it...)
    
    Dave

    Dave,
    
    I will try creating a DDS entry for the autoforward account.
    
    Should the DDS entry have a reverse lookup and if so, what should it
    be. ie: should it resolve to the autoforward accounts MHS address or
    thge originator's?
    
    Glyn

    Dave,
    
    I have tried what you suggested in .19.
    
    Created a DDS entry for the autoforward account with a reverse lookup
    resolving to the MHS address of the autoforward account.
    
    However a request for a read receipt stiil doesnt get thorugh to the
    remote X.400 UA.
    
    Re .20
    
    I understand what you are saying about the V1 and V2 MBS compatability.
    However I thought that the problems of loosing read/delivery receipt
    requests was when you whent through a V1 > V2 > V1 tyoe of translation.
    
    In the senario I am testing now  we only ever seem to be going through
    a V1 > V2 translation.(A1 > MR > A1 (autoforward) > MR > MRX). Also
    bear in mid that the A1 > MR > MRX route seems to work.
    
    Regards
    
    Glyn

    Well, at this point I would suggest you turn on NBS and X409 keep in
    MRX, and use MRXTBED to get dumps of both before and after. Verify that 
    the P2 recipient has the appropriate elements/flags present. Also,
    depending upon the way that the final destination does correlation, you 
    may have to insure that the P1 and P2 recipient ORnames are identical.
    
    Depending upon your further investigations and findings it may be
    appropriate to elevate this via the normal support channels. 
    
    	Dave

    Dave,
    
    I will try and get dumps of the mail messages.
    
    Would the setting of the /RECIP_PROC attribute within MR/X have any6
    affect on this
    
    regards,
    
    Glyn