https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6582
Kevin A. McGrail <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Kevin A. McGrail <[email protected]> 2011-05-06 21:23:26 UTC --- Is the issue that if binary blobs get into the rendered body, the subsequent scantime is excessive and the DoS is based on time/resources expended? Since the time is slow even with a 148KB attachment, I don't think this issue is "solved" by adding the max size option from spamc to also exist on spamassassin front-end filtering script. Are their MUAs that will display text/* parts inline even if they are binary and us bypassing the scan will allow spam through? It sounds to me like we need a rule that fires if anything outside of ASCII is used in an attachment type of text/plain. If it really has DoS potential, we short-circuit further tests and consider it a malicious format with a 100% positive score from that one rule. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
