|Peter Hofmann <[email protected]> wrote: | $ LC_ALL=C PERL5OPT= perl -CS -e 'print "\x{101D0}" x 100' | | MAILRC=/dev/null LC_ALL=en_US.UTF-8 s-nail -nvvd \ | -Ssendcharsets=utf8 -s testsub ./LETTER | ||qp_encode_calc_size() returns 1203 which is not enough. It should return ||at least 1233: Every input byte is encoded as three bytes (= 1200). This ||will span ceil(1200 / 76) = 16 lines, so we get an additional 30 bytes ||because every line break is "=\n". At the end of the encoded string, ||there might be a "=\n" as well, so add another 2. Including the NUL ||terminator, we end up at 1233.
P.S.: of course such content should not end up in quoted-printable encoding at all, but some kind of "automatic chosing the right one", and then base64 (and in case "8bit" isn't used). S-nail should be able to provide an "auto" encoding that will inspect the first xy bytes / lines of data and decide based upon content wether quoted-printable or base64 encoding is the better choice. Unfortunately this would be too hard and complicated to do today, but should be easy with the chain-based implementation that should come in v15.0 (what i hope). And the list has again seen that Subject: mangling... Maybe i get my head around the problem in S-nail that causes this.. Python bug in mailman? --steffen ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ S-nail-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/s-nail-users
