This problem could be a race condition (the mysql server is external, not on the local machine).

I confirmed that the affected items don't have any attributes at all in the database. Trying to send the item again worked flawlessly, so the question is how those items ended up in the outbox without any of the necessary attributes.

We just reproduced the problem on a local system (and that's the first time that I've seen that). The mail has been sent though, and simply reappeared in the outbox without attributes.

item in local outbox: rev3, SEEN flag, size 1656, valid remoteid, no attributes
item in imap sent-mail: rev2, SEEN flag, SENT flag, size 870, no remoteid, has attributes

The id's of the items are different as they should be (with the local item id being greater than the one in the sent-mail folder).

This looks like the maildir resource tries to modify the item (i.e. it always modifies the last-modified timestamp even while reading (probably due to fetching from the backend)), but meanwhile the original item has been moved, which results in the MERGE command creating a new item instead.

One potential root cause could be a race condition during retrieveItems in the maildir resource (the item has been moved in the database, but the change has not been replayed, so the item sync ends up recreating the item that is still found on disk). This scenario aligns with the id of the item in the outbox being greater than the one in the sent mail folder and the missing attributes. It doesn't seem to align with the revision though.

Another potential root cause is a failed move operation:

https://bugs.kde.org/show_bug.cgi?id=357179

There have been reports of mails still not being sent out which was fixed by reopening the mail and sending it again (that is with the version that doesn't remove the stuck messages from the outbox)