The following changes were made to the loop detection algorithms for release 1.5m: - A "To: list-address" in the mail body no longer triggers the loop detector. - "To:"/"Sender:"/"Reply-To:" keywords must now be preceded by a blank or appear in column 1 in order to trigger the loop detector. - An explanatory message is sent along with the rejected mail. This message tells you why LISTSERV thought this was a delivery error notice. - The search in DOMAIN NAMES has been improved. It did not work very will when there were several entries for sub-domains (like .BERKELEY.EDU and .EDU). - There is a new option for the "Loopcheck=" keyword: "None". This suppresses all the loop detection tests, except a few ones that are done at the beginning before LISTSERV determines for which list the mailfile is destined. Needless to say, people who make use of this keyword are responsible for the consequences, and I will not address any loop problem when Loopcheck= None. - There is a new list keyword, 'Sender= List | None | "data"'. The default is LIST and means that the "Sender:" field ought to point to the list. "None" means that NO "Sender:" tag ought to be generated, ie the mail will be seen as coming from the actual mail sender (and he'll get the wonderful "Mail sent" messages). If you specify a quoted string, it will be put AS IS in the "Sender:" field. YOU are responsible to ensure that it is a valid RFC822 mailbox and that it will not cause loops, etc. - The IBM NOTE processor has been simplified to accept almost anything, as long as the first field is "Date:". Other fields may appear in any order, and the contents of the "To:" and "cc:" fields is no longer processed. I have thought this over for about 20 minutes and decided that there is no way to determine whether the format is SHORT or LONG, and after all the contents of these fields are not vital so why bother? Policies about the use of the "Sender=" keyword: - I will not address any kind of loop problem if "Sender=" is not set to LIST. - You should not put someone into a list's "Sender=" field without his EXPLICIT permission. I explicitly state that I do NOT want ANY of my accounts to be put in the "Sender=" field of ANY list, regardless of the reasons, and even for short periods of time. I get enough "* Mail sent to" crap with my own mailings, and I don't want mail from other people to appear as being from me. Now if other list owners don't mind, it's up to them. - The "Sender=" field should contain the very exact same string for all the members of a peered list, except maybe if there is an emergency and you want to change it to see if it stops a loop. Otherwise users will want to subscribe to this or that server because it generates "better" mail. - The list owner is therefore the only person able to decide what should be placed in this field. In particular, the postmaster should NOT change the "Sender=" field of his local peers without permission from the list owner, except in case of emergency. He may of course impose that the change be made or the peer be withdrawn, but this is another story. - When the change is made, it should be announced to the list. It should be stated that it purposeful and it is NOT due to a new version of LISTSERV or a bug or anything. I certainly don't want possible user complaints to land in MY reader. - Note that inter-peer mail always contains a "Sender:" field pointing to the list userid. This is required, it is not a bug and does not imply anything on the destination peer's use of the "Sender:" field. It gets validated and then internally discarded. Future support statements: - Except as noted above, I will only address "bug" problems in the loop detector. I will no longer add tricks with every release to block this or that particular gateway. You will have to convince the gateway author to fix HIS code. Don't even bother to suggest anything, I will just discard it. If you find a bug in the loop detector (eg a missing UPPER), I'll be glad to fix it of course. - 3 weeks after 1.5m is released, I will refuse to answer questions about "why was this mail rejected" unless the site has upgraded to 1.5m. The main reason why I spent over 1h re-designing the loop detector and adding error messages is that I'm now getting 10 such questions a day, and this is getting a bit painful. Some people (mostly list owners) have yet to understand that I'm not a worldwide free user consultancy service :-) Eric