| commit | d91a4bd0c3e75b672352140a07c86c7aa2a16138 | |
| author | Steffen (Daode) Nurpmeso <steffen@sdaoden.eu> | |
| Fri, 4 Nov 2016 22:37:25 +0000 (4 23:37 +0100) | ||
| committer | Steffen (Daode) Nurpmeso <steffen@sdaoden.eu> | |
| Sat, 31 Dec 2016 16:57:46 +0000 (31 17:57 +0100) | ||
| tree | aedbbc585ba7ec4e4d3e84402c4d84cde9ba7259 | treesnapshot (tar.gz zip) |
| parent | 20fb18f61a4ba6869348ea7199c49df2575b91fe | commitdiff |
More or less completely rewrite mime_enc.c..
So that we are now capable to gobble invalid base64 encoding
(embedded garbage, as long as we can synchronize on something
valid later on) and also handle invalid quoted-printable encoding
the very way it is suggested in RFC 2045, section 6.7.
In both cases: except that we, due to lack of a context, cannot
give an error message, say, once per handled message. I.e., we
cannot provide any error logging in order to avoid a possibly
infinite amount of such messages.
Regarding the garbage in base64 parts that we now simply skip.
I mean, it is possible to embed abuse porn or similar shit in
between the valid data, and now we _also_ simply skip over the
"garbage", silently extraditing our users to automatic parsers
which may gobble that s..t!
So that we are now capable to gobble invalid base64 encoding
(embedded garbage, as long as we can synchronize on something
valid later on) and also handle invalid quoted-printable encoding
the very way it is suggested in RFC 2045, section 6.7.
In both cases: except that we, due to lack of a context, cannot
give an error message, say, once per handled message. I.e., we
cannot provide any error logging in order to avoid a possibly
infinite amount of such messages.
Regarding the garbage in base64 parts that we now simply skip.
I mean, it is possible to embed abuse porn or similar shit in
between the valid data, and now we _also_ simply skip over the
"garbage", silently extraditing our users to automatic parsers
which may gobble that s..t!