| TEXT |
address with the working one. In order to activate DNS awareness, this
new field in the MAILMAN SITE PARAMETERS file 4.3 must be set to 'yes':
4.3,8.22 DNS AWARE Yes or No?
Also, routine ^XLFNSLK must exist, and the following field in the
KERNEL SYSTEMS PARAMETERS file 8989.3 must be properly filled in with
an IP address:
8989.3,51 DNS IP IP address for DNS
2. For TCP/IP connections, MailMan can now build transmission scripts on
the fly. For transmission scripts whose TYPE is "SMTP", "TCPCHAN", or null,
MailMan 8.0 offers the following improvements over MailMan 7.1:
the transmission scripts (in the TEXT field 2, in the TRANSMISSION SCRIPT
multiple) in the DOMAIN file, 4.2, are no longer used if these new fields
in the MAILMAN SITE PARAMETERS file 4.3 are filled in:
4.3,8.23 TCP/IP COMMUNICATIONS PROTOCOL Points to file 3.4
4.3,8.24 TCP/IP TRANSMISSION SCRIPT Points to file 4.6
3. Messages in transmit queues can now be designated as low priority, as
well as high priority. If a message gets stuck in a transmit queue and is
holding up the rest of the queue for whatever reason, MailMan will make
that message a low priority message, so that all the other messages are
transmitted ahead of it. The postmaster can also make these priority
changes. In the message queue, high-priority messages are now marked with
'^', instead of '$'. Low priority messages are marked with 'v'.
The postmaster can now change the transmit priority at the message level
(at the 'Message action: Ignore//' prompt). As at the basket level, the
command to use is 'X'. (In a user basket, the 'X' at the message level is
a command to unload a PackMan message or KIDS build. In a remote transmit
queue, the 'X' changes the transmit priority. The difference is the
context, and writers of MailMan front-ends should take note!)
1. MailMan is now DNS aware. It can use the Kernel API MAIL^XLFNSLK
4. MailMan date/times are now in a standard format, produced by the Kernel
API: $$FMTE^XLFDT(datetime,"2Z"). Previously, 3020803.153204 would be
displayed as '03 Aug 02 15:32'. Now, it is displayed as '08/03/02@15:32'.
This change is also carried through to all MailMan APIs which return
date/time in MailMan format.
5. MailMan remote message IDs now include the message date, to ensure that
if you are told that a message is a duplicate of a previously received
message, it really is. Sites will no longer have problems sending messages
to retrieve IP addresses. It is no longer necessary to manually update the
from a production account to a test account which was created by "mirroring"
the production account. The remote message ID is now the message number
following by a period, followed by the 7-digit FileMan message creation
date. Before, a remote message ID might be 34561234@DOMAIN.EXT. Now it
would be 34561234.3020803@DOMAIN.EXT.
6. The ^XMC*, ^XMR*, ^XMS* suite of routines, which are responsible for
scheduling, transmitting to, and receiving messages from remote sites, have
been completely overhauled to make them easier to understand and easier to
maintain.
IP addresses in the DOMAIN file, 4.2. The IP address fields will remain in
7. MailMan will no longer display user names by taking them directly from
the .01 field of the NEW PERSON file, 200. The API, $$NAMEFMT^XLFNAME,
supplied as part of the Name Standardization project, is used, instead.
Thus, the names of people whose last names, for instance, contain periods,
apostrophes, or spaces, are properly displayed (ST. IVES, O'MALLEY, and
VAN DYKE), instead of improperly (STIVES, OMALLEY, and VANDYKE).
8. Messages with responses may no longer be forwarded to broadcast to all
users. Such messages may have important information in the responses, and as
file 4.2, and MailMan will use them. However, if they don't work, MailMan
we all know, responses are not auto-forwarded to remote sites for users with
auto-forward addresses. Users who attempt to broadcast messages with responses
will be encouraged to copy the message and its responses into a new message,
which can be broadcast.
9. Incoming PackMan and KIDS messages are no longer subject to the
restriction NETWORK - MAX LINES RECEIVE (field 8.31, file 4.3). Other kinds
of messages continue to be subject to that restriction.
10. If a task transmitting messages to another site fails and has to be
will use the Kernel API to retrieve a list of valid IP addresses. When
requeued, it really is requeued. Previously, that wasn't true. Previously,
the failing task queued up a new task to take its place, and then the
failing task stopped.
MailMan finds one that works, MailMan will replace the non-working IP
|
