Re: Meaning of auth-worker disconnected message and relation to LMTP 451 errors on Ubuntu

23 Jan 2026 · *What works*

      Hi John,
thank you for the clarification — that helps, and I agree that the
auth-worker disconnect message itself can be disregarded.
To narrow this down further, the consistent behavior I’m seeing is that
everything succeeds up to the point where Dovecot should write the
message to disk, but the actual mailbox write never happens.
*What works*

LMTP connection is established
RCPT is accepted
userdb lookup succeeds and returns:
o valid mailbox path under /var/mail/vmail/
o explicit uid/gid
o quota rule
No errors are logged during authentication or userdb lookup

*What fails*

After the DATA phase, Postfix receives:

                "451 4.3.0 Temporary internal error"

No message is written to disk
No Maildir structure (cur/, new/, tmp/) is created automatically
Manually creating /var/mail/vmail/<domain>/<user>/ (including
Maildir structure) does not change the behavior

*What has been verified*

Ownership and permissions on /var/mail/vmail and subdirectories
match the uid/gid returned by userdb
Parent directories are writable
Disk space and inodes are available
This is a local filesystem (no NFS)
The problem persists even with a freshly created mailbox path

From this, it appears that *Dovecot is blocked or failing internally at
the final delivery/write stage*, but without emitting a more specific
error message.
//Kim
On 2026-01-23 09:12, John Fawcett via dovecot wrote:
...
On 22/01/2026 20:57, Kim Haverblad via dovecot wrote:
...
    Hi dovecot list,
I'm troubleshooting an LMTP delivery issue with Dovecot and would
appreciate clarification on the meaning and impact of the
following log
message, which appears repeatedly during delivery attempts:
    auth-worker(2961): Debug: conn unix:auth-worker (pid=2948,uid=107):
Disconnected: Connection closed (fd=-1)
    Environment
      o OS: Ubuntu (latest LTS, fully up to date)
o Dovecot: distribution package (current version for Ubuntu)
o MTA: Postfix
o Delivery: LMTP to Dovecot
o User database: MySQL (userdb lookup succeeds)
o Mail storage: Maildir
o Quotas: enabled via userdb (quota_rule)
    Context
      o LMTP accepts the recipient and completes userdb lookup
successfully.
o The mailbox path, uid, gid, and quota are correctly returned.
o Postfix later receives a 451 4.3.0 Temporary internal error
after the
DATA phase.
o The above auth-worker ... Disconnected: Connection closed
(fd=-1)
message appears around the same time.
    Questions
     1. Is this Disconnected: Connection closed (fd=-1) message
expected/normal behavior for auth-worker processes once a
lookup is
complete?
2. Under what circumstances would this indicate a real problem
versus a
harmless connection teardown?
3. Could this message itself contribute to, or explain, LMTP 451
4.3.0
Temporary internal error responses?
4. Are there specific auth-worker, LMTP, or debug settings
recommended to
determine whether this disconnect is abnormal?
    So far, authentication and userdb lookups appear clean, and there
are no
explicit permission or quota errors logged, which makes it
unclear whether
this message is relevant to the delivery failure or simply
informational.
Any clarification on how to interpret this log entry -- and how
to confirm
whether it is benign or problematic -- would be greatly appreciated.
    Kind Regards,
    Kim
Hi Kim
that's a debug message. In an installation running without debug
logging you never get to see it. I cannot think of any reason why that
message should be considered an issue. Certainly the 451 error message
is much more indicative of a problem. Also since the error message is
happening after the DATA phase, I would look for an issue that does
not occur in the auth-worker process (even if it potentially could be
triggered by data returned in the user lookups).
If you post the logging of the complete LMTP transaction to the list
someone may be able to identify something else that looks strange. The
info in your email contains little clue to the cause. If privacy is a
concern you can consistently modify email addresses throughout the log
snippet. dovecot -n output could also help too.
John

dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-leave@dovecot.org
Hi John,
thank you for the clarification -- that helps, and I agree that the
auth-worker disconnect message itself can be disregarded.
To narrow this down further, the consistent behavior I'm seeing is that
everything succeeds up to the point where Dovecot should write the message
to disk, but the actual mailbox write never happens.
What works
 o LMTP connection is established
 o RCPT is accepted
 o userdb lookup succeeds and returns:

      o valid mailbox path under /var/mail/vmail/
      o explicit uid/gid
      o quota rule

 o No errors are logged during authentication or userdb lookup
What fails
 o After the DATA phase, Postfix receives:

               "451 4.3.0 Temporary internal error"

 o No message is written to disk
 o No Maildir structure (cur/, new/, tmp/) is created automatically
 o Manually creating /var/mail/vmail/&lt;domain>/&lt;user>/ (including Maildir
   structure) does not change the behavior
What has been verified
 o Ownership and permissions on /var/mail/vmail and subdirectories match
   the uid/gid returned by userdb
 o Parent directories are writable
 o Disk space and inodes are available
 o This is a local filesystem (no NFS)
 o The problem persists even with a freshly created mailbox path
From this, it appears that Dovecot is blocked or failing internally at the
final delivery/write stage, but without emitting a more specific error
message.
//Kim
On 2026-01-23 09:12, John Fawcett via dovecot wrote:
 On 22/01/2026 20:57, Kim Haverblad via dovecot wrote:

       Hi dovecot list,
       I'm troubleshooting an LMTP delivery issue with Dovecot and would
       appreciate clarification on the meaning and impact of the
   following log
       message, which appears repeatedly during delivery attempts:

       auth-worker(2961): Debug: conn unix:auth-worker
   (pid=2948,uid=107):
       Disconnected: Connection closed (fd=-1)

       Environment

         o OS: Ubuntu (latest LTS, fully up to date)
         o Dovecot: distribution package (current version for Ubuntu)
         o MTA: Postfix
         o Delivery: LMTP to Dovecot
         o User database: MySQL (userdb lookup succeeds)
         o Mail storage: Maildir
         o Quotas: enabled via userdb (quota_rule)

       Context

         o LMTP accepts the recipient and completes userdb lookup
   successfully.
         o The mailbox path, uid, gid, and quota are correctly returned.
         o Postfix later receives a 451 4.3.0 Temporary internal error
   after the
           DATA phase.
         o The above auth-worker ... Disconnected: Connection closed
   (fd=-1)
           message appears around the same time.

       Questions

        1. Is this Disconnected: Connection closed (fd=-1) message
           expected/normal behavior for auth-worker processes once a
   lookup is
           complete?
        2. Under what circumstances would this indicate a real problem
   versus a
           harmless connection teardown?
        3. Could this message itself contribute to, or explain, LMTP 451
   4.3.0
           Temporary internal error responses?
        4. Are there specific auth-worker, LMTP, or debug settings
   recommended to
           determine whether this disconnect is abnormal?

       So far, authentication and userdb lookups appear clean, and there
   are no
       explicit permission or quota errors logged, which makes it unclear
   whether
       this message is relevant to the delivery failure or simply
   informational.
       Any clarification on how to interpret this log entry -- and how to
   confirm
       whether it is benign or problematic -- would be greatly
   appreciated.

       Kind Regards,

       Kim

 Hi Kim

 that's a debug message. In an installation running without debug logging
 you never get to see it. I cannot think of any reason why that message
 should be considered an issue. Certainly the 451 error message is much
 more indicative of a problem. Also since the error message is happening
 after the DATA phase, I would look for an issue that does not occur in
 the auth-worker process (even if it potentially could be triggered by
 data returned in the user lookups).

 If you post the logging of the complete LMTP transaction to the list
 someone may be able to identify something else that looks strange. The
 info in your email contains little clue to the cause. If privacy is a
 concern you can consistently modify email addresses throughout the log
 snippet. dovecot -n output could also help too.

 John

 _______________________________________________
 dovecot mailing list -- [1]dovecot@dovecot.org
 To unsubscribe send an email to [2]dovecot-leave@dovecot.org
References
Visible links

mailto:dovecot@dovecot.org
mailto:dovecot-leave@dovecot.org