Hello Richard Clayton. Richard Clayton wrote in <[email protected]>: |In message <[email protected]>, Mauro De |Gennaro <[email protected]> writes | |>I went through spec-06, bcp-01 and dns-00 looking for anything about \ |>header size |>limits in bytes and found nothing. | |try RFC5321 and if you cannot find it there then no formal limit exists |and it is not, in my view, appropriate for DKIM2 to set one ... |this does not seem to be a DKIM2 specific issue at all ... |>7.5. Discussion re: Maximum Number and Size of Message-Instance and |>DKIM2-Signature Header Fields | |[..] | |>Many MTAs, mailbox servers and hosted providers limit the size of the |>header section of a message, the size of individual header fields, or |>the number of header lines. | |I think "All" rather than "many" ... |If you are adding 30K of recipes then I rather think you are doing |something dumb and any sensible reputation system is going to dislike |your email ...
I cut here only because it is sufficient for my response. I find you are talking him down, and that seems not appropriate to the problem, may the DKIM2 guys have talked about it at international IETF meetings or not. Just two examples. Today an OpenSSL announcement, which has a 77198 bytes HTML part. If that is reposted through a mailing-list which cuts HTML parts, only leaving text, and which honours DKIM/ACDC or your thing, then you already crossed 104000 bytes by only base64-encoding that, without any recipe. Another example is the bad habit of attaching little images with logos and such, and i have emails of very distinguished excellent universities (beyond me thus), and i can tell you about half a dozen images, and the "Educate. Engage. Inspire." logo alone is ~55KB. If that crosses boundaries which remove images, you again have created a differential change that is over 100 kilobytes in size. Yet another one is those fancy things with logos of american internet giants the names of which you all know, and where accounts are linked also via those logos, so you can single-click on it to get to what the people say there. If some "trusted proof point" is to remove such not-during-work- hours mess, you often also passed the limit of certain MTAs, very likely so. (Not talking about the MIME structural changes, or the patch recipe data.) So the problem is very much real. Yet i think the only option to overcome that blown up, distortet, not honourable, and not truly trustable email infrastructure, is to streamline it in a way that moves decisions beyond cryptographical verifiability up to users, and to create a chain of cryptographical verifiability on the level below users. For this there is no other option, as already was envisioned over twenty years ago, as it seems from looking at original DKIM, yet for whatever reasons never sprung into existance. So the road is "reduce to the max" (not truly in spirit of Saint-Exupéry), and then allow one powerful tool to achieve its task. And that is DKIM/ACDC. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
