https://bugs.exim.org/show_bug.cgi?id=3040
Jeremy Harris <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|[email protected] |[email protected] Priority|medium |low Target Milestone|Exim 4.97 |Exim 4.98+ --- Comment #1 from Jeremy Harris <[email protected]> --- Worth fixing, even though it's a rather obscure situation. At an initial look, we can make sure to respond 451 rather than 250. We can try to remove the spoolfiles, though the filesystem state is somewhat uncertain at that point. If that works, we won't get a duplicate. Logging is harder. We log message-accept before closing the d-file, because the close release the lock stopping any other process (eg. a queue-runner) picking it up, and we want to know that the log operation succeeded (it could die for a full FS, for example). I don't want to mess with the long-present sequencing. So the best I can think of is to append more logging to say the the message-accept was actually aborted. I think the logging muddle is preferable to a double-deliver. I've placed a commit (f70940c94) in the current 4.next which does that. Seperately, we might consider doing an fdatasync() right after the last fflush(), in an attempt to flush out the specific error observed early enough to sort out the log muddle. I don't know if this will have performance impact, but it does feel right (just on data-security grounds). Dealing with fclose() errors would still need to be done; this is not a replacement. -- You are receiving this mail because: You are on the CC list for the bug. -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/ ## unsubscribe (doesn't require an account): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
