> In response to Jason's request for people to stop using
> relay.cs.net, I am wondering what else is no longer needed,
> or should be done differently.       /Duane
>
> Below is taken from OHSTVMA's MTPLATE file for MAILER.
>
> ... text deleted ...
 
Duane, Although dropping explicit routing in the mailer profile may help
with the load at relay.prime.com it does not appear to be the cause of the
problem.  Princeton does not do any routing of this sort in the mailer
profile and I was able to find anomolies in what PUCC receives.
 
 
Jason contacted me about the traffic he was seeing coming from PUCC.  I was
able to track all the mail we had delivered to .Prime.COM by scanning the
SMTP logs.  In that mail between 1/3 and 1/2 of the destination addresses
were of the form
 
      [log in to unmask]
 
and most (90%) of these had no visible reason for being routed through
relay.prime.com.  Jason had informed me that relay.cs.net and relay.prime.com
were one and the same, but SMTP always shows the canonical name of the
delivery host in the log, so there were no entries for relay.cs.net.
 
I got lucky while analyzing what was happening.  I stopped SMTP and was able
to find some of the addresses for which I couldn't explain the routing
through relay.prime.com.  They were *ALL* addressed as
 
      [log in to unmask]
 
The addresses I found were being delivered for the AIX-L list (AIX-L@PUCC) so
I was able to verify that these addresses were how the users were registered
on the list.
 
The cause of the problem is historical.  At some time in the past, some (now
but not then) internet connected hosts routed their mail through
relay.cs.net.  Relay.cs.net properly rewrote the header addresses into the
form
 
      [log in to unmask]
 
CSNet was dismantled by the merger with Bitnet USA that formed CREN.  Since
these hosts are now internet connected the addresses in their mail are
 
      [log in to unmask]
 
which does not match with the old addresses and may make it impossible for
these users to unsubscribe.  So the user's can't help with fixing the problem.
 
What needs to be done is for all subscriber addresses of the form
 
      [log in to unmask]
 
to be changed to
 
      [log in to unmask]
 
Does anyone have any suggestions on how this can be done network wide?  Other
than doing it by hand?
 
    John