John Levine wrote in <20240430015342.8DF9C89B9BE7@ary.local>: |It appears that Steffen Nurpmeso via Postfix-users <stef...@sdaoden.eu> \ |said: |W> |I did not want to insult you! |>|In mind i had these canon..py snippets |>| |>| def strip_trailing_whitespace(content): |>| return re.sub(b"[\t ]+\r\n", b"\r\n", content) |>| |>| |>| def compress_whitespace(content): |>| return re.sub(b"[\t ]+", b" ", content) |>| |>| ... |>| |>| (x[0].lower().rstrip(), |>| compress_whitespace(unfold_header_value(x[1])).strip() + b"\r\n") |>| for x in headers] |>| |>|These strip()s remove any whitespace, as opposed to [\t ] only. | |If you are complaining that it removes bare \r and \n, those are invalid, |we've repeatedly told you why they're invalid and you're not doing yourself |any favors by continued digging.
No, as i said on the IETF list and now here is that isspace(3) includes several US-ASCII aka lowermost 7-bit of ISO 10646 whitespace characters aside from SPace and HTabulator. You may find it nitpicking, and as i also said dkimpy is the best with that strip() above compared to plain usage of [ascii_]isspace() (rspamd, opendkim) or \s regex (perl thing used by amavisd: last step only on minimal subrange, too). But it is not the "hardcore literal RFC 6376" that the dkim library exim uses implements, or what my thing does. Much worse than the above whitespace thingy is anyway the RFC 5322 parser support of python as such, etc etc. |>In general "all the interoperability problems" are only (as far as |>*i* flew above it) about such whitespace issues. Most dramatical, |>still, by opendkim and rspamd (git repository source). --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) _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
