fsync (os.File.Sync, really) before responding "250 ok" to DATA.
Otherwise a crash before the queue file is flushed to disk will result in lost mail.
It is possible it is there and I missed it, but I traced through the DATA handling code and queue code reasonably thoroughly.
Thanks for reporting this.
This was an intentional choice a long time ago, and it is reasonable to revisit that decision now.
Currently, the safeio package will use os.Rename to provide atomicity, which works on reasonably modern filesystems. However, it is not strictly durable, so a reboot could potentially leave a file empty empty, and lose mail in transit.
I'll take a look and see how it would be to add an fsync for extra safety. I don't think it should be a problem.
Commit 08273ea90128d08e9a52504a7aaff388642faf68 in the next branch should fix this.
I've added a note mentioning you in the commit message, please let me know if you'd like to be credited in any other way.
I'm going to leave this in the next branch for a while just in case, and eventually merge it into main for the next release.
Thanks again!