Name | Value |
---|---|
NAME | XM-I-NEW FEATURES |
HEADER | NEW FEATURES FOR SITE MANAGERS |
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 |
DATE ENTERED | 2002-05-06 10:12:04 |
AUTHOR | USER,ONE |