On Mon 27/Feb/2023 12:59:04 +0100 Tobias Fiebig via mailop wrote:
I'd be happy to hear your feedback, especially if things do not work as expected (then, your test ID and ideally stored emails would be really helpful, so i can double check what went wrong).
My DMARC and DKIM results were marked as ⛔ should improve, which particularly surprises me since I set them up carefully. My test ID is czs3fbcsxia2wjrgfqtparq1jpl82t. For DMARC, there is a parsing bug. My DMARC record consists of three concatenated strings, which should be joined as usual. The view shown in the report strips the leading and trailing double quotes, but not the intermediate ones: v=DMARC1; p=none; " "rua=mailto:[email protected]; " "ruf=mailto:[email protected]; Only v= is parsed correctly; p=, rua= and ruf= result as unset. For DKIM, the test requires 2048 bit keys. RFC 8301 says "Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits." According to RFC 2119, that means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. As I carefully weighted the decision to use a small key —0 attacks in several years— I'd have expected an 💡Ok, but watch notes on this. Also, the diagnostic urges me to sign more header fields. Specifically, it says "see RFC6376 Sec. 5.4: content-transfer-encoding:content-type:message-id:mime-version". It is necessary to sign Content-Type: only if the sender signs a limited amount of the body, using l=; in that case, altering Content-Type:, a text/plain message can be turned into the MIME prologue of a multipart message. Otherwise, signing those fields doesn't add a significant guarantee of message integrity. Signing /technical/ fields, as opposed to semantic ones, in my experience irretrievably decrease signature resilience. That is because most mailing lists and other agents disregard the original content of such field. For example, I could not verify fiebig.nl's signature of the message I'm replying to, whose Content-Transfer-Encoding: was changed to base64, while I expect to DKIM verify this message. See this draft[*] for the method to do so.
I would also be interested to hear what you think should be included in addition to the current tests; Some of our plans for the future below as well.
A test I'd like to make, somewhat more intrusive than replying to all, is about DMARC aggregate report correctness. It would require domain owners to provide a target address at their domain. The server would then send a number of messages to that address, some from a domain with strict DMARC policies, some from a low-reputation IP, some with an EICAR test attached, some from non-existent From: domain, and so forth. On the next day, the diagnostic will examine the DMARC report received, if any, and check its correctness, both formal and semantic. Fancy it? Best Ale -- [*] https://www.ietf.org/archive/id/draft-vesely-dmarc-mlm-transform-07.html#name-the-reversion-method _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
