On Tue, 12 Jun 2001 11:01:02 CDT, David Devereaux-Weber said:

> Jun 12 10:48:48 cable sendmail[7668]: [ID 801593 mail.info] f5CFmml07668:
> from=<[log in to unmask]>, size=367, class=0, nrcpt]
> Jun 12 10:48:48 cable sendmail[7669]: [ID 801593 mail.info] f5CFmml07669:
> clone f5CFmml07668, owner=owner-listserv
> Jun 12 10:48:49 cable LSV:lsv_amin[7671]: [ID 831251 mail.info] Mail for
> listserv (from 1/1008) delivered to LISTSERV.
> Jun 12 10:48:49 cable sendmail[7669]: [ID 801593 mail.info] f5CFmml07669:
> to="|/usr/local/bin/lsv_amin /opt/listserv/spool listservt
> Jun 12 10:48:49 cable sendmail[7673]: [ID 801593 mail.info] f5CFmnl07673:
> from=<>, size=480, class=0, nrcpts=1, msgid=<200106121548]
> Jun 12 10:48:50 cable sendmail[7674]: [ID 801593 mail.info] f5CFmnl07673:
> to=<[log in to unmask]>, delay=00:00:01, xdelay=00:t
>
> Note that when lsv_amin sends the mail to sendmail (I assume that lsv_amin
> sends to port 25 of localhost), the from address is the null string
> "<>".  That is probably a bad thing.  Can you test this on your system?

There's 2 pieces of mail here.  The first one has queue ID 07668,
and goes SMTP->Sendmail->lsv_amin->$LSVSPOOL, where the lsv process
finds it.  The second has queue ID 07673, and goes lsv->SMTP->Sendmail.

The MAIL FROM:<> is proper - this is discussed in RFC821/1123, and in RFC2821.
It is how Listserv (and other mail subsystems) specify that "this message is
automated, and any bounces should be dropped on the floor to prevent a bounce
message loop".

Let's take this off the lstsrv-l list for now.  Can you send me the *complete*
headers for a mail that shows the problem (I'm particularly interested in
the Received: lines).  I think we're going to have to go through step-by-step
and determine exactly where things are getting corrupted.

/Valdis