Hello. That was fast, thanks.
Wietse Venema wrote in <4g0wjn1gdwzj...@spike.porcupine.org>: |Steffen Nurpmeso: |> Jun 9 01:38:06 postfix/smtpd[17007]: B713116056: client=unknown[45.137\ |> .22.84] ... |> status=sent (delivered to mailbox) | |Postfix delivers an email message with message-id |<20210608163805.e242f6fe5d7ac...@sdaoden.eu> to mailbox. But how can it if the client is unknown, that should normally result in NOQUEUE? |Postfix opens the mailbox file, does an lseek() to the end of the |file, writes the message, flushes the output with fsync(), and |closes the mailbox file before claiming successful delivery. (Mind you i struggled with your words in the release that client certificates via SASL cannot be supported, since dovecot uses the very same mechanism for its own client certificate via SASL.) |Then Postfix sends a delivery status notification. ... |As you figured out the sender has requested NOTIFY=SUCCESS. You can |disable that with instructions in |http://www.postfix.org/DSN_README.html#scope Thanks for that pointer, in postconf i have not found anything regarding notifications. I will read this. |Again, Postfix opens the mailbox file, does an lseek() to the end |of the file, writes the message, flushes the output with fsync(), |and closes the mailbox file before claiming successful delivery. | |As for why the original message is not in the mailbox, that could Well maybe it was automatically spam removed. That could be. |be a race condition in how you access the mailbox (are you rsyncing |mailbox files?), or a race condition bug in the file system that |causes lseek() to see the old file size from before the first message |was delivered. Such race conditions would explain how the status |notification can overwrite the first message. | |What kind file system is this? Not worth looking into this, i looked up the mailbox this afternoon, until then only postfix looks at that. --End of <4g0wjn1gdwzj...@spike.porcupine.org> Viktor Dukhovni wrote in <ymdkzydenbtql...@straasha.imrryr.org>: |On Wed, Jun 09, 2021 at 11:48:45AM -0400, Wietse Venema wrote: | |>> Jun 9 01:38:07 postfix/local[17012]: B713116056: to=<steffen@sdaoden.\ |>> eu>, relay=local, delay=2.1, delays=1.3/0.01/0/0.83, dsn=2.0.0, \ |>> status=sent (delivered to mailbox) |> |> Postfix opens the mailbox file, does an lseek() to the end of the |> file, writes the message, flushes the output with fsync(), and |> closes the mailbox file before claiming successful delivery. | |Potentially relevant: | | $ postconf | grep '_lock ' = | mailbox_delivery_lock = flock, dotlock | virtual_mailbox_lock = fcntl, dotlock That is AlpineLinux/postfix standard, #?0|sdaoden:steffen$ postconf | grep '_lock ' mailbox_delivery_lock = fcntl, dotlock virtual_mailbox_lock = fcntl, dotlock and since only postfix and my mailx access this, we get double security (we fcntl + dotlock, too). |Personally, I don't use "mbox" delivery, only maildir. This is only appending write and then (partial) download plus truncation. I do not manage the mails on the single user server. (Maybe if i would have multiple devices. I think i recall even dovecot switched away from MBOX recently? But for now ... i would not use anything else but (compressed) MBOX for archives. Hm.) |> As for why the original message is not in the mailbox, that could |> be a race condition in how you access the mailbox (are you rsyncing |> mailbox files?), or a race condition bug in the file system that |> causes lseek() to see the old file size from before the first message |> was delivered. Such race conditions would explain how the status |> notification can overwrite the first message. |> |> What kind file system is this? | |Indeed, any lock-related overrides, and is it really mbox rather than |maildir, any why? No no no. Ext3. Ok, i see .. it is because of RCPT is someone known. But how can i enforce .. i had reject_unverified_sender but i removed that again. Hm. I will add reject_unknown_client_hostname to the smtpd_client_restrictions! For postfix the reject_unknown_helo_hostname .. it can simply skip sending HELO/EHLO! Hmm, i see. So anyhow connection address/hostname, helo/ehlo address/hostname, that is all distinct. Ok, then yes, this is solely my fault. Thanks for the correction. A bit dry the humour for a mouse ;) Ciao from Germany! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
