In the filter-dkimsign readme I suggest to use 2048 and I stand by it. >From RFC1035: <character-string> is a single length octet followed by that number of characters. <character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet).
Followed by: TXT-DATA One or more <character-string>s. An RR has an RDLENGTH of 16 bits, meaning that you can fit about shy of 64k characters in the RR devided over aprox 256 character strings. (not accounting for the maximum DNS packet length). Since you already pointed to RFC6376, also have a look at section 3.6.2.2: Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. So if an implementation were to truncate a DKIM TXT record at the 255 bytes boundry, it is a violation of the RFC and the validator should be fixed. The same goes for SPF, which specifies in RFC7208 section 3.3: As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS record can be composed of more than one string. If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. martijn@ On Sun, 2021-03-28 at 16:46 +0200, Thomas Bohl wrote: > Hello, > > I only recently started to use DKIM and DMARC. (Yesterday to be exact. Now > mails to Gmail go to the inbox and not the spam-folder. Which is nice.) I > started with a 1024 bits RSA key. > > I followed > https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/ > and > https://prefetch.eu/blog/2020/email-server/#dkim > > poolp.org talks in length about why to use a 1024 bits key in order not to > truncate the DNS TXT record. > prefetch.eu uses 2048 bits and talks shortly about why not to use something > bigger. (Which makes sense, since RFC 6376 says that up to 2048 bits MUST be > supported and larger keys only MAY be.) > > Microsoft 365 talks about that 1024 and 2048 bitness is supported, but > defaults to 1024. > https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide#manually-upgrade-your-1024-bit-keys-to-2048-bit-dkim-encryption-keys > > Google Workspace recommends a key with 2048 bits, if your domain host can > manage it. > https://support.google.com/a/answer/174126 > > > I guess my question is: Is the problem with a truncate the DNS TXT record, > as described on poolp.org still a think to worry about, or have think > improved since 2019 and one can unhesitatingly use a > 2048 bits key? > > Thanks for reading > >
