Ok, will get busy... I also noticed two other issues, one related to ENVID= (should be generated for DSNs), and some data in the DSN's message/delivery-status parts, that must be generated according to eh RFC, when ENVID= or ORCPT= are present, which are not, currently. Will look at those, as well. Might take a few days, though... will keep you posted.


On Wed, Mar 13, 2024 at 11:00:51AM +0000, gil...@poolp.org wrote:
March 13, 2024 10:31 AM, "Tassilo Philipp" <tphil...@potion-studios.com> wrote:


I noticed that DSNs generated by OpenSMTPd use "Content-Type: multipart/mixed", instead of "Content-Type: multipart/report", as defined by RFC3461 (and described in RFC3464 and RFC3462). I wonder if there's a reason for that?

I haven only done a cursory review of the actual multiparts themselves, but they seem to (mostly) follow the mentioned RFCs with for example "Content-Type: text/rfc822-headers". However, if RET=FULL, the content type should be IMHO only "message/rfc822" and not "text/rfc822-headers", the latter seems to be currently used for both, RET=HDRS and RET=FULL. Need to read up on it more to get a clearer picture, though, I just started digging into it.

Either way... I think the RFCs should be followed, want me to prepare a patch?

Yes please, patch and RFC reference so this can be checked too


Reply via email to