Heho, > 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. Ok, thanks; Identified and fixed.
> 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. Hm... I see your point. However, I'd go with 'Should improve', kind of sticking with the RFC phrasing here; A (more general) issue, though is the absence of a clear distinction between 'should' level issues, and 'must' level issues (say, missing rDNS alltogether). What should definately be the case is skipping a warning if there is at least one other RSA2048 or ED25519 key. Will fix that. > 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. Hrm, good point. I had initially skipped the approach as in RFC6376; Following that now, i moved all non-signed headers to '💡Ok' (except for from: being signed.) I will spend more time on thinking about a good way to address this. > 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? Would be an awesome idea, and i am noting it down. However, given that there can be a rather strong wind blowing for email measurement setups that originate emails for measurement purposes (i feel the implementation we have now is already a stretch with one potentially unsolicited email being sent), i'll rather skip on that for now. Thanks for the feedback. Will implement the better handling of multiple DKIM signatures and then push. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
