Tue, 12 Jun 2001 12:08:24 -0400
|
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
|
|
|