Hi Jeff: Am 16.10.17 16:01 schrieb(en) Jeffrey Stedfast via balsa-list:
Ah, yes, okay – now I understand better. Different software interprets things differently so when writing software that attempts to filter out viruses and other types of attacks, it might not interpret things exactly the same as the user’s email client.
Exactly. As I mentioned earlier, it's not limited to security appliances, though. Some of my users usually read messages on the iPhone first. If a message looked sane there, [s]he will probably open it carelessly later with Outlook, but the message might be interpreted differently there.
The NUL byte inserted by GMime when decoding base64 content with “=” inside the block (slide 32) looks like a bug to me, though.It might be, I’ll have to look into it a bit more.
See the attached little test code and feed the TEST.txt file into it…
This leads to the question if it would be possible to extract this information from the GMime parser. Although Balsa is probably not a target (due to the regrettably small number of installations and the robustness of Linux), it should be able to display a warning as mentioned above, just in case the user reads the messages using different MUA's (think of IMAP, plus Outlook/iOS/Android/…). But it would be an *extremely* helpful feature for writing some kind of “security scanner”.I think it would be possible, I think the question is mostly how to surface this information in a usable way.
The information about one issue detected by the parser could be a simple set of numerical values, e.g. something like - offset: position within the input stream - scope: e.g. as enum: message header; part header; part body; embedded message header; … - classification: e.g. as enum: rfc violation (like unencoded 8-bit chars in a header, or duplicated boundary parameter, …plus all the stuff g_mime_parser_options_set_*_compliance_mode() controls); strange content (like “=” inside base64 block, unnecessary line folding in headers, …); … - issue code: number Maybe the latter two could be glued together, as to make the approach less complex. Sometimes it is not clear anyway how to classify an issue: Two contradictory Content-Transfer-Encoding headers for one part are against the intentions of RFC 2045, but not explicitly forbidden iirc. For passing the issues to the caller: As GMimeParser is derived from GObject, the most simple way might be a signal the caller can connect to. The callback would receive the three or four values above. This leaves the existing API unchanged and does not introduce any extra memory requirements (like an error stack). The performance penalty (which only applies to messages containing any issues anyway) should be small. And the approach is easily extensible – as to notify about an other issue, just define the enum code, and emit the signal. If you could give me a hint where I should start within your sources, I could try to implement a small (I hope…) example patch for one of the issues addressed by the g_mime_parser_options_set_*_compliance_mode() options as to illustrate the approach. Cheers, Albrecht.
Attachment:
base64_test.c
Description: Text Data
Attachment:
TEST.txt
Description: Text document
Attachment:
pgpm8TAjxcLcU.pgp
Description: PGP signature