> 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