Conference virke::mrmemo

    		Hi,
    
    I tried the last one, chancing the MHSMAILBOX to MEMO and addrpart to
    (sya,xlt). This resulted in a reverse lookup of
    	FKR1..AZ50368@meo@XLT.
    
    Strange enough was the first part not added in the reverse lookup,
    c.q. SYSA.
    It did not change the behaviour of MRMEMO, the same 
    %MRIF-W-INVSENDER, invalid sender message was reported back in the
    log file.
    I've appended the log file to this note, the nbs files are also
    availible.
    
    		thanks Rob.
    
    
    Time: 1992-01-30 16:59:15.08; message from server MRMEMO1:

%MRIF-W-INVSENDER, invalid sender
    
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, receiving from MEMO after data received from MEMO
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 13 36.', substates: 00000030
%TRACE-W-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

SRVLOG          SRV$LOG_HANDLER                  3943      000001C9  001E379D
----- above condition handler called with exception 0935E818:
%MRIF-W-INVSENDER, invalid sender
----- end of exception message
SRVMRC          SRV$MRC_POST                     4820      0000005E  001E7879
SRVACT          POST_MEMO                        4962      0000003B  001EB33B
SRVACT          SRV$ACT_R                        5290      00000210  001EB6FF
SRVDSP          SRV$DSP_FSM                      3423      000002A6  001E342A
SRVMMO          SRV$MMO_ONE_LIFE                 4376      000001EF  001E03BF
SRVMMO          SRV$MMO_MAIN                     4208      00000017  001E01C3
                                                           00239BAE  00239BAE
KOTERM          KOTERM                            804      00000039  002375A2
                                                           00239B89  00239B89
KODOC           KODOC                            1768      00000097  002347E4
                                                           00239B89  00239B89
                                                           0026513E  0026513E
ADA$ELAB_DDS    ADA$ELAB_DDS                               0000000E  001C0C0E
                                                           00239B89  00239B89

    Hello Rob,

.1> I've appended the log file to this note, the nbs files are also
.1> availible.

    The NBS files would be very valuable, so if you could post here, or
    send by mail, the MRNBSDMPs of the files or give a pointer to where
    the files can be fetched, I think we can work this problem out.

    I would also like to know exactly which DDS options are you using in
    MRMEMO (an MRMMan> LIST would be nice).

    Anders

    		Hi Anders,
    
    I've the envelope and the content nbs files which were left in the log
    file directory. You can find them at ijsapl""::.
    Please note that I copied the file through pathworks to diskettes and
    back. The contents is saved but is not reliable.
    
    What can be done to escalate the problem, I'v to get it work at 10-feb.
    Configuration is that all  validation is enabled. I saw in other notes
    that this should be working with the mrgate mailbox. Maybe DDS handles
    this one different then an 'entry' mailbox. So possibly replave the mbx
    mailbox with mrgate ?
    I really hate to propose this, but when it works,,,,,
    
    		regards Rob Eisink

.3> I've the envelope and the content nbs files which were left in the log
.3> file directory. You can find them at ijsapl""::.
.3> Please note that I copied the file through pathworks to diskettes and
.3> back. The contents is saved but is not reliable.

    Ok, I've got the files. It took me some time to get them into a format
    acceptable to MRNBSDMP. I think you should use NFT /BLOCK mode when
    copying the files from DOS to VMS.

    Anyway - the files look ok. That is - they correspond to your DDS
    entries. The route user@MEMO@MBX@node is, however, not acceptable to
    MRIF when a message is posted. MRIF wants the sender to have the
    route user@MEMO or user@MEMO@node.

    A way to get around this is to apply the attribute /IGNORE_SENDER to
    the MEMO mailbox (with MRMAN). But I strongly recommend you *not* to
    do this since you will disable the sanity check on the sender addresses,
    causing any erroneous routes in DDS to slip through. Replies and
    notifications could then end up in the wrong place.

.3> What can be done to escalate the problem, I'v to get it work at 10-feb.

    I guess the assets library in Turin is the place to turn to. I don't
    think this really is an MRMEMO problem. Any MRIF application will have
    this problem if you try to cheat by supplying a sender address that
    isn't correct because you want replies to take another route.
    Maybe you can get help in FORTY2::MAILBUS.

.3> Configuration is that all  validation is enabled. I saw in other notes
.3> that this should be working with the mrgate mailbox. Maybe DDS handles
.3> this one different then an 'entry' mailbox. So possibly replave the mbx
.3> mailbox with mrgate ?
.3> I really hate to propose this, but when it works,,,,,

    Yes - there is some builtin magic in DDS to handle the /VMSORADDRESS
    format and add 'MRGATE' to the route. Are you suggesting that you
    should use the MRGATE mailbox as your translation utility mailbox?
    I don't think that is wise - even if it should work.

    Now I have said "don't do this" and "don't do that" for a while. Don't
    I have any creative suggestions? Well, maybe one: I haven't tried this,
    but there is a small chance that a sender route looking like
    user@MEMO@node@MBX@node might work. This would make replies go to
    MBX@node and MRIF *might* be satisfied by the route starting with
    user@MEMO@node. I believe, however, that /IGNORE_SENDER is necessary
    to achieve what you want.

    Anders    

    		Hi,
    
    thanks for the reply. Today I went there.
    
    You was right that transfer service wanted the message posted from the
    mailbox the same as the from (sender) address.
    The /ignore_sender did not work. This because this qualifier should be
    used when the useragent is autoforwarding a message (such as all-in-1)
    I think they first implemented ALL-IN-1 and after that the updated
    mailbus. 
    When you use /ignore-message the auto-forwarding useragent is not
    allowed to have the same mailbox in its routing address. 
    That is what I read from the documentation (3.1 and 3.2).
    
    So after testing it still went wrong.
    
    At last I switched off the dds validation from MRMEMO. Messages showed
    up but because DDS lookups were not performed the FROM addres was 
    user@posted_mailbox@node_name. This resulted also in bab behaviour of
    delivery receipts and so on. I'll post a note about that but I think it
    is a ALL-IN-! MAIL feature (bug).
    
    After that I found the following solution :
    
    	Added an mailbus entry. like IBM4/replace=MEMO4@MBX
    
    	Changed the lookup of the memo user to FKR1.AV@IBM4@NODE
    
    	Added an reverse lookup (second or) for the sender
    		sender@memo4@mbx@node_name
    
    	Added the qualifier /ignore_sender to the memo4 mailbox.
    
    Because the memo4 mailboxname is not anymore in the from address
    (reverse lookup) for the specific IBM user the mailbox name where the
    message is posted does not occur in the sender address. This will
    result in a valid address.
    Replies (the from address) is the reverse lookup so replying to that
    message is no problem.
    Delivery AND read receipts are sent accros.
    
    	tommorow I'll test the rest but mine understanding is saying that
    this is a supported situtaion (workaround)
    
    I'll put a note with the results,
    
    		regards Rob