1.7e will introduce changes to the behaviour of mailing lists, and peered lists in particular, in order to support messages with lines longer than 80 bytes (with the understanding that this code cannot be activated with the present version of the VM mailer and that it will not have been tested when 1.7e is released). It is assumed that the new mailer will fold (and not truncate) lines longer than 80 bytes when delivering to "old" mailers. When a 1.7e site with a "new" mailer mails a copy of a message with long lines to a 1.7e site with an "old" mailer, the lines will be folded by the mailer at the sending site. Even though the message will look approximately the same, its CRC will be different since it has, in effect, been altered. Furthermore the CRC algorithm used in 1.7d and older versions is not suitable for messages with lines longer than 80 bytes. To avoid duplicating the work that was done with DISTRIBUTE, - CRC's will no longer be checked among peers. 1.7e will supply no CRC value, nor will it attempt to verify any CRC value supplied by older servers. - DISTRIBUTE will be used to deliver the message to the peer, so that its integrity can be validated by the dual-CRC system of LSVDIST2. For similar reasons, support for "Mail-via= Direct" has been removed: all delivery will now take place through DISTRIBUTE, which has code for dealing with long lines and their integrity. LSVXMAIL no longer writes to the punch at all. Unfortunately, older versions of DISTRIBUTE truncate lines longer than 80 bytes. This is because EXECIO PUNCH (or CARD PUNCH, or equivalent techniques) were used. In fact, lines longer than 80 bytes were simply not valid as input, since DISTRIBUTE dealt, by definition, with card images. Note that header lines of 255 characters or less (or any length with 1.7d) *are* properly folded by all versions, including LISTEARN; this is because they were sometimes generated internally and could exceed the 80 bytes limit. The problem only applies to the body of the message, which means that delivery will not fail but characters beyond column 80 will be lost. This is already a concern in itself, since it will affect delivery to end users. As far as LISTSERV is concerned, the early release of 1.7e should make it possible to build a backbone of servers which can handle long lines *before* the new mailer is actually released. There remains the problem of LISTEARN, which would have to be modified both to fold lines longer than 80 bytes when distributing mail and to accept lines longer than 255 in job files. I will let Turgut comment on that. This truncation is an even more serious concern when it comes to peered lists. A new DISTRIBUTE option is used to order DISTRIBUTE to deliver the CRC'ed jobs directly to the LISTSERV at the target node, without going through any intermediate node; this ensures that truncation will never occur if the target node is running 1.7e, no matter what may lie in between. This however does not address the problem of older servers. A compatibility list-header option will be provided to fold the message at the source for all recipients (as done in previous versions), thus ensuring that messages with long lines are never generated and removing the truncation problem. It will be necessary to use this option when peering lists with servers not running 1.7e, or some of the peers may distribute truncated copies. That option can also be used in cases where lines longer than 80 are simply not desired - many workstation users tend to forget that there are people with terminals that show less than 260 characters per line, and some mail user interfaces do not display long lines in a very user-friendly way. In fact, the support for long line is mostly to make it possible to mail source code excerpts and the like, rather than for actual textual messages. This new keyword is called "Long-Lines= No" and is a no-operation for messages without long lines. In other words, there is no need to code it for the transition period during which 1.7e will slowly replace 1.7d - at least not before the new mailer is released. This option is mostly for compatibility with LISTEARN, and for lists where a lot of subscribers cannot conveniently read lines longer than 80 bytes. Eric