`dmarc2html` fails

[catap]

as

Dec 27 20:37:04 mx1 smtpd[35753]: 1346581649bf5965 smtp tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 27 20:37:05 mx1 smtpd[86029]: dmarc2html: Traceback (most recent call last):
Dec 27 20:37:05 mx1 smtpd[86029]: dmarc2html:   File "/usr/local/libexec/palant-opensmtpd-filters/venvs/opensmtpd-filters/lib/python3.10/site-packages/opensmtpd_filters/dmarc2html_filter.py", line 43, in convert
Dec 27 20:37:05 mx1 smtpd[86029]: dmarc2html:     raise Exception('Expected one attachment, got {}'.format(len(attachments)))
Dec 27 20:37:05 mx1 smtpd[86029]: dmarc2html: Exception: Expected one attachment, got 0
Dec 27 20:37:05 mx1 smtpd[35753]: 1346581649bf5965 smtp message msgid=a5f441d1 size=4842 nrcpt=1 proto=ESMTP
Dec 27 20:37:05 mx1 smtpd[35753]: 1346581649bf5965 smtp envelope evpid=a5f441d1c8eaf563 from=<kirill.korinsky@icloud.com> to=<dmarc-report@catap.net>

on attached zip from google

google.com!korins.ky!1703548800!1703635199.zip

[catap]

I can easy reproduce that issue by sending this zip from icloud to dmarc's report domain.

[palant]

The problem is not the zip file. It’s not being recognized as an attachment. So: what does the email look like? Maybe you could save it as a .eml file and attach it here. Alternatively, email source code starting with the Content-Type header and ending at the beginning of the ZIP attachment should also do.

[catap]

Sure, here the email: Report domain korins.ky Submitter google.com Report-ID_ 440465233067844141.zip

(github asked me to make a zip from it)

[palant]

Yes, I can confirm that this message cannot be processed correctly. But that’s a message sent by your iCloud account, with complicated structure and multiple nested parts. A regular Google message looks very differently and at least for me is always processed correctly.

I’m looking into whether the parsing logic can be adapted, but I don’t think that this use case justifies making it considerably more complicated than it is now.

[catap]

Indeed it's more complicated.

I simple tried to test that filter O:-)

[palant]

Turned out to be fairly simple after all. I think that it should work even with those iCloud mails now.

[catap]

Something still doesn't right. I've attached resulted email and screenshot how I see it via mail.app:

Report domain korins.ky Submitter google.com Report-ID_ 440465233067844141.zip

[catap]

and Thunderbird show it as it should

[palant]

I suspect that your email client has trouble displaying a multipart/alternate message structured like this. I pushed one more change, feel free to try it.

[catap]

Well... it doesn't help. I still see Content-Type: multipart/alternative header: qqq.zip

Thus, the right structure should be something like this: https://stackoverflow.com/a/66551704

[palant]

My bad. I trusted the documentation here and didn’t actually test. Yet the documentation appears to be incorrect and multipart/alternative isn’t actually being converted.

[palant]

Actually: no, I made a mistake testing this. When testing correctly, the message being produced for me has Content-Type: multipart/mixed. In fact, the email.message code being called here has no code path where Content-Type would remain unchanged. So maybe check again whether you are running the latest version of the code?

[catap]

an example of real life dmarc report with quite complicated strucutre: Report Domain korins.ky Submitter protection.outlook.com Report-ID_ 3fcd42495e724333a793ad0ca6b4950f.zip

[palant]

Not really, these were processed correctly before this change as well – they have multipart/mixed at the top level, so the attachment is found without any trouble. The problem only occurred when the attachment was hidden within a nested structure.