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/<domain>/<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][email protected]
     To unsubscribe send an email to [2][email protected]

References

   Visible links
   1. mailto:[email protected]
   2. mailto:[email protected]
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to