http://bugzilla.spamassassin.org/show_bug.cgi?id=3781
------- Additional Comments From [EMAIL PROTECTED] 2004-09-15 20:42 ------- Subject: Re: There should be a rule type for mime part headers > I responded to Chris Santerre's message requesting the plugin (ie: > what kind of information/queries are they looking to do), but have not > received a response. I'm not Chris, but a mime boundary is really a pretty simple thing, for instance: Content-Type: image/gif; name="Vnguku.GIF" Content-Transfer-Encoding: base64 Content-ID: <[EMAIL PROTECTED]@eurekabroadband.com> Content-Disposition: inline; filename="Vnguku.GIF" There just isn't a lot here, and I'd want to treat it as just more header items. Possibly even treating them as though they were part of the main header would be sufficient. But I'd prefer to be able to treat them as individual headers and not agglomerate the contents of identically-named header items into a single string. I can't find a good example in the afternoon's spam collection, and being on a Windoze box it is too much work to hunt around just for an example. But generally I'm interested in the value of Content-Transfer-Encoding, looking for what appear to be bogus values that are being treated as text/plain. The file name can also potentially be useful. Obviously those that want to use SA to strip bogus virus warnings would be interested in this field, since it could be a virus, or it could be a stupid name like "Norton.Deleted" that can be used very easily to tell the message is junk. I'd personally be more interested in looking for things like "CitiLogo.gif", as is typical in a CitiBunk phish. As in all of these things, sometimes knowing the case of the words can be interesting, just as with header items or body items. Thus, semantically, I'd like to treat them as normal header items can be treated. > Since the body mime bits and the binary bits are pretty much the same, I think > getting them together in the same plugin would be fine. The code to look in > the body mime headers is pretty trivial though, so a separate plugin may be > good depending on what is actually desired in such a plugin. This seems not unreasonable. Perhaps a fake 'header' type of Mime-Body or the like could be used to access the first 100 bytes or so of the body by default, or the whole body if Mime-Body:full or some such were specified. I can't immediately see using this myself at the moment, but I wouldn't want to rule it out. It could be useful for looking for something like a signature attachment with a particular value > 1. the MIME-ish "Binary" plugin I'm working on based on MSExec could do > this in addition to what I'm working on now (accessing raw MIME part > data) This seems feasible, if I'm understanding you correctly. > 2. we could clean up the header test types a bit and allow something > like "full" on just the body. I'm not sure I follow this here. While an earlier bug pointed out that the current implementation of rawbody is rather useless, forcing one to use 'full' far too often, I see this as unrelated. I'd much rather not have to scan across the entire message looking for mime header encodings and hope that what I found was really a mime header. Too much chance for an FP, and too hard to do the correct mime part separation in normal rules. SA already knows how to split things into parts, and that should be leveraged. > I think I would probably object to a new core test type for just MIME > part headers. I would not object to them being lumped into the current header tests. Short of that, I'd like the appearence of a new test type, whether that is a new object or a way of using a new eval/plugin. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
