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.
Cheers
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:
Hello,
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
Thanks,
