Hi Jeff: In the meantime, I looked into ways to implement the GMime parser error reporting feature. Instead of using a signal emitted by the GMimeParser object, I think it might be better to add a “issue callback” to GMimeParserOptions, as it is also used by many other functions. The attached little patch implements a /very/ basic feasibility demonstration: - add the callback to GMimeParserOptions; - call it from the parser if a duplicated “Content-*” header is detected, and drop the duplicated header; - check for duplicated header parameters in decode_param_list() and keep only the first one. Note that for the latter, it is not possible to report the originating object and parser offset, as it is not passed downstream into the function. Do you have an idea how this could be achieved, without adding extra parameters to all the functions? Maybe add an internal reference to the parser object to GMimeParserOptions? The possibility of removing “evil” headers or parameters should probably be configurable through GMimeParserOptions. If it is activated, it can be used to parse and re-write a sanitised message with a well-known behaviour. Running the attached suspicious message data block (packed, as Balsa would attach it as message/rfc822 otherwise…) through the modified test-parser application, all 6 issues are detected and reported. What do you think about this approach? Should I proceed this way? Cheers, Albrecht.
Attachment:
proposal_error_tracking.diff
Description: Text Data
Attachment:
BADMAIL.gz
Description: application/gzip
Attachment:
pgp_GjacsJPQd.pgp
Description: PGP signature