| 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 |
We have a problem when sending from MEMO to X.400 using DDAs in the address. Partially this might be a MRX problem, but the sending (with the DDS subscriber below) works for * ALL * other UAs and gateways. The problem is caused by the use of DDAs of the memo gateway (other gateways make only use of INTDDAs). We try to send to an Form 1.3 address with DDAs. When MRX receives the NBS file the it will find DDAs as well in the SAs and the ROUTE/USERID. Therefore MRX rejects the message. I didn't test it with Form 1.1 addressing but the problem might be the same. Regards, Rainer =============================================================================== Organizational unit : VUSCLU Given name : Fax Surname : Digital Name : Fax Digital Reverse lookup : 1=DE@2=EMSA1@11=008932492525@*SERVICE\FAX@MTA_CLU@REFVUS MR S location : A1ATCB13 MR S user name : FAXMFR MR P user name : FAXMFR MR P location : GYVUS Master copy owning node : REFVUS MHS/VMS address number : 1 MHS/VMS address part : REFVUS MHS mailbox : MTA_CLU MHS User identifier : 1=DE@2=EMSA1@11=008932492525@*SERVICE\FAX ============================================================================= 28JAN91 11:36:18.90 E032 1_REFVUS_0000277F %MRX-I-RTSMRFETC, has fetched from message router mailbox MTA_CLU into file DISK$USER:[MB$.MRX]483.NBS 28JAN91 11:36:19.06 E032 1_REFVUS_0000277F %MRX-I-STAMSGTRN, Started message translation 28JAN91 11:36:20.86 E032 1_REFVUS_0000277F %MRX-W-WASPRESENT, Node to be inserted in tree is already present 28JAN91 11:36:20.96 E032 1_REFVUS_0000277F -MRX-I-STATEIS, Parser state is DOMAINDEFINEDATTRIBUTELIST 28JAN91 11:36:21.06 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is DOMAINDEFINEDATTRIBUTELIST 28JAN91 11:36:21.16 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is DOMDEF 28JAN91 11:36:21.27 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is DOMDEFINED 28JAN91 11:36:21.37 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is MRDDATTRIBUTELIST 28JAN91 11:36:21.48 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is RECIPIENTINFO2 28JAN91 11:36:21.60 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is RECIPIENTINFO 28JAN91 11:36:21.70 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is RECIPIENTITEM 28JAN91 11:36:21.81 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is USERMPDU 28JAN91 11:36:21.91 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is USERMPDU 28JAN91 11:36:22.02 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is USERMPDU 28JAN91 11:36:22.12 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is MPDU 28JAN91 11:36:22.28 E032 1_REFVUS_0000277F %MRX-I-STATEIS, Parser state is MPDU 28JAN91 11:36:22.74 E032 1_REFVUS_0000277F %MRX-I-STANDNGEN, Started non-delivery notification generation
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 68.1 | Try undocumented switch | STKOFF::SPERSSON | Pas de Probleme | Tue Jan 29 1991 11:47 | 31 |
Rainer,
I don't know if this will help but there is an undocumented way of turning
off the generation of DDA:s. This however will affect the way MRMEMO
can map notification messages to the original.
You enable this server switch as follows:
MRMMAN> DEFINE/NODOMAIN_DEFINED_ATTRIBUTES
To disable it, obviously:
MRMMAN> DEFINE/DOMAIN_DEFINED_ATTRIBUTES
When /NODOMAIN is set then a LIST command will generate:
MRMMAN> LIST
.
.
.
Send Notifications: Enabled
Domain Defined Attr: Disabled
Cluster alias address: Disabled
.
.
.
When /DOMAIN is set the "Domain Defined Attr:" will be ommitted by LIST
Stefan
| |||||
| 68.2 | Be careful | STKOFF::SPERSSON | Pas de Probleme | Tue Jan 29 1991 14:46 | 25 |
Oh by the way,
If I remember correctly, when we designed V2.1 we did have a look at
Internal DDA:s, but we decided not to use them because they were *not*
relayed through our X.400 connection. I don't remember whether this was
a restriction on MRX or the particular ADMD (MAILnet in Finland) that
we connected to. Nor have I any idea what the protocol says.
We do want the DDA:s to relay through X.400, the reason why we put
them there in the first place was that MRX has a bug in it, they'll
crash on Extensionid in outgoing delivery reports. Extensionid maps to
MEMO's Receiver List position. Because of this MRX bug, we switched to
DDA "MRMRLP" to map to this item.
Now, as I said in .1 you can switch off the DDA:s, but this means you
run the risk of losing delivery notification functionality (ie mapping
the original MEMO to the reported recipient), not only over X.400, but
I'm afraid throughout the MR network. It's not so bad if the MEMO only
contains one recipient, but distribution lists may mess things up, to
the degree where the wrong recipient is reported as having received the
message.
Stefan
| |||||
| 68.3 | I can't see a solution | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Wed Jan 30 1991 10:21 | 26 |
Hi Stefan,
we used the addressing scheme in .0 in a test environment and we did
change our software. So in our case we had a 'workarround'. Your
suggestion would have been worked too (with all the disadvantages
described in your replies). I think this is more or less an MRX
problem and I did QAR this problem. The following situation should give
an example:
From MR/S or MR/P to DDS-registered X.400 Form 1.3 recipients with DDS
attributes like
COUNTRY, ADMD, Surname, Givenname, X121address, DDA and
Reverse_lookup = 1=country@2=admd@11=x121address@*DDA@mbx@node
will fail too (because the gateways put the X.400 relevant attributes
into the SA fields and into USERID/ROUTE). Here MRX could either use
the SAs or the USERID/ROUTE informations because they are the same but
fails with 'node to be inserted already in tree'.
This is different for MR/MEMO because the MRMddas are dynamic and
therefore cannot be registered in DDS.
I have no idea how to solve the problem.
Rainer
| |||||