Ummm…  I erased the gzip'ed message before sending, which for some strange 
reason invalidated the signature.  2nd try, with both parts ijn a tar…

Sorry for the confusion,
Albrecht.


Am 21.10.17 19:20 schrieb(en) Albrecht Dreß:
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.tar.gz
Description: application/compressed-tar

Attachment: pgpydVB0rJvVc.pgp
Description: PGP signature

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

Reply via email to