| 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 |
Those of you who have tried to use MRMEMO V2.0 in connection with MRX
have noticed some difficulties. We are currently in the process
of trying to provide fixes/workarounds to make interoperability
between these products possible. I would like to use this note to
gather opinions on whether you think we're on the right track. Please
feel free to comment on anything that is written below.
The main problems are threefold:
1) MRX V2.0 (later versions not tested) will crash when it tries to
issue a delivery notification or non-delivery notification on a message
that was sent from MEMO. The reason for this is, as far as we've been
able to confirm through tests, that messages issued by MRMEMO always
contain the NBS Date attribute DEFERRED. This should be perfectly legal
but MRX crashes with MRX-E-INVHERE. It's obviously an MRX bug but
nevertheless we've seen the need to provide the simple fix of not
including the DEFERRED attribute in any message. This attribute
is not, as far as I know, honoured by any of our "strategic office
applications" anyway. The meaning of it is "don't deliver this message
until this date and time"
2) MRMEMO V2.0 translates this address provided by a MEMO user (DDS
validation not enabled):
VAX.John__Smith..PR=DIGITAL..ORGUNIT=SWAS..MRX
into this NBS ORADDRESS format:
TO:
PRDNAME: DIGITAL
ORGUNIT: SWAS
ROUTE: MRX
USERID: Jonh Smith
This causes all sorts of silly situations because of the way MRX
handles the NBS file. We propose to provide the fix of instead
translating the address into:
TO:
ROUTE: MRX
ROUTE: PR=DIGITAL
ROUTE: ORGUNIT=SWAS
USERID: Jonh Smith
This is what MRX expects, because this is what it gets from MRGATE
and ALL-IN-1
3) When recipient validation is enabled in direction MEMO->MR the
DDS record (if found) is translated into NBS ORADDRESS as this example
shows:
============================================================================
DDS record:
PRDM: DIGITAL
ORGUNIT: SWAS
MHSORADDRESS:
ADDRPART: VAX1
MHSMBX: MRX
MHSUSERID: JOHN SMITH
Translates to ->
NBS ORADDRESS:
TO:
PRDNAME: DIGITAL
ORGUNIT: SWAS
ROUTE: VAX1
ROUTE: MRX
USERID: Jonh Smith
============================================================================
This will cause the same silly situations as are hinted at under 2).
There are two ways to specify valid DDS records that will be translated
to proper MRX type OR-addresses
Either ->
============================================================================
DDS record:
PRDM: DIGITAL
ORGUNIT: SWAS
MHSORADDRESS:
ADDRPART: VAX1
ADDRPART: MRX
ADDRPART: PR=DIGITAL
MHSMBX: ORGUNIT=SWAS
MHSUSERID: JOHN SMITH
Translates to ->
NBS ORADDRESS:
TO:
PRDNAME: DIGITAL
ORGUNIT: SWAS
ROUTE: VAX1
ROUTE: MRX
ROUTE: PR=DIGITAL
ROUTE: ORGUNIT=SWAS
USERID: Jonh Smith
============================================================================
Or ->
============================================================================
DDS record:
PRDM: DIGITAL
ORGUNIT: SWAS
MHSORADDRESS:
ADDRPART: VAX1
MHSMBX: MRX
MHSUSERID: JOHN SMITH @PR=DIGITAL @ORGUNIT=SWAS
Translates to ->
NBS ORADDRESS:
TO:
PRDNAME: DIGITAL
ORGUNIT: SWAS
ROUTE: VAX1
ROUTE: MRX
USERID: JOHN SMITH @PR=DIGITAL @ORGUNIT=SWAS
============================================================================
No particular fix is needed for this as far as MRMEMO code is concerned,
but rather to understand how MRMEMO uses DDS and MRIF under these
circumstances.
Finally, if you feel you or your customers need the fixes as described
above, please contact the MRMEMO product manager Jan Plars@SOO, and he will
be able to tell you how to get hold of them.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 15.1 | Small comment | KETJE::VANHOOSTE | Guide to Shadowland | Thu Oct 12 1989 14:52 | 8 |
>> contain the NBS Date attribute DEFERRED. This should be perfectly legal
>> but MRX crashes with MRX-E-INVHERE. It's obviously an MRX bug but
I would try it out with MRX V2.1 just in case.
In any case, if you want to have any hope for MRX V2.2, you'll have to
do it.
Marc VH.
| |||||
| 15.2 | How does the fix look like | MUNICH::ROSENBERGER | Rainer Rosenberger @MUH, TSSC-OIS | Thu Oct 12 1989 15:57 | 22 |
Hi Stefan,
in .0 you mentioned that you'll provide a 'fix'. How will this fix look
like ? I gues you'll translate
DEC.givenname__surname..PR=DIGITAL..ORGUN=ENG..MRX..GWYNOD
to NBS
GIVEN: givenname
SURNAME: surname
PRMD: DIGITAL
ORGUNIT: ENG
USERID: MRX
ROUTE: GWYNOD
is this correct ?
Rainer
| |||||
| 15.3 | This is how | STKOFF::SPERSSON | Pas de Probleme | Wed Oct 18 1989 10:53 | 29 |
Rainer,
Sorry for not replying earlier, as Anders mentions elsewhere in this
conference we have had problems with our development environment that
have prevented proper testing.
The 'fix' I'm talking about will be provided as a special version,
V2.0A, which will be available *at request*, at least here in Sweden. I
cannot speak for the rest of the world, the product manager will
probably kill me for revealing this much :-).
The address translation outlined in .2 is not entirely correct. This
is what it will look like in V2.0A:
========================================================================
DEC.givenname__surname..PR=DIGITAL..ORGUN=ENG..MRX..GWYNOD
translates to NBS ->
ROUTE: GWYNOD
ROUTE: MRX
ROUTE: PR=DIGITAL
ROUTE: ORGUN=ENG
USERID: givenname surname
Stefan
| |||||
| 15.4 | good news | MUNICH::ROSENBERGER | Rainer Rosenberger @MUH, TSSC-OIS | Wed Oct 18 1989 12:14 | 12 |
Hi Stefan,
that's exactly what I did hope. So also an ALL-IN-1 CC is able to reply
to ALL recipients.
Regards,
Rainer
| |||||
| 15.5 | MR-MEMO, MRX and M400 | 48392::BONNAVAUD | Phil. Bonnavaud. SWAS Nice | Thu Oct 19 1989 17:59 | 18 |
We are at the S.I.T.A. using 2 VAX's, the first one running VMS,
VMS-SNA, ALL-IN-1, MRX400, MR-MEMO, MR-P, MR-S, the second one running
ULTRIX with M400 as Electronic Mail.
Exchanging mails between ALL-IN-1 and M400 or M400 and ALL-IN-1
is OK.
Exchanging mails between MEMO on the I.B.M. and ALL-IN-1 or ALL-IN-1
and MEMO is OK.
Exchanging mails from M400 on a VAX running ULTRIX and MEMO on
the I.B.M. via MRX400 is OK. I've got a problem transmitting a mail
from MEMO on the I.B.M. and M400 on ULTRIX, in this case M400 rejects
the message, with illegal recipient name.
I run MR-MEMO V2.0.
If someone of you has any experience of this type of configuration,
it will be very helpful for me.
Thank's for any help,
Regards
Philippe.
| |||||
| 15.6 | Wait for V2.0A | STKOFF::SPERSSON | Pas de Probleme | Mon Oct 23 1989 11:27 | 12 |
> I've got a problem transmitting a mail
> from MEMO on the I.B.M. and M400 on ULTRIX, in this case M400 rejects
> the message, with illegal recipient name.
I think this might be caused by the current behaviour of MRMEMO address
translation, as described in the base note. Please stay tuned for
information on how to obtain the "fix" version, 2.0A
Stefan
| |||||
| 15.7 | Have fun with V2.0A | NCESW1::BONNAVAUD | Phil. Bonnavaud. SWAS Nice | Mon Nov 13 1989 11:04 | 4 |
With the new version of MRMEMO V2.0A, the problem I've specified
is resolved.
Many thanks for your help.
Philippe.
| |||||
| 15.8 | Soon here | STKOFF::SPERSSON | Pas de Probleme | Mon Nov 13 1989 15:58 | 3 |
Let me point out that Philippe was given a "Field Test" version of V2.0A
It's not yet publicly available, but hopefully will be very soon.
| |||||