|
30-Nov-1989
VAX MAILGATE for MEMO Version 2.0A
Release Notes
This document contains release notes for V2.0A of VAX
Mailgate for MEMO.
________________________
November 1989
__________
The information in this document is subject to change
without notice and should not be construed as a
commitment by Digital Equipment AB. Digital Equipment
AB assumes no responsibility for any errors that may
appear in this document.
The software described in this document is furnished
under a license and may be used or copied only in
accordance with the terms of such license.
No responsibility is assumed for the use or
reliability of software on equipment that is not
supplied by Digital Equipment AB or its affiliated
companies.
__________
Copyright �1989 by Digital Equipment AB
All Rights Reserved.
Printed in Sweden.
__________
The following are trademarks of Verimation AB:
MEMO SESAM
The following are trademarks of International Business
Machines Corporation:
IBM MVS/XA SNA
MVS VTAM
The following are trademarks of Digital Equipment
Corporation:
ALL-IN-1 MAILBUS ULTRIX
DEC MASSBUS UNIBUS
DECmate Message VAX
Router
DECnet MicroPDP VAXmate
DECset MicroVAX VAX P.S.I.
DECstart MicroVMS VAX P.S.I. ACCESS
DECUS MRX VMS
DECsystem-10 OSAK VOTS
DECSYSTEM-20 PDP WPS-8
DECwriter Q-BUS WPS-PLUS
DIBOL Rainbow
DNA RSTS
LQP RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version
1.2
_______________________________________________________
Contents
_______________________________________________________
CHAPTER 1 INTRODUCTION 1-1
_______________________________________________________
CHAPTER 2 NEW FEATURES AND CHANGES 2-1
_________________________________________________
2.1 FIXED BUGS 2-1
2.1.1 Attached documents were
indented too much _____________ 2-1
2.1.2 MEMO replies failed when using
recipient validation __________ 2-1
2.1.3 Long subjects no longer crashes
MRMEMO ________________________ 2-3
2.1.4 An MRMMAN user can be suspected
as network intruder ___________ 2-3
2.1.5 ORGUNIT and DDS validation no
longer crashes MRMEMO _________ 2-4
2.1.6 The tag "4=" is now
recognized ____________________ 2-4
2.1.7 %MRX-E-INVHERE on
DEFERREDDELIVERY no
longer occurs _________________ 2-5
2.1.8 MRX requires special addressing
format ________________________ 2-5
2.1.9 Non-delivery notifications
for large mails are now more
informative ___________________ 2-5
2.1.10 Delivery notifications from
MEMO didn't get through to MR _ 2-6
2.1.11 NBS contents file is no longer
left open _____________________ 2-6
iii
Contents
2.1.12 Delivery notifications to
ALL-IN-1 now contain subject __ 2-6
2.1.13 Delivery notifications and MEMO
distribution lists ____________ 2-7
2.1.14 ALL-IN-1 users can now reply to
local MEMO recipients _________ 2-7
2.1.15 Replacement character strings
no longer left in USERID ______ 2-8
_______________________________________________________
CHAPTER 3 KNOWN PROBLEMS 3-1
_________________________________________________
3.1 PROBLEM REPORTS 3-1
_________________________________________________
3.2 THE SERVER 3-1
3.2.1 First reverse lookup address is
always used ___________________ 3-1
3.2.2 Sender authorization on
autoforwarded messages ________ 3-2
3.2.3 Maximum Message Size __________ 3-2
3.2.4 Non-delivery notifications with
original messages missing _____ 3-3
3.2.5 Delivery notifications over
X.400 (MRX) doesn't work ______ 3-3
3.2.6 Authorization error and MEMO
distribution lists ____________ 3-3
_______________________________________________________
CHAPTER 4 KNOWN RESTRICTIONS 4-1
_________________________________________________
4.1 NOTIFY FUNCTION IN MEMO 4-1
iv
Contents
_________________________________________________
4.2 SERVICE MESSAGES ARE LANGUAGE
DEPENDENT 4-1
_________________________________________________
4.3 USE OF MRMAN'S READ COMMAND NOT
POSSIBLE ON MRMEMO MESSAGES 4-1
_________________________________________________
4.4 TAG ADDRESSES IN DIRECTION MR -
MEMO WITH DDS LOOKUPS DISABLED 4-2
_________________________________________________
4.5 MRX HAS PROBLEMS WITH MRMEMO
NON-DELIVERY NOTIFICATIONS 4-3
v
_______________________________________________________
1 Introduction
Version V2.0A of VAX Mailgate for MEMO is an
intermediate patch release that includes fixes to some
of the problems discovered in V2.0.
1-1
_______________________________________________________
2 New features and changes
__________________________________________________________________
2.1 Fixed bugs
___________________________
2.1.1 Attached documents were indented too much
When a message containing an attached document is
sent from e.g. ALL-IN-1 through MRMEMO, the attached
document is indented so much (12 positions) that the
text will be awkward to read in MEMO.
In V2.0A, message text is never indented, regardless
of attachment nesting level.
___________________________
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.
2-1
New features and changes
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)
2-2
New features and changes
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.
___________________________
2.1.3 Long subjects no longer crashes MRMEMO
When a mail with a subject longer than 40 characters
is sent to MEMO from VMSmail and the server
characteristic "/TIMESTAMP" is active, MRMEMO V2.0
could crash.
When "/TIMESTAMP" is active, a line containing
"Ident:" followed by the VMSmail subject in
hexadecimal notation is inserted in the beginning of
the MEMO text. When the internal hex conversion buffer
overflows, MRMEMO data structures are destroyed and
can cause a crash.
This has been fixed in V2.0A by truncating the maximum
length of the hex Ident string to 80 characters.
___________________________
2.1.4 An MRMMAN user can be suspected as network intruder
During startup of a MRMEMO server and by using the
MRMMAN command SHOW when the destination server is not
active, the MRMMAN user can be logged as an intruder
in VMS.
This happens because MRMMAN tries to connect to
the MRMEMO server using object name addressing
(NODE::"0=MRMEMOn"). If the server is starting and
has not yet declared itself as a network object, the
connect attempt will fail and cause VMS to detect the
memo manager as an intruder. If there are too many
failures, the "intruding" user will be denied further
access.
2-3
New features and changes
There is no easy fix to this problem but to reduce
the problems, the polling interval has been increased
in V2.0A and the maximum number of polls has been
decreased. This will not eliminate the problem
but make it less likely to reach the VMS intruder
threshold.
A better solution will be implemented in a future
release.
___________________________
2.1.5 ORGUNIT and DDS validation no longer crashes MRMEMO
The tag "ORGUNIT=" is different from most other DDS
attributes in that it can occur more than once in a
DDS record. ORGUNIT is not properly handled in MRMEMO
V2.0 when DDS lookups are enabled.
When sending from X.400 to MRMEMO, there are often
ORGUNIT element(s) present, making this problem
particularly apparent when using X.400.
V2.0A will not crash when "ORGUNIT=" is used in
combination with DDS validation.
___________________________
2.1.6 The tag "4=" is now recognized
The numeric equivalent for the tag "ORGUNIT=" is "4=".
MRMEMO V2.0 does however not recognize "4=". When "4="
occurs in a address string, a traceback is generated
and the rest of the address string is ignored.
This causes problems when sending from X.400 to MRMEMO
since messages coming from X.400 often contains "4="-
elements.
V2.0A recognizes "4=" as a synonym for "ORGUNIT=".
2-4
New features and changes
___________________________
2.1.7 %MRX-E-INVHERE on DEFERREDDELIVERY no longer occurs
When a message is sent from MEMO through MRMEMO to MRX
and MRX tries to generate a non-delivery notification,
MRX previously could fail with the error message'%MRX-
E-INVHERE' in parser state 'DEFERREDDELIVERY'.
MRX doesn't seem to like the NBS item deferred date
that MRMEMO sends out. To avoid this problem, MRMEMO
V2.0A doesn't send out any deferred date.
___________________________
2.1.8 MRX requires special addressing format
MRX is not satisfied with getting e.g. SURNAME in the
NBS element SURNAME. It wants it in a ROUTE element
on the form "SURNAME=surname". The same goes for all
other attributes.
MRMEMO V2.0 does not create these route elements, but
puts them in the "real" NBS elements SURNAME etc.
When DDS MEMO to MR recipient validation is
used, the X.400 address can be put in DDS.
(MHSADDR=MRXNODE, MHSMAILBOX=MRX, MHSUSER=nisse
user@CO=coutry@PR=private@whatever).
When DDS is not used, MRMEMO V2.0A now puts all tagged
attributes in the route elements to make sending to
through MRX work.
___________________________
2.1.9 Non-delivery notifications for large mails are now
more informative
When a too large mail is sent to MEMO, a non-delivery
notification comes back throught MRMEMO V2.0 with
no information about who it was sent to or what the
subject was.
2-5
New features and changes
In MRMEMO V2.0A, the UACONTID field displayed in the
non-delivery notification message will contain the
subject. This will make it possible to identify the
message that didn't get delivered.
___________________________
2.1.10 Delivery notifications from MEMO didn't get through to
MR
When /SEND_NOTIFICATIONS is enabled, MRMEMO V2.0
sometimes failed to send delivery notifications coming
from MEMO.
This has been fixed in V2.0A.
___________________________
2.1.11 NBS contents file is no longer left open
Sometimes the MRMEMO V2.0 server crashes with
'exceeded quota'. The file MRMEMOn-CONTENTS.NBS
is found to be open many times. This was caused
by an error in MRMEMO that could leave a service
message contents file from Message Router open after
disassembly.
This has been fixed in V2.0A.
___________________________
2.1.12 Delivery notifications to ALL-IN-1 now contain subject
When /SEND_NOTIFICATIONS is used and a message is
sent from ALL-IN-1 to MEMO, the returned delivery
notification didn't contain the subject of the
message.
This worked before MRMEMO V2.0, but was broken in
V2.0. In MRMEMO V2.0A, it has been fixed. The UACONTID
field of the Message Router delivery notification now
contains the subject of the message.
2-6
New features and changes
___________________________
2.1.13 Delivery notifications and MEMO distribution lists
There have been restrictions in MRMEMO about how
MEMO distribution lists may be composed to make
notifications work. To make the messages sent from
MEMO to MRMEMO change state from 'BEING SENT TO' to
'SENT TO, DISTRIBUTION NOT YET CONFIRMED', the MRMEMO
destined messages have previously had to be placed as
the first entries in a distribution list.
If /REQUEST_NOTIFICATIONS was used to make the
distribution list entries change state from 'SENT
TO, DISTRIBUTION NOT YET CONFIRMED' to 'SENT TO',
this didn't work unless the distribution list only
contained MRMEMO destined messages to one node and one
User Agent.
In MRMEMO V2.0A these restrictions have been removed.
A distribution list in MEMO can now contain any mix of
destinations in any order without confusing the MRMEMO
delivery notification handling.
___________________________
2.1.14 ALL-IN-1 users can now reply to local MEMO recipients
When a message was sent from MEMO to some local MEMO
users and ALL-IN-1 users in the same distribution
list, the addresses of the local MEMO users in the
recipients' copies of the distribution list were not
complete, making it impossible to send a reply to all
recipients from ALL-IN-1.
The address of a local MEMO user could in ALL-IN-1
look like DGA.ADAMS@MEMO1, which in general can not
be used since the node name is missing. In V2.0A, the
server node name is also added, producing the address
DGA.ADAMS@MEMO1@NODE, which can be replied to from all
nodes.
2-7
New features and changes
___________________________
2.1.15 Replacement character strings no longer left in USERID
If a message sent from MR to MRMEMO with any
characters in USERID being exposed to MRMEMO character
translation and the delivery failed, the translated
characters would not be changed back in the non-
delivery notification.
E.g. if sending from USERID = "JOHN ADAMS" to
DGA.NONEXIST@MEMO@NOD and there is a replacement
string "__= " defined in MRMEMO, a non-delivery
notification would be sent "back" to JOHN__ADAMS.
This has been fixed in V2.0A.
2-8
_______________________________________________________
3 Known Problems
In this section, known problems that are not fixed
in this release of MRMEMO are listed. They are being
worked on and might be mixed in a future release.
__________________________________________________________________
3.1 Problem reports
Problems must be reported as SPRs (Software
Performance Reports) to Digital.
__________________________________________________________________
3.2 The Server
The following are known problems with the server.
___________________________
3.2.1 First reverse lookup address is always used
The design change in MRMEMO V2.0A concerning MEMO to
MR recipient validation (see Section 2.1.2) can cause
replies from MEMO to go to the "wrong" address if
there is more than one MHS address in the recipient's
DDS record.
The address lookup in V2.0A can be made on an MHS
address instead of the SN items as key, but the
destination address used is still the first reverse
lookup address in the DDS record. If there is more
than one reverse lookup address, the destination might
not be what is expected and there will be a difference
between using recipient validation or not.
3-1
Known Problems
___________________________
3.2.2 Sender authorization on autoforwarded messages
If the sender authorization option is enabled
in the MR to MEMO direction, (ie 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.
___________________________
3.2.3 Maximum Message Size
The maximum message size is approximately 125 kbyte.
This implicates that the total size of an SNA message
must not exceed this limit.
If, as an example, the number of recipients is small,
MEMO line length is set to 75 and we assume there are
66 lines per page, the possible number of pages within
a single message is approximately 25. If the server
encounters a longer message, the message is truncated
and transferred to MEMO with a truncation notification
message.
WARNING: If a message is too long for MEMO, the
non-delivery notification returned to the sender by
MRMEMO will contain neither the message text nor the
recipient list. Only a error notice, "memo is too
big", will be returned.
3-2
Known Problems
___________________________
3.2.4 Non-delivery notifications with original messages
missing
Some error messages from MEMO are not distinct enough
for the server to be able to create real non-delivery
notifications. The original sender will receive a
notification considering an error reason (either "memo
is too big" or "recipient was not found") and a USERID
("MEMO SYSTEM THROUGH MRMEMO/GATEWAY"), but it is
missing other notification attributes as SENDER and
the original message.
___________________________
3.2.5 Delivery notifications over X.400 (MRX) doesn't work
When /REQUEST_NOTIFICATIONS is used and a message
sent over X.400 results in a delivery notification
that is sent back over X.400, MEMO will not be able
to identify which message the notification belongs to.
I.e. the notification is "lost" and the 'DELIVERY NOT
YET CONFIRMED' line in the MEMO distribution list will
never go away.
This is because the message identification code sent
out from MEMO with the original message usually
contains character codes that don't belong to the
IA5 character set required by X.400. The non-IA5
character codes are converted to IA5, which destroys
the MEMO message code and prohibits identification of
the originating message.
___________________________
3.2.6 Authorization error and MEMO distribution lists
When sending from MEMO to a distribution list and
MEMO to MR sender validation is used, there is a
problem if a validation fails. Only the first entry
in the sender's distribution list will change state to
'AUTHORIZATION FAILED'.
3-3
Known Problems
The correct behaviour would be to change status on all
distribution list entries that are destined for the
pertinent MRMEMO server and only those entries.
3-4
_______________________________________________________
4 Known Restrictions
In this section, problems and restrictions that are
the result of the characteristics of MEMO, VMS or
other products are described. These restrictions are
not to be considered as bugs in MRMEMO.
These problems might or might not be solved in future
releases.
__________________________________________________________________
4.1 Notify function in MEMO
The Notify function is a MEMO feature which
automatically notifies a sender when a MEMO recipient
is absent. This function is not supported in MRMEMO.
__________________________________________________________________
4.2 Service Messages are language dependent
Some User Agents (e.g. MRGATE, ALL-IN-1) do not
send notifications in the form of Message Router
Service Messages, but as ordinary text mails. Due
to this restriction, the server has to recognize
these messages by the SUBJECT field and is therefore
not able to recognize service messages created in
languages other than English, German or Swedish. This
affects e.g. local language versions of ALL-IN-1.
__________________________________________________________________
4.3 Use of MRMAN's READ command not possible on MRMEMO
messages
You cannot use the Message Router Manager's Utility
(MRMAN) to interactively read messages created by
MRMEMO.
4-1
Known Restrictions
If you try to use MRMAN to read MRMEMO messages in a
message router mailbox called MY_MBX on node MYNODE,
the following will happen:
$ RUN SYS$SYSTEM:MRMAN
This is MRMAN v 3.0
MRM> READ/IDENT=MY_MBX
%Using mailbox MY_MBX at node MYNODE
%MROUTER-E-FORMAT Syntax error in message with code "E"
Message Router error message indicates that the
message in the mailbox has some format syntax error
that MRMAN can't handle. This is true for all messages
created by MRMEMO.
__________________________________________________________________
4.4 Tag addresses in direction MR - MEMO with DDS lookups
disabled
Tag addresses will be passed unconverted to MEMO
unless MEMO recipient validation is enabled.
Furthermore, MEMO will return the message with error
status "unrecognised format". This will be converted
by MRMEMO into a non-delivery notification message
with the diagnostic "Invalid syntax for the Gateway".
The intended recipient element will not contain the
full original recipient address. Typically if the
original address read:
DGN=ABC @DEN=SMITH @MEMO
the intended recipient element of the non-delivery
notification will contain:
USERID: ABC
and the rest of the original address will be lost.
4-2
Known Restrictions
__________________________________________________________________
4.5 MRX has problems with MRMEMO non-delivery
notifications
Non-delivery notifications created by MRMEMO V2.0A are
not properly processed by MRX. MRX will complain about
a "mandatory sequence element missing". This is not a
fatal error but the non-delivery notification will be
dropped.
The MRX log will look something like this:
... %MRX-I-RTSMRFETC, has fetched from message router mailbox MRX_ADM into file SYS$SYSDEVICE:[MB$.MRX]35.NBS
... %MRX-I-STAMSGTRN, Started message translation
... %MRX-E-SEQELTMIS, Syntax error in message file SYS$SYSDEVICE:[MB$.MRX]35.NBS;1: mandatory sequence element missi
... -MRX-I-STATEIS, Parser state is RECIPIENTINFO2
... %MRX-E-SEQFULL, Syntax error in message file SYS$SYSDEVICE:[MB$.MRX]35.NBS;1: sequence full, too many items found
... -MRX-I-STATEIS, Parser state is RECIPIENTINFO2
... %MRX-W-PRSERRCON, Parser error in optional state: continuing
... -MRX-I-STATEIS, Parser state is REPORTEDRECIPIENTNAME
... %MRX-I-MSGID, Message id: country=SE, admin=ADM, private=DIGITAL, mpduid=32016151119891/2022@NODE File=SYS$SYSDEV
... %MRX-I-MSGCLASS12, Message file: SYS$SYSDEVICE:[MB$.MRX]35.X409 Class: OUTBOUND service message
... %MRX-I-ORNAME0, Originator ORname::
... %MRX-I-ORNAME3, Originator ORname:: Personal Name:
... %MRX-I-CPLMSGTRN, Completed message translation
4-3
|
|
13-Sep-1990
VAX MAILGATE for MEMO Version V2.1 Release Notes
This document contains release notes for V2.1 of VAX MAILGATE
for MEMO.
digital equipment corporation
________________________
Sep 1990
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes
no responsibility for any erros that may appear in this
document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability
of software on equipment that is not supplied by Digital
Equipment Corporation or its affilited companies.
__________
Copyright �1990 Digital Equipment Corporation.
All rights reserved
Printed in Sweden
The following are trademarks of Verimation AB:
MEMO SESAM
The following are trademarks of International Business
Machines Corporation:
IBM MVS/ESA VTAM
DOS MVS/XA SNA
MVS VM
The following are trademarks of Digital Equipment Corporation:
ALL-IN-1 MAILbus ULTRIX
DEC MASSBUS UNIBUS
DECmate Message VAX
Router
DECnet MicroPDP VAXmate
DECset MicroVAX VAX P.S.I.
DECstart MicroVMS VAX P.S.I. ACCESS
DECUS MRX VMS
DECsystem-10 OSAK VOTS
DECSYSTEM-20 PDP WPS-8
DECwriter Q-BUS WPS-PLUS
DIBOL Rainbow
DNA RSTS
LQP RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version 1.2
Contents
________________________________________________________________
________________________________________________________________
CHAPTER 1 INTRODUCTION 1-1
________________________________________________________________
CHAPTER 2 PREREQUISITE SOFTWARE 2-1
2.1 CDA CONVERSION 2-1
________________________________________________________________
CHAPTER 3 NEW FEATURES 3-1
3.1 ADDRESS TRANSLATION 3-1
3.1.1 Address format 3-2
3.1.2 Ensure uniqueness 3-3
3.1.3 Multiple oraddresses 3-5
3.2 ALTERNATE ADDRESSING TAG NAMES 3-6
3.3 SELECTION BETWEEN MR/S AND MR/P DDS ADDRESS
ATTRIBUTES 3-7
3.4 CLUSTER ALIAS SENDER ADDRESS 3-7
3.5 WRAPPING OPTIONS FOR TEXT LINES 3-8
3.6 MEMO-MEMO DELETE NOTIFICATIONS 3-9
3.7 LARGER MESSAGE SIZE 3-10
iii
3.8 FLEXIBLE SERVER INTERVAL TIMER 3-10
3.9 NEW INFORMATION IN STATUS DISPLAY 3-11
3.10 REFRESH OF MANAGER PROGRAM'S SCREEN 3-11
3.11 ACCOUNTING FILE ALLOWS SHARED READ ACCESS 3-11
________________________________________________________________
CHAPTER 4 CHANGES 4-1
4.1 MODIFIED FORMAT OF THE SERVER PARAMETER
DATABASE 4-1
4.2 REPLACEMENT SEQUENCES BEHAVE DIFFERENTLY 4-3
4.3 NO REPLACEMENT CHARACTERS IN THE ACCOUNTING
FILE 4-3
4.4 RECEIPT NOTIFICATION RECEIPTTYPE 4-4
4.5 DDS ATTRIBUTES OVERRIDE MEMO PROFILE DATA 4-5
________________________________________________________________
CHAPTER 5 CORRECTED PROBLEMS 5-1
5.1 AUTHORIZATION ERROR AND MEMO DISTRIBUTION
LISTS 5-1
5.2 COMPLETE DISTRIBUTION LISTS IN TEXT 5-1
iv
5.3 TAG ADDRESSES IN DIRECTION MR TO MEMO WITH
DDS LOOKUPS DISABLED 5-2
5.4 DDS ENTRIES FOR VMSMAIL CAN NOW BE USED
PROPERLY 5-2
5.5 REJECT MEMO TO MR ADDRESSES WITH WRONG PREFIX 5-3
5.6 DELIVERY NOTIFICATIONS OVER X.400 (MRX) NOW
WORKS 5-4
5.7 MR RECIPIENT VALIDATION NO LONGER SENDS TO
"WRONG" ADDRESS 5-4
5.8 LONG TEXT LINES NO LONGER CAUSES CRASH 5-4
5.9 AN MRMMAN USER CAN BE SUSPECTED AS NETWORK
INTRUDER 5-5
5.10 CLUSTER ALIAS IN MANAGER DEFINITIONS 5-6
5.11 MRMMAN CAN START SERVER IN BATCH 5-7
5.12 BETTER ERROR REPORTING IF PROCESS CREATION
FAILS 5-7
5.13 SOME MINOR MRMMAN DEFINE FIXES 5-8
5.14 DDS ADDRESS ENTRIES WITH MORE THAN ONE
ADDRPART 5-8
v
________________________________________________________________
CHAPTER 6 KNOWN PROBLEMS 6-1
6.1 NON-DELIVERY NOTIFICATIONS WITH ORIGINAL
MESSAGES MISSING 6-1
________________________________________________________________
CHAPTER 7 KNOWN RESTRICTIONS 7-1
7.1 NOTIFY FUNCTION IN MEMO 7-1
7.2 RECEIPT NOTIFICATIONS OVER X.400 DON'T WORK 7-1
7.3 MAXIMUM MESSAGE SIZE 7-2
7.4 SERVICE MESSAGES ARE LANGUAGE DEPENDENT 7-2
7.5 SENDER AUTHORIZATION ON AUTOFORWARDED
MESSAGES 7-2
7.6 USE OF MRMAN'S READ COMMAND NOT POSSIBLE ON
MRMEMO MESSAGES 7-3
________________________________________________________________
TABLES
3-1 Addressing tags 3-6
vi
Chapter 1
Introduction
________________________________________________________________
This document describes new features, changes, corrected
problems etc. in MRMEMO V2.1 compared to the previous ver-
sion, MRMEMO V2.0A.
Introduction 1-1
Chapter 2
Prerequisite software
________________________________________________________________
__________________________________________________________
2.1 CDA conversion
This version of MRMEMO supports conversion of CDA formatted
documents into the text format supported by MEMO.
This means that certain general CDA conversion software must
be installed in order to perform a successful MRMEMO V2.1
installation. The MRMEMO installation procedure checks for
the existence of the file SYS$LIBRARY:CDA$ACCESS.EXE. This is
part of the DECwindows base kit (pre VMS V5.4). Please make
sure that this is installed before you install MRMEMO V2.1.
If your system is running VMS V5.4 or later then this should
be included.
Prerequisite software 2-1
Chapter 3
New features
________________________________________________________________
In this chapter, the new features in MRMEMO V2.1 are de-
scribed.
__________________________________________________________
3.1 Address translation
Previously, an MR sender's address has always been presented
to MEMO recipients as prefix.user @ mailbox @ node. This
format can be regarded as somewhat unfriendly.
When DDS is used for MR recipient validation, messages can
be sent from MEMO using e.g. dgn.den, prefix.freeform or
prefix.SUR=surname @ GIVEN=givenname.
In MRMEMO V2.1, the new feature address translation makes
it possible to have the MR sender's address presented to the
MEMO user in virtually any of the formats that can be used
when DDS is used for MR recipient validation.
New features 3-1
__________________________________________________________
3.1.1 Address format
Address translation makes use of DDS to lookup MR sender's
on messages sent to MEMO. An address string on the desired
format is then composed from the information in the DDS
record. This address string will then be presented to the
MEMO recipient(s) as the sender's address. When the MEMO user
replies, DDS will be used again to translate the address to a
Message Router address.
The DDS lookups that are made when address translation is
used, are quite similar to what happens when DDS validation
is enabled for MR senders and MR recipients. There is, how-
ever, one important difference - DDS validation requires the
searched DDS records to be present, where address translation
does not.
When a DDS lookup that is initiated due to DDS validation
fails, the result is a non-delivery message to the sender
("sender authorization failure" or "recipient not found").
When an address translation lookup fails, the action taken is
the same as if DDS was not used at all. I.e. if an MR sender
lookup fails, no address translation will be performed and
the sender address presented to the MEMO user will have the
"old" format (prefix.user @ mailbox @ node). When an MR re-
cipient lookup fails, the address will be passed untranslated
to Message Router.
To enable address translation, the new MRMMAN DEFINE qual-
ifier /[NO]ADDRESS_TRANSLATION = (keyword[,...]) is used.
The format of the address string that is to presented to the
MEMO user is specified with the FORMAT keyword. Valid FORMAT
keyword values are:
o MEMO-this makes the presented address look like a MEMO
address (i.e. dgn.den) by fetching the DDS attributes
SNLOCATION and SNUSERNAME from the MR sender's DDS record.
(Or, alternatively, PRLOCATION and PRUSERNAME - see
Section 3.3.)
3-2 New features
o FREEFORM-this makes the presented address look like pre-
fix.freeform by fetching the DDS attribute NAME from the
DDS record.
o "Meta-string"-by using this, an arbitrary set of DDS
attributes can be used to compose a tagged address string.
E.g. the meta-string "<ORGANIZATION> @ <SURNAME>" will
present the address "prefix.ORGANIZATION=organization @
SURNAME=surname" to the MEMO user.
The tag names in the meta-string can be abbreviated or
used in their numeric form. The tags in the address pre-
sented to the MEMO user will have the same format and
abbreviations as in the meta-string. E.g. the meta-string
"<GIV> @ <6>" will present the address "GIV=givenname @
6=surname" to the MEMO user.
Examples on how to use MRMMAN to define various address
formats:
MRMMan> DEFINE /ADDRESS_TRANSLATION=FORMAT=MEMO
MRMMan> DEFINE /ADDR=FORM=FREEFORM
MRMMan> DEFINE /ADDR=FORM="<ORGANIZATION>@<SURNAME>"
MRMMan> DEFINE /ADDR=FORM="<GIV>@<6>"
Address translation is disabled with:
MRMMan> DEFINE /NOADDRESS_TRANSLATION
__________________________________________________________
3.1.2 Ensure uniqueness
When address translation is used, there is a risk of creat-
ing an MR sender address that will not uniquely identify a
DDS record and if the address is later (when the MEMO user
replies to it) used to do a DDS lookup, the lookup will fail.
New features 3-3
E.g. if the address translation format FREEFORM is used and
there are several addressees with the same name, FREEFORM
will not be enough to identify all users uniquely.
To avoid this situation, a longer address format could be
specified to contain enough attributes from the DDS record
to make sure the complete address string is always unique.
It is, however, unsatisfactory to have to present this long
string to the MEMO users. The idea of using address transla-
tion is to make the address look friendlier.
To solve this problem, MRMEMO can be set up to check the
uniqueness of the composed address and conditionally (in case
the address is not unique) add more attributes to the address
string.
This is done by using the keyword ENSURE_UNIQUENESS to spec-
ify a meta-string containing additional DDS attributes that
are to be added to the address string in case it is required
to make it unique. To, for example, use freeform format and,
in case the freeform name alone is not unique, add the orga-
nization name and the organizational unit name(s), use the
following command:
MRMMan> DEFINE /ADDRESS_TRANSLATION=(-
MRMMan_> FORMAT=FREEFORM,-
MRMMan_> ENSURE_UNIQUENESS="<ORG>@<UNIT>")
To disable the ensure uniqueness option, use
MRMMan> DEFINE /ADDRESS_TRANSLATION=NOENSURE_UNIQUENESS
NOTE
Enabling ENSURE_UNIQUENESS will cost some performance
since extra DDS lookups must be performed to check the
uniqueness.
3-4 New features
__________________________________________________________
3.1.3 Multiple oraddresses
DDS records can contain more than one Reverse lookup address.
When address translation is applied to an MR sender that
has a DDS record containing more than one address, a problem
arises.
If the selected format is e.g. FREEFORM, the MR sender's
address will be translated to the senders freeform name. When
this is replied to by a MEMO user, MRMEMO will lookup the
DDS record and find several Message Router addresses in the
record-which one to choose?
MRMEMO offers three different behaviors that can be selected
through the DEFINE /ADDRESS_TRANSLATION keyword MULTIPLE_
ORADDRESS:
o PRIMARY-The primary (first) of the MHS/VMS addresses in
the DDS record is always used as destination address.
Note that when this option is selected, replies and status
messages (e.g. non-deiliveries) will not be returned to
the originating address in case the sender is not sending
from his/her "primary" address.
o MATCHING-This option causes the string "@ADDRNO=number" to
be appended to the sender's address before it is sent to
MEMO, where number is the sequence number of the address
in the DDS record. This will make MRMEMO able to find the
originating address and make replies (and status messages)
from MEMO go back to the original sender's address.
o NON_DELIVERY-This disallows MR senders having DDS records
containing multiple addresses to be used for address
translation. The message will not be sent and the sender
will receive a non-delivery notification with diagnostic
"originator not unique".
New features 3-5
Examples on MRMMAN commands:
MRMMan> DEFINE /ADDRESS_TRANSLATION=MULTIPLE_ORADDRESS=PRIMARY
MRMMan> DEFINE /ADDR=MUL=MATCHING
MRMMan> DEFINE /ADDR=MUL=NON_DELIVERY
__________________________________________________________
3.2 Alternate addressing tag names
In MRMEMO V2.1, the addressing tag names have been changed
from the old MRMMAN qualifier syntax to the MRX syntax.
Table_3-1:__Addressing_tags__________________________________
Old_tag_______New_alternate_name(s)__________________________
AMDNAME ADMIN_DOMAIN, ADMDNAME
GIVENNAME GIVEN_NAME
ORGNAME ORGANIZATION
PRDNAME PRIVATE_DOMAIN, PRMDNAME
ORGUNIT UNIT_NAME
UNIQUEUAID____UNIQUE_UAID____________________________________
The old tag names can still be used, as well as the numeric
form of the tags.
The preferred format is the one used by MRX (ADMIN_DOMAIN,
GIVEN_NAME, ORGANIZATION, PRIVATE_DOMAIN, UNIT_NAME and
UNIQUE_UAID).
3-6 New features
__________________________________________________________
3.3 Selection between MR/S and MR/P DDS address attributes
When MEMO address information (DGN and DEN) is to be stored
in DDS, there are no dedicated fields available for MRMEMO.
Instead, the fields intended for use with MR/S have previ-
ously been used (SNLOCATION and SNUSERNAME).
Still, there are no dedicated MRMEMO fields available in
DDS, but to avoid conflicts in installations comprising both
MRMEMO and MR/S, MRMEMO V2.1 makes it possible to use the DDS
fields intended for MR/P (PRLOCATION and PRUSERNAME) instead.
The new MRMMAN qualifier DEFINE /MEMO_ADDRESS = (SN_
ATTRIBUTES or PR_ATTRIBUTES) decides which set of attributes
to use.
__________________________________________________________
3.4 Cluster alias sender address
Previously, MRMEMO has always used the server node name
(i.e. the translation of the logical name SYS$NODE) as an
addressing entity.
In MRMEMO V2.1, it is possible to use the cluster alias name
(i.e. the translation of the logical name SYS$CLUSTER_NODE)
instead of the node name. The new MRMMAN qualifier DEFINE
/[NO]CLUSTER_ALIAS_ADDRESS controls this option.
When this option is enabled, an MR sender's address will be
presented to the MEMO user as prefix.user..mailbox..alias
instead of prefix.user..mailbox..node. If address translation
is enabled, the address will have a completely different
format where neither node nor alias name is included. See
Section 3.1 for information about address translation.
Also, a MEMO sender's address will be posted to the Message
Router with the cluster alias name of the MRMEMO node as part
of the sender's route.
New features 3-7
NOTE
If DDS lookups are used, enabling this option will
cause the cluster alias name to be searched for in the
ADDRPART of reverse lookup address strings instead of
the node name of the MRMEMO server node. Any existing
DDS records containing only the MRMEMO server node
name must be updated to contain the cluster alias name
if they are to be found by MRMEMO.
__________________________________________________________
3.5 Wrapping options for text lines
In MEMO, the text line width is fixed. In previous versions
of MRMEMO, lines that are longer than the MEMO line length
have been wrapped to the next line.
To make it possible to have the treatment of long lines pro-
duce a result that looks more pleasant, the MRMMAN qualifier
DEFINE /TEXT_LINES has been added in V2.1.
By using /TEXT_LINES = (keyword[,...]) it is possible to
specify:
o the MEMO line length (WIDTH=n). This is a synonym for the
old qualifier /LINE_LENGTH.
o if long lines should be wrapped or truncated ([NO]WRAP).
WRAP enables wrapping and causes long lines to wrap to
the next MEMO line (as in previous versions). NOWRAP will
truncate long lines and cause the characters exceeding the
MEMO line length to be lost.
o a character string that is to be inserted at the end
of wrapped/truncated lines as an indicator ([NO]WRAP =
string).
o if word wrapping should be attempted, i.e. wrapping is
done at space characters ([NO]MARGIN=max distance from
line end where a space is searched for).
3-8 New features
o a character string that is to be inserted at the end of a
wrapped line when word wrapping is enabled and no space is
found to wrap at (HYPHEN = string).
An example:
DEFINE /TEXT_LINES = (WIDTH=73, WRAP, MARGIN=16, HYPHEN="-")
will
o set the MEMO line length to 73 characters,
o wrap lines longer than that on to the next MEMO line,
o try to wrap at a space if one is found among the 16 last
characters
o and insert the string "-" at the end of lines where a
space was not found to wrap at.
__________________________________________________________
3.6 MEMO-MEMO delete notifications
In MEMO, a sender of a message can, by "expanding" the mes-
sage, check if the message has been deleted by the recipi-
ent(s). This is accomplished by MEMO through the sending of
status messages indicating that the message has been deleted.
MRMEMO V2.1 supports passing of such "delete notifications"
to/from Message Router.
Since these delete notifications is something that is only
used by MEMO, this new functionality of MRMEMO only affect
messages where both the originating system and the desti-
nation system are MEMO systems. I.e. MAILbus is used for
communication between MEMO systems.
New features 3-9
__________________________________________________________
3.7 Larger message size
Previous MRMEMO versions have used a message buffer size of
approximately 125 Kbytes, which has been more than sufficient
to handle the maximum MEMO message size.
The MRMEMO V2.1 message buffer size has been increased to
support larger message sizes (approx. 500 Kbytes) in antici-
pation of future increases of MEMO's ability to handle large
messages.
NOTE
The larger buffer size in MRMEMO does not automati-
cally mean that larger messages than before can be
sent to MEMO. The largest message that can be sent
is restricted not only by MRMEMO but also by MEMO and
MEMO Gateway.
__________________________________________________________
3.8 Flexible server interval timer
In the MRMEMO server there is an interval timer. Each time
this timer expires, MRMEMO performs some operations, of which
the most important one is to check the Message Router mailbox
for messages. Previously, the time interval has been fixed to
30 seconds.
In MRMEMO V2.1, the time interval value is part of the perma-
nent server database and can be changed with the MRMMAN com-
mand DEFINE /CLOCK_TICK = delta-time. The delta time format
looks like [dddd-] [hh:mm:ss.cc]. The default is 30 seconds
(0:0:30).
By changing the time interval, checking of the mailbox could
be made more frequent (or infrequent). It is recommended
not to use extreme values (such as hours or fractions of a
second) for the interval timer.
3-10 New features
__________________________________________________________
3.9 New information in status display
The MRMMAN command SHOW /STATUS now includes three additional
lines:
o Direction-the direction of the last message handled (MR to
MEMO or vice versa).
o Timestamp-the time the last message was sent.
o Status-number of recipients that were successfully deliv-
ered to and number of failing recipients (non-delivered)
of the last message.
__________________________________________________________
3.10 Refresh of manager program's screen
When monitoring an MRMEMO server with the MRMMAN command SHOW
/CONTINUOUS, the screen contents could become destroyed (e.g.
due to LAT session switching or line noise).
Previously, it has been necessary to leave the continuous
mode and give the SHOW /CONT command again to reinitialize
the screen. In MRMEMO V2.1, it is possible to use CTRL/W in
MRMMAN to reinitialize screen (like in most other Digital
screen oriented applications).
__________________________________________________________
3.11 Accounting file allows shared read access
Previously, MRMEMO has claimed exclusive access to the ac-
counting file (MRMEMOACCn.DAT).
MRMEMO V2.1 allows shared reading of the accounting file.
This makes it possible to examine the accounting file while
the server is active and accounting enabled.
New features 3-11
Chapter 4
Changes
________________________________________________________________
This chapter describes changes in MRMEMO since previous
version.
__________________________________________________________
4.1 Modified format of the Server Parameter Database
The MRMEMO Server Parameter database, MRMEMO$DIR:MRMEMOPAR.DAT,
has been extended to accommodate data for new server qual-
ifiers. This means that if you wish to use some of the new
features, you will have to create a new database. If you
don't intend to use any new features, the old file can still
be used.
If MRMMAN V2.1 is started when the database is in old format,
MRMMAN will display the message '%MRMEMO-I-PERMDBOLD, perma-
nent database has old format'. In this situation, the follow-
ing server DEFINE qualifiers can not be used (see description
of commands in Chapter 3):
o /ADDRESS_TRANSLATION
o /CLOCK_TICK
o /CLUSTER_ALIAS_ADDRESS
o /MEMO_ADDRESS
Changes 4-1
o /TEXT_LINES
When any of the qualifiers above is used with an old
database, MRMMAN will display the message '%MRMEMO-W-
QUALNOTSUP, qualifier <qualifier> not supported for old
database format'.
To convert an old database to the new format, the MRMMAN
command CONVERT /DATABASE [/NEW=new-file-name] can be used.
This command converts a permanent MRMEMO server database
(MRMEMO$DIR:MRMEMOPAR.DAT) in old format (pre V2.1) to V2.1
format. Fields and options that did not exist in the old
database format are filled in with default values.
By default, a new version of MRMEMOPAR.DAT is created
on MRMEMO$DIR. If it for some reason is desired that
the converted database should not be a new version of
MRMEMO$DIR:MRMEMOPAR.DAT, the /NEW qualifier can be used
to specify an alternate name and/or directory.
NOTE
To access the newly created database file with
MRMMAN, MRMMAN must be exited and entered again.
When MRMMAN is started, it always uses the database
MRMEMO$DIR:MRMEMOPAR.DAT.
To create a completely new database, do the following:
1. Delete (or rename) the file MRMEMO$DIR:MRMEMOPAR.DAT
2. Run the MRMEMO manager's utility, MRMMAN. A new parameter
file will be automatically created.
3. Use MRMMAN's DEFINE command to create a new server record.
4-2 Changes
__________________________________________________________
4.2 Replacement sequences behave differently
The substitution method for replacement sequences in ad-
dress strings is slightly different in MRMEMO V2.1 compared
to previous versions. This will not be noticed in most en-
vironments. In some situations, the effects of the changed
substitution method could however cause different results.
Previously, at signs ('@') and spaces were not searched for
in address strings if there was a replacement defined (e.g.
'..=@'). Instead, only the replacement sequence was searched
for (in this case '..').
In MRMEMO V2.1, the substitutions are done first and then the
search for '@' and ' '. A consequence of this is that in an
environment where '@' can be used in MEMO, '@' and a possible
replacement sequence can both be used as route delimiters.
Previously, '@' would not be recognized as a route delimiter
if there was a replacement sequence defined for it.
__________________________________________________________
4.3 No replacement characters in the accounting file
In the MRMEMO accounting file (MRMEMOACCn.DAT), the orig-
inator addresses are stored. Previously, any MRMEMO Server
replacement character strings in effect (e.g. "..=@") have
been displayed in the accounting file. That is, an originator
address could look like "USER..MBX..NODE".
In MRMEMO V2.1, address replacement sequences will not be
displayed in the accounting file. I.e. the originator will
look like "USER@MBX@NODE" regardless of any replacement
defined for '@'.
Changes 4-3
__________________________________________________________
4.4 Receipt notification RECEIPTTYPE
When a message with a request for a receipt notification
(read receipt) is sent to MEMO, a status message will be
issued by MEMO when the message is read (selected) by the
MEMO user. This status message is translated by MRMEMO to a
receipt notification and sent to Message Router.
A receipt notification contains, among other information, an
element (RECEIPTTYPE) that indicates whether the recipient
explicitly (manually) authorized sending of the receipt noti-
fication or if the user agent has generated the notification
automatically.
Previously, MRMEMO has not given this element (RECEIPTTYPE)
any value which caused it to get the default value. The
default is to indicate that the recipient has explicitly
authorized the receipt notification.
This is not consistent with how MEMO implements receipt noti-
fications. In MEMO, users are not given the option to autho-
rize the sending of receipt notifications. To reflect this,
MRMEMO V2.1 sets the RECEIPTTYPE element to indicate that the
user agent has generated the notification automatically.
This will cause e.g. ALL-IN-1 MAIL to display the text
Message receipt was acknowledged automatically.
instead of
Message receipt was acknowledged explicitly.
in association with a receipt notification from MEMO.
4-4 Changes
__________________________________________________________
4.5 DDS attributes override MEMO profile data
In a MEMO user's profile, there is some information that MEMO
puts in outgoing messages and MRMEMO propagates to Message
Router. The MEMO profile field "Full name", for example, is
used as SURNAME by MRMEMO.
When DDS is used for MEMO sender validation (authorization),
information from the MEMO sender's DDS record is included in
the created message that is posted to Message Router.
If there is information from both the MEMO profile and the
DDS record, the MEMO profile data has previously been used.
In MRMEMO V2.1, data from DDS will override the MEMO profile
data.
Changes 4-5
Chapter 5
Corrected problems
________________________________________________________________
__________________________________________________________
5.1 Authorization error and MEMO distribution lists
When sending from MEMO to several recipients and MEMO sender
validation is used, MRMEMO will now send a status message
back to MEMO that causes the correct entries in the sender's
distribution list to change state to 'Authorization failed'.
That is, the entries that are destined for the pertinent
MRMEMO server and only those entries will change state.
Previously, only the first entry in the sender's distribution
list changed state to 'Authorization failed' (regardless of
whether this was an MRMEMO recipient or not).
__________________________________________________________
5.2 Complete distribution lists in text
The MRMMAN DEFINE qualifier /DISTRIBUTION_LIST decides if and
where a distribution list should be presented in the message
text of messages going from Message Router to MEMO.
Corrected problems 5-1
When presentation of the distribution list is enabled, the
complete distribution list was previously not always dis-
played. If the sender of the message requested read receipts
(e.g. from ALL-IN-1), the complete distribution list was pre-
sented, but if there was no request for read receipts (as
is always the case when using e.g. MRGATE), only the first
recipient in the distribution list was displayed in the MEMO
message.
In MRMEMO V2.1, the complete distribution list is always
presented if /DISTRIBUTION_LIST is enabled (BEGINNING or
END).
__________________________________________________________
5.3 Tag addresses in direction MR to MEMO with DDS lookups
disabled
Previously, MRMEMO checked addressing tags (e.g. SURNAME=)
for valid syntax even when DDS MEMO recipient validation was
not enabled. This stopped the address parsing if an invalid
tag was found and caused the non-delivery message to contain
only part of the address specified by the sender (possibly
just an empty string).
In MRMEMO V2.1, tag addresses will be passed unconverted to
MEMO unless MEMO recipient validation is enabled. This should
make non-delivery messages contain the complete address that
delivery was attempted to.
__________________________________________________________
5.4 DDS entries for VMSmail can now be used properly
MRMEMO has previously had some problems with DDS records
where the VMS address format (MBMAN /VMSORADDRESS qualifier)
was used instead of the MHS address format (/MHSORADDRESS
qualifier). This made it necessary to set up DDS entries for
VMSmail users using MRGATE on a remote node in a way that
didn't look very pleasant.
5-2 Corrected problems
With MRMEMO V2.1, it is possible to set up DDS records for
VMSmail users using the /VMSORADDRESS format and have DDS
validation and/or address translation work properly.
A VMSmail address where MRGATE is present on the same node as
the VMSmail user should be defined with:
MBMAN> MOD DDS SUB /VMSOR=(ADDR=usernode, VMSUSER=username)
A VMSmail address where the VMSmail user uses MRGATE on
another node (e.g. the node MRGNODE), should be defined with:
MBMAN> MOD DDS SUB /VMSOR=(ADDR=MRGNODE, VMSNODE=usernode,-
_mbman> VMSUSER=username)
__________________________________________________________
5.5 Reject MEMO to MR addresses with wrong prefix
If there is a mismatch in the prefix specification between
the MEMO system and the MRMEMO server, MRMEMO has previously
regarded the MR recipients with the wrong (from MRMEMO's
point of view) prefix as passive recipients. I.e. recipients
to whom the message will not be delivered.
This caused an error to be signaled in the server logfile
(%MRMEMO-W-NORECIP, no VAX recipients entered) and the
message to be lost (i.e. the sender didn't get any error
notification).
In MRMEMO V2.1, a more informative error will be signaled in
the server logfile (%MRMEMO-W-BADPREFIX1, receiver <recipient
address> is active, string doesn't begin with prefix) and
an error status message will be sent back to the MEMO sender
with status 'Distr rej. invalid memo format'.
Corrected problems 5-3
__________________________________________________________
5.6 Delivery notifications over X.400 (MRX) now works
When /REQUEST_NOTIFICATIONS is used and a message sent over
X.400 results in a delivery notification that is sent back
over X.400, MEMO will now be able to identify which message
the notification belongs to. I.e. the message will change
state from 'Delivery not yet confirmed' to 'Sent to'.
The message identification code sent out from MEMO is now
converted by MRMEMO to characters that are allowed to pass
unharmed over X.400. This enables MEMO to correlate the
delivery notification to the original message.
__________________________________________________________
5.7 MR recipient validation no longer sends to "wrong" address
Starting with MRMEMO V2.0A, DDS address lookups can be made
on an MHS address (user@mailbox@node) instead of DGN and
DEN items as key. But in V2.0A, the destination address
used was still the first reverse lookup address in the DDS
record. If there was more than one reverse lookup address,
the destination might not be what was expected and there
would be a difference between using recipient validation or
not.
In MRMEMO V2.1, the matching MHS address will be used as
destination address if the MEMO sender specifies an MHS
address and MEMO to MR recipient validation is enabled. If
address translation is used, see also Section 3.1, MULTIPLE_
ORADDRESS.
__________________________________________________________
5.8 Long text lines no longer causes crash
When a long text line (more than 256 characters) was received
by MRMEMO from Message Router, MRMEMO previously crashed
(access violation).
5-4 Corrected problems
MRMEMO V2.1 will handle lines up to 512 characters in length.
Lines longer than that will be truncated to 512 characters.
Note that a long text line can also be the result of tab
expansion. MRMEMO expands tabs in message lines from Message
Router to spaces (1-8 spaces per tab depending on the tab
position).
__________________________________________________________
5.9 An MRMMAN user can be suspected as network intruder
Due to the way MRMMAN connects to the MRMEMO server, VMS
security alarms could get triggered when connect attempts are
made to a server that is not active (i.e. has not declared
itself as a network object).
To avoid this problem, the MRMEMO startup command file
(MRMEMOSTART.COM) has been extended to include NCP commands
that define the MRMEMO network object name(s) before any
server is started.
By defining the network objects in this way, the connect
attempts will not cause VMS security alarms. By default,
the command file is designed to define the object for server
number 1. If other servers are to be used, the file should be
edited to define network objects for all used servers.
This does not solve the problem completely since the ob-
jects will not be declared until the MRMEMO startup procedure
is executed. To fully avoid the risk of having MRMMAN at-
tempt invalid logins, the MRMEMO network object(s) should be
permanently defined in the network database with the command
$ MCR NCP DEFINE OBJECT MRMEMOn NUMBER 0
Corrected problems 5-5
__________________________________________________________
5.10 Cluster alias in manager definitions
In a cluster environment, the list of valid MRMEMO managers
could get quite long if it desired that management should be
possible from several nodes in the cluster.
A list of managers could look like:
VAX1::SMITH
VAX2::SMITH
VAX3::SMITH
VAX1::JONES
VAX2::JONES
VAX3::JONES
If the cluster alias name is used instead, which is much more
convenient. the manager list could look like:
VAXCLU::SMITH
VAXCLU::JONES
In MRMEMO V2.1, this is prepared in the MRMEMO startup com-
mand procedure (MRMEMOSTART.COM). Uncomment the last part of
the command line
SET OBJECT MRMEMOn NUMBER 0 !ALIAS OUTGOING ENABLED
by changing it to
SET OBJECT MRMEMOn NUMBER 0 ALIAS OUTGOING ENABLED
This will make MRMMAN identify the user with the cluster
alias name instead of the node name.
NOTE
This only works if MRMMAN and the server run on the
same node. If not, the commands that define the
MRMEMOn network object(s) must be executed in some
other way on the MRMMAN node. E.g. by including them
in a system startup command file.
5-6 Corrected problems
__________________________________________________________
5.11 MRMMAN can start server in batch
The MRMMAN command START can now be used when MRMMAN runs in
batch.
Before MRMEMO V2.1, it was not possible to use the START
command in batch (or interactively with SYS$OUTPUT redirected
to a file). If SYS$OUTPUT did not point to a terminal device,
the error '%SYSTEM-F-FILNOTACC, file not accessed on channel'
occurred when the START command was used.
__________________________________________________________
5.12 Better error reporting if process creation fails
If starting a MRMEMO server should fail due to a process
creation problem, the error message reported by MRMMAN has
previously only consisted of the first message line reported
by VMS. Example on the old behavior:
MRMMan> START 1
%MRMEMO-I-STARTING, status from server process creation is:
%RUN-F-CREPRC, process creation failed
MRMMan>
The reason for the process creation failure is not reported.
It was necessary to examine NETSERVER.LOG on MRMEMO's login
directory to find the complete message.
In MRMEMO V2.1, the complete message will be reported by
MRMMAN. Example:
MRMMan> START 1
%MRMEMO-I-STARTING, status from server process creation is:
%RUN-F-CREPRC, process creation failed
-SYSTEM-F-DUPLNAM, duplicate name
MRMMan>
Corrected problems 5-7
__________________________________________________________
5.13 Some minor MRMMAN DEFINE fixes
Some minor errors and inconsistencies have been fixed in the
MRMMAN DEFINE command:
o The DEFINE /REPLACE command now reports "%MRMEMO-I-
MODIFIED, server n modified" (as all other define com-
mands).
o DEFINE /NOREPLACE and DEFINE /NOCIRCUIT_NAME now works.
o The DEFINE qualifiers /MRMAILBOX, /NODE and /PREFIX are no
longer allowed in negated form.
__________________________________________________________
5.14 DDS address entries with more than one ADDRPART
DDS entries containing an ADDRPART list (i.e. more than one
node) have previously not always been found when searched
for by MRMEMO. This affected MR sender validation and MR
recipient validation.
This problem has been corrected in V2.1.
5-8 Corrected problems
Chapter 6
Known Problems
________________________________________________________________
In this chapter, known problems that are not fixed in this
release of MRMEMO are listed. They are being worked on and
might be fixed in a future release.
Problems must be reported as SPRs (Software Performance
Reports) to Digital.
__________________________________________________________
6.1 Non-delivery notifications with original messages missing
MRMEMO does not save enough information about outstanding
messages to MEMO to be able to respond properly to certain
errors reported by the MEMO system.
This causes some non-delivery notifications to lack some
information that should be there. The original sender will
receive a notification containing an error reason (e.g. "memo
is too big" or "recipient was not found") and a USERID ("MEMO
SYSTEM THROUGH MRMEMO/GATEWAY"), but other notification at-
tributes such as SENDER and the original message are missing.
Known Problems 6-1
Chapter 7
Known Restrictions
________________________________________________________________
In this section, problems and restrictions that are the
result of the characteristics of MEMO, VMS or other products
are described. These restrictions are not to be considered as
bugs in MRMEMO.
These problems might or might not be solved in future re-
leases.
__________________________________________________________
7.1 Notify function in MEMO
The Notify function is a MEMO feature which automatically
notifies a sender when a MEMO recipient is absent. This
function is not supported in MRMEMO.
__________________________________________________________
7.2 Receipt Notifications over X.400 don't work
To be able to provide MEMO with information enough to cor-
relate receipt notifications to the original MEMO sender's
message, MRMEMO adds some information to the Message Router
message in Domain Defined Attributes. These attributes are
however lost if the message is sent over X.400, which makes
MEMO unable to recognize possible returned receipt notifica-
tions.
Known Restrictions 7-1
__________________________________________________________
7.3 Maximum message size
The maximum message size that MRMEMO V2.1 can handle is
approximately 500 Kbytes. This implicates that the total
size of an SNA message must not exceed this limit.
If, as an example, the number of recipients is small, MEMO
line length is set to 75 and we assume there are 66 lines per
page, the possible number of pages within a single message
is approximately 100. If the server encounters a longer
message, the message is truncated and transferred to MEMO
with a truncation notification message.
WARNING: If a message is too long for MEMO, the non-delivery
notification returned to the sender by MRMEMO will con-
tain neither the message text nor the recipient list. Only
an error notice, "memo is too big", will be returned (see
Section 3.7).
__________________________________________________________
7.4 Service Messages are language dependent
Some User Agents (e.g. MRGATE and ALL-IN-1) do not send all
notifications in the form of Message Router Service Messages,
but as ordinary text mails. Due to this restriction, the
server has to recognize these messages by the subject field
and is therefore not able to recognize service messages
created in languages other than English, German or Swedish.
This affects e.g. local language versions of ALL-IN-1.
__________________________________________________________
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.
7-2 Known Restrictions
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.
__________________________________________________________
7.6 Use of MRMAN's READ command not possible on MRMEMO messages
The Message Router Manager's Utility (MRMAN) cannot be used
to interactively read messages created by MRMEMO.
If you try to use MRMAN to read MRMEMO messages in a message
router mailbox called MY_MBX on node MYNODE, the following
will happen:
$ RUN SYS$SYSTEM:MRMAN
This is MRMAN V3.1
MRM> READ/IDENT=MY_MBX
%Using mailbox MY_MBX at node MYNODE
%MROUTER-E-FORMAT Syntax error in message with code "E"
The Message Router error message indicates that the message
in the mailbox has some format syntax error that MRMAN can't
handle. This is true for all messages created by MRMEMO.
This is a known problem in MRMAN V3.1.
Known Restrictions 7-3
|