http://bugzilla.spamassassin.org/show_bug.cgi?id=3131
------- Additional Comments From [EMAIL PROTECTED] 2004-03-06 23:41 ------- I would be somewhat in favor of #6. It would at least provide the required functionality. However, it has the distinct drawback that it must do the join on every invocation of a text that uses that bodypart, at least as you have diagrammed it. Perhaps some more clever code that would do the join on the first use of the :all functionality within a given mimepart, and would be smart enough to use the existing concatenation if a second test referenced :all (as might quite likely be the case). Part of the problem here is semantic, although the more important part is the actual lack of a suitable item to test. The semantic part is that 'body', at least to me, implies something much greater than a single line or paragraph *of the body*. So the "proper" solution would be to make 'body' mean "all of the decoded body (of the current mimepart)" and 'paragraph' mean what 'body' now actually represents. Of course, while this would be 'proper' it isn't going to fly because of all the tests, both released and developed by others, that would have to change. So the alternative is a new keyword, a new modifier, or possibly a tflags (which I know little about) option. On the subject of deleting 'full', I believe that there currently at least two missing objects to test against. Development of these objects could well eliminate the need for both full and rawbody. The first missing test object is the subject of this report: a full concatenation of the 'body' parts relevent to a single mime part of the message. The primary use for this part would be textual checks that need to span multiple lines, and want the html encoding eliminated before the tests. The second missing part is a de-binhexed, d-printed-quotable, de-base64ed representation of a single mime part. This would be perhaps essentially the concatenation of the rawbody lines for this mimepart. The primary use of this part would be to do html checks that may have to span multiple lines. Note that both of these parts perhaps should retain the newlines, in case those provide appropriate clues to the tests to run on them. A /s is simple enough to use if the newlines are to be ignored. Number of "body:all" parts in a message: There should be one "body' for each processed mimepart. A text-only message will have one body. An html-only message will have one body. A text and html message will have two bodies. A text, html, and binary attachment will still have two bodies, because the binary attachment is discarded. There should NOT be a single 'body' for all mimeparts of the message concatenated. Or if there is, it should be something separate from what is being discussed here. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
