> What we are seeing is the digest build
> toward the specified size (currently 1000 lines). In the majority of
> times that it reaches the 1000 line limit (plus whatever number of
> lines over the limit the last note puts the digest), we are seeing
> two events reported in listserv.log:
> 
> -> RSET
> 421 Error: timeout exceeded
> 
> And the digest is **not** sent out.

Ok, the log I referred to is the one you posted to this list on 2005-03-02,
which shows what I assumed to be regular delivery at midnight. If you have
logs for (missing) exceptional delivery, please send them to me and I will
look at them.

Also, please look up SMTP_FORWARD_1 et seq in go.user and let me know what
they are set to. I would like to double-check that you are using
asynchronous delivery (SMTP workers) and not the old-style synchronous
delivery. My prior remarks were based on the assumption that you do use SMTP
workers.

> If what you are saying is correct, then I have to assume that every
> time a new message comes in after the digest reaches the 1000 line
> limit, Listserv will attempt to send off the digest.

I'm not sure about "will" - the log will tell us more about that - but it
definitely should be doing that.

> So, if Listserv doesn't have an internal counter, is the process that
> Listserv receives a new message, delivers it the SMTP, then adds it
> to the digest, then counts the lines in the digest?

Something like that, not sure of the exact order in 1.8d. This is all done
internally, no external commands like 'wc'. I wouldn't worry too much about
the line count being incorrect, I think what may be happening is that
LISTSERV does not decide to send the digest, for reasons unrelated to the
actual line count.

> And what happens if listserv decides to send the digest, but fails in
> queueing the mail for later delivery?

It will reprocess the digest at the end of the day but, with asynchronous
delivery, it would take something like a disk full condition to make this
happen. LISTSERV just creates a disk file (or several) and sends a signal to
the SMTP workers to wake them up.

  Eric