| Currently (MRMEMO V2.0, V2.0A), the DDS validation options requires that
DDS is populated.
o Sender validation (i.e. authorization) requires that the sender has a
DDS record.
o Recipient validation requires that the recipient has a DDS record.
The FROM address presented to MEMO users has so far always looked the same
regardless of DDS validations:
prefix.userid@mailbox@node
e.g.
VAX.JONES@MRGATE@BIGVAX
In MRMEMO V2.1 (currently in field test), there is a new option -
address translation - that will make use of DDS to translate MR sender
addresses that are presented to the MEMO recipients. The format of the
presented FROM address can be specified in several ways.
Address translation causes DDS lookups to be done on MR senders and MR
recipients. Address translation does, however, *not* require the DDS
records to be found (as for DDS validation). If an MR sender lookup
fails, the address will not be translated but presented to the MEMO user
in the "old" format (prefix.userid@mailbox@node). If an MR recipient
lookup fails, no address translation will take place, causing the
destination address to be passed directly to Message Router (in the same
way as when DDS is not used).
The DDS validation options are still available in V2.1 and can be used
in combination with address translation to enforce DDS population.
There is no translation of MEMO sender addresses going to MR. They look
like:
dgn.den@mrmemo_mailbox@mrmemo_server_node
Does this answer your question?
Anders
PS
.0> I've just finished reading the documentation and this PASS sounds
.0> very much like a product!
Thank you! Actually, it *is* a product in Sweden and Germany.
DS
|
|
Just to clarify one point (don't know if this is necessary):
If DDS validation is not enabled at all, then DDS need not be
populated, nor even configured as far as MRMEMO is concerned. The
addresses (TO and FROM) are derived directly from the information in
.NBS-files and the MEMO equivalent.
Stefan
|
|
I understood your explanation, and I did need the extra reply. However, I
still need some clarification. Sorry.
You pick the FROM address out of the NBS file. OK, so I sent it from MR and
my ALL-IN-1 userid is HARE_D. So I appear as VAX.HARE_D@A1@MEMVAX or similar in
the MEMO user's FROM field.
This implies to me that my mail alias in MEMOland has to be the same as my
username in ALL-IN-1. This is no problem, I suppose, unless MEMO imposes some
constraints on the length of the name or the characters that it can contain.
If VALIDATION is used, I assume I'd need a SN_USERNAME of HARE_D in DDS. In
other situations (e.g. MRS) the mail alias and the Digital userid are independent.
Please understand that I do not wish to appear critical - I'm just trying to
learn!
Thanks
David
P.S. Does the MEMO gateway work in a multi-node MEMO implementation, if this is
possible?
|
| .3> I understood your explanation, and I did need the extra reply. However, I
.3> still need some clarification. Sorry.
No need to be sorry. Other noters can also benefit from this discussion
and we (the developers) get valuable feedback about how the documentation
can be made more clear.
.3> You pick the FROM address out of the NBS file. OK, so I sent it from MR
.3> and my ALL-IN-1 userid is HARE_D. So I appear as VAX.HARE_D@A1@MEMVAX or
.3> similar in the MEMO user's FROM field.
Right
.3> This implies to me that my mail alias in MEMOland has to be the same as my
.3> username in ALL-IN-1. This is no problem, I suppose, unless MEMO imposes
.3> some constraints on the length of the name or the characters that it can
.3> contain.
MEMO user names have the form DG.memoid. This corresponds to a SNADS
Distribution User Name (DEN.DEN) and is limited to 8 + 8 characters.
How then can your MEMO name be VAX.HARE_D@A1@MEMVAX? Well, it can't! That
is, this non-MEMO name can not be registered in the MEMO system but it can
be used as a destination address if the MEMO system is configured to allow
it.
In MEMO there is something called a "complex name". A complex name is an
addressing prefix (in this case "VAX.") that tells MEMO to ignore the
syntax in the rest of the address string. In this way, it is possible to
send messages from MEMO to systems requiring strange (in MEMO's view)
syntaxes.
So, you don't have an alias in the MEMO system. MEMO will route anything
starting with "VAX." to the Distribution Port that has been associated
with "VAX.".
.3> If VALIDATION is used, I assume I'd need a SN_USERNAME of HARE_D in DDS.
.3> In other situations (e.g. MRS) the mail alias and the Digital userid are
.3> independent.
When MR Recipient Validation is used, there is a difference between how
MRMEMO V2.0 and later versions (currently only V2.0A) work.
In V2.0, it was required to have an SN_USERNAME that matched the userid
but that is no longer true (i.e. SN_USERNAME and user are independent).
This is described in the V2.0A Release Notes, section 2.1.2 (included
below). The complete V2.0A Release Notes can be found in Note 4.1.
.3> Please understand that I do not wish to appear critical - I'm just
.3> trying to learn!
I don't find you critical. And if I did - I wouldn't mind, so whatever
you find to be wrong/bad/annoying/missing/... in MRMEMO, don't hesitate
to tell us!
.3> Thanks
.3>
.3> David
.3>
.3> P.S. Does the MEMO gateway work in a multi-node MEMO implementation, if
.3> this is possible?
Yes, MRMEMO can be connected to a MEMO network. Within a MEMO network,
a MEMO address (DGN.DEN) is unique, so this is transparent to MRMEMO.
We did have some trouble communicating with more-than-one-hop-away MEMO
systems once (not related to addressing). I don't remember if the fix made
it into V2.0 or if it's in V2.0A. Digital's MEMO system (on the IBM in
Valbonne) is a single system so we can't test multi-node MEMO
configurations (but we support them :-).
Anders
----------------------------------------------------------------------
Section 2.1.2 from MRMEMO V2.0A Release Notes:
___________________________
2.1.2 MEMO replies failed when using recipient validation
When a mail is sent from the Message Router side
(e.g. ALL-IN-1) to MEMO, the MEMO user will see a
from-address looking like "VAX.USER@A1@A1NODE". When
MEMO to MR recipient validation is active, it is not
possible to reply to this address using MRMEMO V2.0.
MEMO returns "RECEIVER NOT FOUND".
This is not really an error but a consequence of how
MEMO to MR recipient validation was designed. The
DDS lookup is performed on "VAX.USER", searching for
a record with SNLOCATION = "VAX" and SNUSERNAME =
"USER". The effective destination address is then
taken from the (first) MHS address in the DDS record.
The route items "A1" and "A1NODE" are ignored.
The address lookup was originally designed this way
to simplify the parsing of a destination address by
making no difference beteween a pure "MEMO address",
i.e. an address like "VAX.USER" and an address like
"VAX.USER@MRGATE@NODE".
Since there seems to be a widespread confusion about
this lookup scheme, a design change in the the area of
MEMO to MR recipient validation has now been made.
In reality, there are two different kind of addressing
modes used in MEMO when specifying destination
addresses to MRMEMO:
1 The "MEMO style" DGN.DEN format (e.g. VAX.USER)
2 The "MHS style" PREFIX.USER..MAILBOX..NODE format
(e.g. VAX.USER..A1..A1NODE) or PREFIX.FREEFORM
(e.g. VAX.JOHN__ADAMS).
MRMEMO V2.0A (and future releases) now handles these
different kind of destination addresses differently.
The "MEMO style" addresses are handled as before,
doing DDS lookup on SNLOCATION = DGN and SNUSERNAME
= DEN. This addressing format requires MEMO to MR
recipient validation to be active.
The "MHS style" address format is a Message Router
address with a prefix and is treated as such, doing
a DDS lookup on the reverse address USER@MAILBOX@NODE
instead of on the SN items. The freeform format is
also regarded as an MHS address. That is, in the
following two cases is the destination address treated
as an MHS address:
o There is any route element present (e.g. "..MRGATE"
or "ROUTE=NODEA")
o The item immediately after the prefix is a freeform
name (e.g. VAX.JOHN__ADAMS)
In this way, MR to MEMO recipient validation acts more
as a pure validation and the effective destination
address will not depend on whether validation is
active or not.
|