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