[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference virke::mrmemo

Title:VAX MAILGATE for MEMO
Moderator:STKHLM::OLSSON
Created:Sat Feb 25 1989
Last Modified:Tue May 14 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:216
Total number of notes:933

192.0. "Automatic forwarding and DDS lookup ?" by HAN::FISCHER_HE () Mon Nov 22 1993 19:47

    
    
    Hi,
    
    we had a long time the MRMEMO servers running with
    complex names handling. We changed to 8.8 addressing
    and had no problems until some users who had accounts
    in A1 and MEMO used there new MEMO address for 
    automatic forwarding from A1 to MEMO. 
    The sender of a MEMO Mail which is forwarded through A1 
    to another MEMO account  gets an strange (variant) error 
    status. 
    Setting the old address (the old servers -complex names- 
    are still running) the mail gets forwarded.
    Seems to be an DDS lookup problem with the 8.8 server
    for such account which are held with two mailboxes
    in DDS (same SNUSER, different SNLOCATION).
    How is the DDS lookup done for outgoing mail recipients
    in case automatic forwarding (sender validation is 
    switched off).
    Thanks
    Heinz Fischer
T.RTitleUserPersonal
Name
DateLines
192.1Forwarded address lookup known problem (see release notes)STKOFF::SPERSSONPas de problemeThu Nov 25 1993 17:5857
    
    Hi,
    
    Apologies for the delay, out at customers' sites as usual.
    
    There are known problems with autoforwarded sender authorization: this
    is from the V2.1 Release Notes: (since you have a custmized MRMEMO
    version they may have been overwritten. The regular variant can be
    found in STKOFF::MRMEMO$PUBLIC:[V021.SDC]MRMEMO021.RELEASE_NOTES)
    
    --------------------------------------------------------------------------
    7.5  Sender authorization on autoforwarded messages

             If the sender authorization option is enabled in the MR to
             MEMO direction, (i.e. if the MRMMAN command DEFINE/DDS=SENDER=MR
             has been issued) and an autoforwarded message is received by
             the server (e.g. from a VMSmail user who has "SET FORWARD" to
             a MEMO address), the DDS validation on the sender will fail.

             This is because the Reverse lookup DDS attribute is used
             for validating the sender address of the message, but this
             address contains a mixture of the original sender and the
             autoforwarding sender address.
    --------------------------------------------------------------------------
    
    A possible fix is to define the actual Reverse_lookup in DDS. Assuming
    the MEMO user is already defined in DDS define a secondary lookup
    something like this:
    
    mhsaddr=(addr=<a1-node>,mhsm=a1,-
    mhsu="<mrmemo-prefix>.<memo-address>@<mrmemo-node>")
    
    I'm not really sure of the above, but it looks reasonable.
    
    Even so I don't quite follow the problem statement. Could you
    please explain a couple of things:
    
>    we had a long time the MRMEMO servers running with
>    complex names handling. We changed to 8.8 addressing
>    and had no problems until some users who had accounts
>    in A1 and MEMO used there new MEMO address for 
>    automatic forwarding from A1 to MEMO. 
>    The sender of a MEMO Mail which is forwarded through A1 
>    to another MEMO account  gets an strange (variant) error 
>    status. 
    
    - where did you get this error (MRMEMOn.LOG ?), and what is the exact
    error message?
    
    - does "change to 8.8 addressing" also mean that you have modified the
    MRMMAN definitions (this is the only way MRMEMO would have changed its
    behaviour. MRMEMO knows nothing about whether complex adressing, a MEMO
    feature, is enabled or not)
    
    cheers,
    
    	Stefan
192.2DDS settings changedHAN::FISCHER_HEMon Nov 29 1993 14:0311
    
    
    Hi,
    
    It's a long time ago since we ensured 8.8 address handling.
    And I was not sure if server settings were relevant in 
    that functional change. But as you said it is only the
    switching to DDS usage we did in the server configuration.
    We will try the workaround.
    Thanks
    Heinz Fischer