Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

strange change of queue id (8.14.4 bug ?)

7 views
Skip to first unread message

Sergey

unread,
Jun 24, 2011, 6:31:11 AM6/24/11
to
Hello.

I found strange information in the log:

$ cat /var/log/mail/all|grep 9564
Jun 22 13:01:02 sendmail[9564]: NOQUEUE: connect from [192.168.32.113]
Jun 22 13:01:02 sendmail[9564]: AUTH: available mech=SRP DIGEST-MD5 OTP CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS, allowed
mech=(null)
Jun 22 13:01:07 sendmail[9564]: p5M912Tv009564: --- 220 gw ESMTP Sendmail 8.14.4/8.14.4; Wed, 22 Jun 2011 13:01:02 +0400
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: <-- EHLO Station1
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-gw Hello [192.168.32.113], pleased to meet you
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-ENHANCEDSTATUSCODES
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-PIPELINING
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-EXPN
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-VERB
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-8BITMIME
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-SIZE 500000000
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-DSN
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-ETRN
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250-DELIVERBY
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: --- 250 HELP
Jun 22 13:01:08 sendmail[9564]: p5M912Tv009564: <-- MAIL FROM:<q...@my.dom> SIZE=584
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: Milter (milter-mailfromd): timeout before data read, where=mail
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: Milter (milter-mailfromd): to error state
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: --- 250 2.1.0 <q...@my.dom>... Sender ok
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: <-- RSET
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: --- 250 2.0.0 Reset state
Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: from=<q...@my.dom>, size=584, class=0, nrcpts=0, proto=ESMTP, daemon=MTA,
relay=[192.168.32.113]
Jun 22 13:02:08 sendmail[9564]: p5M912Tw009564: --- 421 4.4.1 gw Lost input channel from [192.168.32.113]
Jun 22 13:02:08 sendmail[9564]: p5M912Tw009564: lost input channel from [192.168.32.113] to MTA after rset

Last two lines have another queue id. I can not understand it.
Be may a bug here ? This is all log lines with PID 9564 of sendmail.

--
Regards, Sergey.

ska

unread,
Jun 27, 2011, 6:09:13 AM6/27/11
to
On Jun 24, 12:31 pm, Sergey <a_...@sama.ru> wrote:

> Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: --- 250 2.1.0 <q...@my.dom>... Sender ok
> Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: <-- RSET
> Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: --- 250 2.0.0 Reset state
> Jun 22 13:02:08 sendmail[9564]: p5M912Tv009564: from=<q...@my.dom>, size=584, class=0, nrcpts=0, proto=ESMTP, daemon=MTA,
> relay=[192.168.32.113]
> Jun 22 13:02:08 sendmail[9564]: p5M912Tw009564: --- 421 4.4.1 gw Lost input channel from [192.168.32.113]
> Jun 22 13:02:08 sendmail[9564]: p5M912Tw009564: lost input channel from [192.168.32.113] to MTA after rset
>
> Last two lines have another queue id. I can not understand it.

After a ReSET a new transaction starts, hence, it needs to get an
unique queueid. The from=<q.. is the last line of the previous
transaction.

Regards, ska

Sergey

unread,
Jun 27, 2011, 10:48:53 AM6/27/11
to
ska wrote:

> After a ReSET a new transaction starts, hence, it needs
> to get an unique queueid.

Thanks ! I had not thought about it.

--
Regards, Sergey

D. Stussy

unread,
Jun 27, 2011, 2:34:54 PM6/27/11
to
"Sergey" <a_...@sama.ru> wrote in message
news:iua58j$oj$1...@speranza.aioe.org...

> ska wrote:
>
> > After a ReSET a new transaction starts, hence, it needs
> > to get an unique queueid.
>
> Thanks ! I had not thought about it.

Why is that necessary if it knows that there's nothing queued under the ID
abandoned and unused?


ska

unread,
Jun 30, 2011, 4:51:59 AM6/30/11
to
On Jun 27, 8:34 pm, "D. Stussy" <spam+newsgro...@bde-arc.ampr.org>
wrote:

If I were a sendmail developer, I would handle events sequentially:

. There is a RSET commands, hence, purge internal state and open new
transaction
. connection closed, hence, log "lost input channel"

0 new messages