| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 165.1 | Really? | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Fri Feb 26 1993 18:22 | 81 |
| .0> A customer here in Belguim has installed the patch for Binaries
.0> (5.28?).
Patch 5.21, I assume.
.0> Unfortunatly this means that read receipt correlation no
.0> longer works on ALL-IN-1 Mail. If he replaces the excecutable with a
.0> backup from before the patch was applied, the cirrelation works.
This sounds very strange. I assume you mean that a message is sent from
ALL-IN-1 MAIL to MEMO and when the MEMO user reads the message,
the notitification sent back to ALL-IN-1 MAIL is received as a separate
message instead of correlating to the original message's header.
.0> After the patch is applied the reciept notificartion comes back as a
.0> message with a line;
.0>
.0> (*MRMRLP=1)
.0>
.0> under the recipients name.
The "(*MRMRLP=1)" is normal - this is how ALL-IN-1 MAIL displays
DDAs (Domain Defined Attributes) present in the receipt notification.
.0> Is their a patch or a workaround available for this problem?
No - this is an unknown problem.
Are you absolutely sure that there is a difference between how the
patched and unpatched version of the MRMEMO server behaves? Receipt
notifications can easily fail to correlate if the following rules are
not obeyed.
From note 52.1:
Receipt notifications returned from MEMO correlates to the ALL-IN-1
MAIL sender's distribution list only if all the following conditions
are true:
o The ALL-IN-1 MAIL user requests a receipt notification
(RECEIPT_NOTIFICATION=FULL)
o The CORRELATE options is set in the ALL-IN-1 MAIL users's profile
o The address sent to by the ALL-IN-1 MAIL user is the "raw" MHS
address (dgn.den@mbx@node). If any other format is used, the
correlation will not work and the ALL-IN-1 MAIL user will receive
a notification in the form of a text message. This restriction
is more permanent than the problem with delivery notifications.
It will probably not work properly until we can exchange real X.400
addressing information with MEMO.
It's the last of the bullets above that I think might be the culprit.
How extensive tests were done before the patched MRMEMO was judged
erroneous? If, for example, the destination address used is dga.den@memo
instead of dga.den@memo@node, the correlation will not work since
the address reported back will be dga.den@memo@node and ALL-IN-1 MAIL
doesn't think that dga.den@memo correlates to dga.den@memo@node.
Make sure that *exactly* the same destination address is used when
comparing the patched and unpatched MRMEMOs.
If there, after all, really is a problem with the patched version, I
need some more information to guess what's happening since I can't
reproduce this. I need the NBS files from a message with the unpatched
version and then from a message sent with the patched server.
The NBS files are:
MRMEMO$DIR:MRMEMOn-ENVELOPE.NBS
CONTENTS.NBS
RNOTENV.NBS
RNOTCNT.NBS
RNOTENV.NBS and RNOTCNT.NBS are most important since they contain the
receipt notification.
Also, are there any other patches installed? The "Patch Information"
part from ANALYZE/IMAGE on MRMSRV.EXE (patched and unpatched) would be
of interest.
Anders
|
| 165.2 | You were right! | BACHUS::WOOD | I couldn't resist the fish! | Mon Mar 08 1993 14:14 | 22 |
| Hi Anders,
> Patch 5.21, I assume.
>
> o The address sent to by the ALL-IN-1 MAIL user is the "raw" MHS
> address (dgn.den@mbx@node). If any other format is used, the
> correlation will not work and the ALL-IN-1 MAIL user will receive
> a notification in the form of a text message. This restriction
> is more permanent than the problem with delivery notifications.
> It will probably not work properly until we can exchange real X.400
> addressing information with MEMO.
The customer has just got back to me, and yes, this was the problem. Thanks
for your help.
Cheers,
Andy
|
| 165.3 | problems the other way | YUPPY::CARTER | Windows on the world... | Fri Mar 12 1993 12:13 | 19 |
| Hi
We are also having problems with notification. We have a TEAMLINKS
(ALL-IN-1 Mail Server) system.
The problem is at the MEMO end. If a memo user send a message to one
receipient they get no notification that the recipient has read the
message, however if they send to N recipients that they get
notification on N-1 of the recipients.
We haven't done exhaustive testing but it appears that its the last
recipient for whom the reciept is not received.
We are running the Volkswagen Audi system.
Regards
Christine
|
| 165.4 | About those receipt notifications | KETJE::VANHOOSTE | Guide to Shadowland | Sun Mar 14 1993 19:54 | 33 |
| Coming back to the original point, and looking at the MRIF guide, a
question pops up.
In MRIF it is implied that the recipient address should be in a content
form, not in an envelope form. That is, if we send to
Marc VanHooste @BRO
and BRO has a /REPLACE="", and "Marc VanHooste" has a replace of
"DGN.DEN@MEMO@NODEA",
then it looks to me that a receipt notification should contain "Marc
VanHooste @BRO", not the raw address. Which is logical, because receipt
notifications have to do with the UA, just like Content recipients.
This would solve all problems I guess, save perhaps two. It could only
be done if
1) MRMEMO uses content based recipients to send back in rec. not.
2) To be able to have 1, there must be a way to correlate the
envelope recipients with the content ones. To be able to send
back the content one. And all products normally make sure the
nr of recipients in an envelope = the nr of recipients in the
content, save ... DEC MAILworks ...
Any ideas on this ?
It IS disturbing since (extrapolating) in the real world there ARE
/REPLACE strings used (IS, customers doing it to actively hide the
physical MR machine for disaster recovery etc).
And of course DMW *IS* bought because of it's correlation feature
instead of the competition (believe it or not).
Marc VH.
|
| 165.5 | But all MRMEMO knows is DGN.DEN | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Mon Mar 15 1993 14:35 | 26 |
|
.4> In MRIF it is implied that the recipient address should be in a content
.4> form, not in an envelope form. That is, if we send to
.4>
.4> Marc VanHooste @BRO
.4>
.4> and BRO has a /REPLACE="", and "Marc VanHooste" has a replace of
.4> "DGN.DEN@MEMO@NODEA",
.4>
.4> then it looks to me that a receipt notification should contain "Marc
.4> VanHooste @BRO", not the raw address. Which is logical, because receipt
.4> notifications have to do with the UA, just like Content recipients.
Yes, it would be logical for the receipt notification to contain "Marc
VanHooste @BRO". Implementing it is however not that easy. When the
MEMO user reads the message, MEMO sends out a status message to the
original sender, containing information about the fact that DGN.DEN
has read the message. So... DGN.DEN is all MRMEMO knows about the
MEMO user. To make it work a little better, MRMEMO appends '@mbx@node'
but that's all.
MRMEMO does not know that the original address was "Marc VanHooste @BRO".
Maybe some solution where DDS is used could be designed but that's not
a minor task.
Anders
|
| 165.6 | I see ... | KETJE::VANHOOSTE | Guide to Shadowland | Mon Mar 15 1993 22:14 | 18 |
| Yes, that's what I mean : normally speaking one would find in DDS
(using DGN/DEN as key) "Marc VanHooste @BRO", thereby making exact
correlation possible.
What you are saying is that MRMEMO doesn't work that way.
Hm. What this particular customer seems to want is to use something
like MEMOGATE/REPLACE="MEMO@NODEA" . In case NODEA goes down, he can
then switch to a backup node and with a simple /REPLACE= modification
reroute his mail to MEMO.
So if he chooses his mailbox cleverly, the only term in difference
would be the nodename of the node where the MEMO gateway is installed.
Perhaps we might pursuade the DMW folks to strip off routing terms in
case an exact match is not found. That would solve this problem. Or is
there a way to keep MRMEMO from adding the node to the rec. notif ?
Marc VH.
|