Image spam with inline jpeg image
All my rulesets and the LARGO rules are for catching inline png and inline gif. Now I am getting stock spams with images like --=_NextPart_001_000C_01C6BBE8.11C02650-- --=_NextPart_000_000B_01C6BBE8.11BB4450 Content-Type: image/jpeg; name="militarism.jpg" Content-Transfer-Encoding: base64 Content-ID: Thanks Ram
Re: Image spam with inline jpeg image
Ramprasad wrote: All my rulesets and the LARGO rules are for catching inline png and inline gif. Now I am getting stock spams with images like --=_NextPart_001_000C_01C6BBE8.11C02650-- --=_NextPart_000_000B_01C6BBE8.11BB4450 Content-Type: image/jpeg; name="militarism.jpg" Content-Transfer-Encoding: base64 Content-ID: Are you using the updated version OR the one originally posted? http://www.rulesemporium.com/plugins.htm#imageinfo Updates: - added optimization changes by Theo Van Dinter - added jpeg support - added function image_named() - added function image_size_exact() - added function image_size_range() - added function image_to_text_ratio() - dhawal
Re: Image spam with inline jpeg image
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Are you using the updated version OR the one originally posted? > > http://www.rulesemporium.com/plugins.htm#imageinfo can the rules_du_jour script be config'd to pickup plugin updates as well? i'd guess more than just an add to "TRUSTED_RULESETS" would be req'd ... richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iEYEAREDAAYFAkTZ868ACgkQlffdvTZxCMa7CwCeMKs+sGcwrL0/KhwjAMb7YsNj 9KUAn2bcfVaq2UqVu9OUOjKQdUilTwQt =V67N -END PGP SIGNATURE-
Re: Image spam with inline jpeg image
> http://www.rulesemporium.com/plugins.htm#imageinfo > > Updates: > - added optimization changes by Theo Van Dinter > - added jpeg support > - added function image_named() > - added function image_size_exact() > - added function image_size_range() > - added function image_to_text_ratio() > > > - dhawal Thanks. I have updated my servers But still this mail is getting thru http://ecm.netcore.co.in/tmp/imagespam.txt Thanks Ram
Re: Image spam with inline jpeg image
Ramprasad wrote: > > But still this mail is getting thru > http://ecm.netcore.co.in/tmp/imagespam.txt > I tested your mail here with the latest imageinfo.pm and it comes through indeed. The exact same one in .gif (same text, same background) was detected though. It was even my first and only image-spam that got a LARGO score since the install last week, I don't get many of those spams.. Regards Menno -- View this message in context: http://www.nabble.com/Image-spam-with-inline-jpeg-image-tf2079118.html#a5728450 Sent from the SpamAssassin - Users forum at Nabble.com.
RE: Image spam with inline jpeg image
Menno wrote: > Ramprasad wrote: > > > > But still this mail is getting thru > > http://ecm.netcore.co.in/tmp/imagespam.txt > > > I tested your mail here with the latest imageinfo.pm and it comes through > indeed. The exact same one in .gif (same text, same background) > was detected > though. It was even my first and only image-spam that got a LARGO score > since the install last week, I don't get many of those spams.. The OCR plugin hits on this one: Content analysis details: (11.5 points, 5.0 required) pts rule name description -- -- 1.5 SPAMPIC_ALPHA_3Image contains many alphanumeric chars -0.0 NO_RELAYS Informational: message was not relayed via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 10 SPAMPIC_WORDS_4Contains inline spam picture (4+) -0.0 NO_RECEIVEDInformational: message has no Received headers (One might argue that a score of 10 is a bit excessive, but note that this spam escaped all other tests.)
Re: Image spam with inline jpeg image
On Wed, August 9, 2006 16:39, Richard wrote: > > can the rules_du_jour script be config'd to pickup plugin updates as well? > i'd guess more than just an add to "TRUSTED_RULESETS" everyone likes to have sa-update ruledujour now :-) rules_du_jour was done when sa-update did not exists -- Benny
Re: Image spam with inline jpeg image
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 hi, >> can the rules_du_jour script be config'd to pickup plugin updates as well? >> i'd guess more than just an add to "TRUSTED_RULESETS" > > everyone likes to have sa-update ruledujour now :-) i'm sorry, i don't understand that sentence. > rules_du_jour was done when sa-update did not exists are you implying that sa-update replaces rules-du-jour? i though sa-update updates the SA distro's bundled rules, but NOT any additional SARE rules that require rules du jour. - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iEYEAREDAAYFAkTaFCsACgkQlffdvTZxCMY7xgCgouYICT09WzAy1wtxkLeYLnkA O+8An21FfcUpdY2c4pZOCzl5KryzCRHy =Ke4R -END PGP SIGNATURE-
Re: Image spam with inline jpeg image
Richard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 hi, can the rules_du_jour script be config'd to pickup plugin updates as well? i'd guess more than just an add to "TRUSTED_RULESETS" everyone likes to have sa-update ruledujour now :-) i'm sorry, i don't understand that sentence. rules_du_jour was done when sa-update did not exists are you implying that sa-update replaces rules-du-jour? i though sa-update updates the SA distro's bundled rules, but NOT any additional SARE rules that require rules du jour. Would not things like SARE rules be the purpose for channels in sa-update? What other possible purpose could there be for allowing multiple channels other than to update more than the distributed rule set? DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: Image spam with inline jpeg image
On Wed, Aug 09, 2006 at 09:58:19AM -0700, Richard wrote: > > rules_du_jour was done when sa-update did not exists > > are you implying that sa-update replaces rules-du-jour? That depends on what you mean by "replaces". > i though sa-update updates the SA distro's bundled rules, but NOT any > additional SARE rules that require rules du jour. sa-update is a generic tool that lets users download "channels" (ie: bundles of rules/plugins) from anywhere that decides to publish them (requires a certain setup, etc.) At the moment, the only published channel that I know of is updates.spamassassin.org. (all this is in http://wiki.apache.org/spamassassin/RuleUpdates btw) There's nothing stoping the SARE folks from publishing a single or a bunch of channels and getting rid of RDJ in favor of sa-update if they wanted to... There are some benefits either way I suppose, and I'm biased towards sa-update of course. :| -- Randomly Generated Tagline: "I'm nothing ... I'm navel lint ..." - From the movie True Lies pgpJjSSOGUJjO.pgp Description: PGP signature
Re: Image spam with inline jpeg image
- Original Message - From: "Gary Funck" <[EMAIL PROTECTED]> To: Sent: Thursday, August 10, 2006 12:04 AM Subject: RE: Image spam with inline jpeg image Menno wrote: Ramprasad wrote: > > But still this mail is getting thru > http://ecm.netcore.co.in/tmp/imagespam.txt > I tested your mail here with the latest imageinfo.pm and it comes through indeed. The exact same one in .gif (same text, same background) was detected though. It was even my first and only image-spam that got a LARGO score since the install last week, I don't get many of those spams.. The OCR plugin hits on this one: Content analysis details: (11.5 points, 5.0 required) pts rule name description -- -- 1.5 SPAMPIC_ALPHA_3Image contains many alphanumeric chars -0.0 NO_RELAYS Informational: message was not relayed via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 10 SPAMPIC_WORDS_4Contains inline spam picture (4+) -0.0 NO_RECEIVEDInformational: message has no Received headers (One might argue that a score of 10 is a bit excessive, but note that this spam escaped all other tests.) I am only getting 3.0 Content analysis details: (3.0 points, 5.0 required) pts rule name description -- -- 1.5 SPAMPIC_ALPHA_3Image contains many alphanumeric chars -0.0 NO_RELAYS Informational: message was not relayed via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 NO_RECEIVEDInformational: message has no Received headers 1.5 SPAMPIC_WORDS_1Contains inline spam picture (1) Why so?
RE: Image spam with inline jpeg image
Theo wrote (in part): > > sa-update is a generic tool that lets users download > "channels" (ie: bundles > of rules/plugins) from anywhere that decides to publish them > (requires a > certain setup, etc.) At the moment, the only published > channel that I know > of is updates.spamassassin.org. (all this is in > http://wiki.apache.org/spamassassin/RuleUpdates [...] Has anyone considered also supplying new rules in the form of rpm's available via a yum-compatible repository? It'd be nice to have the usual versioning and logging support as well as a central update facility. This could be done as a gateway to sa-update, perhaps providing the updates in other package formats as well.
RE: Image spam with inline jpeg image
On Wed, 9 Aug 2006, Gary Funck wrote: Has anyone considered also supplying new rules in the form of rpm's available via a yum-compatible repository? It'd be nice to have the usual versioning and logging support as well as a central update facility. This could be done as a gateway to sa-update, perhaps providing the updates in other package formats as well. This is purely a philosophical argument, but something seems wrong about the idea of using a package manager to manage volatile data files in /var. - Logan
RE: Image spam with inline jpeg image
Logan Shaw wrote: > On Wed, 9 Aug 2006, Gary Funck wrote: > > Has anyone considered also supplying new rules in the > > form of rpm's available via a yum-compatible repository? > > It'd be nice to have the usual versioning and logging > > support as well as a central update facility. This > > could be done as a gateway to sa-update, perhaps > > providing the updates in other package formats as well. > > This is purely a philosophical argument, but something seems > wrong about the idea of using a package manager to manage > volatile data files in /var. It also has the same problems as sa-update. It's not very useful unless you have one package/channel per ruleset and that is a bit excessive considering that a ruleset is just a single file. >From my perspective, RDJ does a great job of handling the add-on rulesets. It's simple and flexible. Why fix something that isn't broken? -- Bowie
Re: Image spam with inline jpeg image
From: "Theo Van Dinter" <[EMAIL PROTECTED]>
There's nothing stoping the SARE folks from publishing a single or a
bunch of channels and getting rid of RDJ in favor of sa-update if they
wanted to... There are some benefits either way I suppose, and I'm biased
towards sa-update of course. :|
Um, before I make bad presumptions maybe you could fill me in regarding
the update channels. Is EVERYTHING found sourced on a channel loaded
from that channel as rules updates? Or does the user have the option
to select items 1, 3, 4, 5, 7, 9, 12 and so forth? The SARE rules
exist in MANY versions. It's not always advisable to load them all
either by level or by type. There is so much variance in the YMMV
choices to be made that one or even N channels with N less than the
total number of SARE rule sets would work very well.
{^_^}
Re: Image spam with inline jpeg image
From: "Gary Funck" <[EMAIL PROTECTED]>
Theo wrote (in part):
sa-update is a generic tool that lets users download
"channels" (ie: bundles
of rules/plugins) from anywhere that decides to publish them
(requires a
certain setup, etc.) At the moment, the only published
channel that I know
of is updates.spamassassin.org. (all this is in
http://wiki.apache.org/spamassassin/RuleUpdates
[...]
Has anyone considered also supplying new rules in the
form of rpm's available via a yum-compatible repository?
It'd be nice to have the usual versioning and logging
support as well as a central update facility. This
could be done as a gateway to sa-update, perhaps
providing the updates in other package formats as well.
For about a femto-second, perhaps. There is too much YMMV
involved with the SARE rule sets to make it practical as
an rpm solution.
{^_^}
RE: Image spam with inline jpeg image
On Wed, August 9, 2006 22:01, Gary Funck wrote: > could be done as a gateway to sa-update, perhaps > providing the updates in other package formats as well. rpm packages does not install sa-update ? i know yum, but dont make it the better sa-update :-) it was worse enogh with rulesdujour -- Benny
RE: Image spam with inline jpeg image
> > On Wed, 9 Aug 2006, Gary Funck wrote: > > > Has anyone considered also supplying new rules in the > > > form of rpm's available via a yum-compatible repository? > > > It'd be nice to have the usual versioning and logging > > > support as well as a central update facility. This > > > could be done as a gateway to sa-update, perhaps > > > providing the updates in other package formats as well. > > > > This is purely a philosophical argument, but something seems > > wrong about the idea of using a package manager to manage > > volatile data files in /var. > > It also has the same problems as sa-update. It's not very useful > unless you have one package/channel per ruleset and that is a bit > excessive considering that a ruleset is just a single file. > > >From my perspective, RDJ does a great job of handling the add-on > rulesets. It's simple and flexible. Why fix something that isn't > broken? RDJ doesn't work in native Windows. Sa-update does. In my mind, that makes RDJ *broken* if you're running Windows. Bret
RE: Image spam with inline jpeg image
Bret Miller wrote: > > > On Wed, 9 Aug 2006, Gary Funck wrote: > > > > Has anyone considered also supplying new rules in the > > > > form of rpm's available via a yum-compatible repository? > > > > It'd be nice to have the usual versioning and logging > > > > support as well as a central update facility. This > > > > could be done as a gateway to sa-update, perhaps > > > > providing the updates in other package formats as well. > > > > > > This is purely a philosophical argument, but something seems > > > wrong about the idea of using a package manager to manage > > > volatile data files in /var. > > > > It also has the same problems as sa-update. It's not very useful > > unless you have one package/channel per ruleset and that is a bit > > excessive considering that a ruleset is just a single file. > > > > > From my perspective, RDJ does a great job of handling the add-on > > rulesets. It's simple and flexible. Why fix something that isn't > > broken? > > RDJ doesn't work in native Windows. Sa-update does. In my mind, that > makes RDJ *broken* if you're running Windows. RDJ is a bash script. It was written to run on the *nix systems that most people use for SA. It shouldn't be that difficult to create a version that works on Windows. My approach would be to port it to Perl and use LWP to do the file transfers. -- Bowie
Re: Image spam with inline jpeg image
Bowie Bailey wrote: Bret Miller wrote: On Wed, 9 Aug 2006, Gary Funck wrote: Has anyone considered also supplying new rules in the form of rpm's available via a yum-compatible repository? It'd be nice to have the usual versioning and logging support as well as a central update facility. This could be done as a gateway to sa-update, perhaps providing the updates in other package formats as well. This is purely a philosophical argument, but something seems wrong about the idea of using a package manager to manage volatile data files in /var. It also has the same problems as sa-update. It's not very useful unless you have one package/channel per ruleset and that is a bit excessive considering that a ruleset is just a single file. From my perspective, RDJ does a great job of handling the add-on rulesets. It's simple and flexible. Why fix something that isn't broken? RDJ doesn't work in native Windows. Sa-update does. In my mind, that makes RDJ *broken* if you're running Windows. RDJ is a bash script. It was written to run on the *nix systems that most people use for SA. It shouldn't be that difficult to create a version that works on Windows. My approach would be to port it to Perl and use LWP to do the file transfers. I think everyone is missing the point here. This isnt a discussion about porting RDJ to windows or even about RDJ itself. SA now has an application that is similar to RDJ in its function. This is an offical part of SA and not an unsupported (by the SA team) add on. The "if it aint broken, why fix it" argument doesnt apply here as its now being included with SA itself. Its like saying hey look cars now come with seatbelts direct from the factory but im going to rip them out and install someone elses. Theres just no point to it. sa-update can be used to (among other things) replace RDJ. It runs on windows an *nix. Why would anyone spend their time even further developing RDJ, nevermind porting it to another OS when SA now has the same functionality built in? -Jim
RE: Image spam with inline jpeg image
Jim Maul wrote: > Bowie Bailey wrote: > > Bret Miller wrote: > > > > > On Wed, 9 Aug 2006, Gary Funck wrote: > > > > > > Has anyone considered also supplying new rules in the > > > > > > form of rpm's available via a yum-compatible repository? > > > > > > It'd be nice to have the usual versioning and logging > > > > > > support as well as a central update facility. This > > > > > > could be done as a gateway to sa-update, perhaps > > > > > > providing the updates in other package formats as well. > > > > > This is purely a philosophical argument, but something seems > > > > > wrong about the idea of using a package manager to manage > > > > > volatile data files in /var. > > > > It also has the same problems as sa-update. It's not very > > > > useful unless you have one package/channel per ruleset and that > > > > is a bit excessive considering that a ruleset is just a single > > > > file. > > > > > > > > > From my perspective, RDJ does a great job of handling the > > > > > add-on > > > > rulesets. It's simple and flexible. Why fix something that > > > > isn't broken? > > > RDJ doesn't work in native Windows. Sa-update does. In my mind, > > > that makes RDJ *broken* if you're running Windows. > > > > RDJ is a bash script. It was written to run on the *nix systems > > that most people use for SA. > > > > It shouldn't be that difficult to create a version that works on > > Windows. My approach would be to port it to Perl and use LWP to do > > the file transfers. > > > > I think everyone is missing the point here. This isnt a discussion > about porting RDJ to windows or even about RDJ itself. > > SA now has an application that is similar to RDJ in its function. > This is an offical part of SA and not an unsupported (by the SA team) > add on. The "if it aint broken, why fix it" argument doesnt apply > here as its now being included with SA itself. Its like saying hey > look cars now come with seatbelts direct from the factory but im > going to rip them out and install someone elses. Theres just no > point to it. sa-update can be used to (among other things) replace > RDJ. It runs on windows an *nix. Why would anyone spend their time > even further developing RDJ, nevermind porting it to another OS when > SA now has the same functionality built in? It doesn't really matter to me who supports which pieces as long as they all work. Someone may be able to fix sa-update so that it can take over from RDJ, but as of now, that is not possible without configuring about 62 sa-update channels (one for each ruleset RDJ manages). -- Bowie
Re: Image spam with inline jpeg image
Bowie Bailey wrote: It doesn't really matter to me who supports which pieces as long as they all work. Someone may be able to fix sa-update so that it can take over from RDJ, but as of now, that is not possible without configuring about 62 sa-update channels (one for each ruleset RDJ manages). True, but doesnt that make more sense than having 2 separate programs which both pull down updated rules for SA, but from 2 different locations? -Jim
RE: Image spam with inline jpeg image
Jim Maul wrote: > Bowie Bailey wrote: > > > It doesn't really matter to me who supports which pieces as long as > > they all work. > > > > Someone may be able to fix sa-update so that it can take over from > > RDJ, but as of now, that is not possible without configuring about > > 62 sa-update channels (one for each ruleset RDJ manages). > > True, but doesnt that make more sense than having 2 separate programs > which both pull down updated rules for SA, but from 2 different > locations? Possibly. It depends on the overhead involved in setting up the channels. -- Bowie
RE: Image spam with inline jpeg image
> -Original Message- > From: Bowie Bailey [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 2:45 PM > To: users@spamassassin.apache.org > Subject: RE: Image spam with inline jpeg image > > Possibly. It depends on the overhead involved in setting up > the channels. > Plus, not all of us want ALL 62 files! Some of the *[0-3] files say to use 70_abcd0.cf , or _1, or_2, or_3. Would need tome cf file for sa-update to decide which of the 62 files we want, and it could be per site. (some sites with huge email volume might want to cur down on sa/perl overhead) > -- > Bowie > >
RE: Image spam with inline jpeg image
Michael Scheidell wrote: > From: Bowie Bailey [mailto:[EMAIL PROTECTED] > > > > Possibly. It depends on the overhead involved in setting up the channels. > > Plus, not all of us want ALL 62 files! > > Some of the *[0-3] files say to use 70_abcd0.cf , or _1, or_2, or_3. > > Would need tome cf file for sa-update to decide which of the 62 files > we want, and it could be per site. > (some sites with huge email volume might want to cur down on sa/perl > overhead) Right. Since there is currently no way to tell sa-update to get only certain files from a channel, you would need 62 sa-update channels in order to have the same flexibility you currently have with RDJ. Each channel would contain a single .cf file and you can pick which channels to use. -- Bowie
Re: Image spam with inline jpeg image
Bowie Bailey wrote: Michael Scheidell wrote: From: Bowie Bailey [mailto:[EMAIL PROTECTED] Possibly. It depends on the overhead involved in setting up the channels. Plus, not all of us want ALL 62 files! Some of the *[0-3] files say to use 70_abcd0.cf , or _1, or_2, or_3. Would need tome cf file for sa-update to decide which of the 62 files we want, and it could be per site. (some sites with huge email volume might want to cur down on sa/perl overhead) Right. Since there is currently no way to tell sa-update to get only certain files from a channel, you would need 62 sa-update channels in order to have the same flexibility you currently have with RDJ. Each channel would contain a single .cf file and you can pick which channels to use. What if the channel contained all rule files but the default channel .cf would not include any of them. Then the user could add a file to their local rules directory that included just the files they want. It might look something like: include /var/lib/spamassassin/version/updates_rulesemporium_com/70_sare_html0.cf ... That's a little messy so perhaps SA could add a new include directive that looks in the local state directory. Something like: include_state updates_rulesemporium_com/70_sare_html0.cf
RE: Image spam with inline jpeg image
Perhaps it could be as simple as only updating existing rules for your installation? In other words, you would have to download the CF file and install it first (but you would do this anyways to test!!!). Then sa-update could simply parse your rules directory and update rules found there accordingly. The only catch I see is 'locking' a particular CF rule file which could be addressed perhaps by a file preface? -Original Message- Stuart Johnston wrote: What if the channel contained all rule files but the default channel .cf would not include any of them. Then the user could add a file to their local rules directory that included just the files they want. It might look something like: include /var/lib/spamassassin/version/updates_rulesemporium_com/70_sare_html0.cf ... That's a little messy so perhaps SA could add a new include directive that looks in the local state directory. Something like: include_state updates_rulesemporium_com/70_sare_html0.cf
Re: Image spam with inline jpeg image
From: "Jim Maul" <[EMAIL PROTECTED]>
Bowie Bailey wrote:
It doesn't really matter to me who supports which pieces as long as
they all work.
Someone may be able to fix sa-update so that it can take over from
RDJ, but as of now, that is not possible without configuring about 62
sa-update channels (one for each ruleset RDJ manages).
True, but doesnt that make more sense than having 2 separate programs
which both pull down updated rules for SA, but from 2 different locations?
Nor does it make sense to use a tool, even if supplied with SpamAssassin,
that is broken for performing updates.
So build a tool for yourself.
{^_-}
Re: Image spam with inline jpeg image
On 8/11/2006 12:02 AM, jdow wrote: From: "Jim Maul" <[EMAIL PROTECTED]> Bowie Bailey wrote: It doesn't really matter to me who supports which pieces as long as they all work. Someone may be able to fix sa-update so that it can take over from RDJ, but as of now, that is not possible without configuring about 62 sa-update channels (one for each ruleset RDJ manages). True, but doesnt that make more sense than having 2 separate programs which both pull down updated rules for SA, but from 2 different locations? Nor does it make sense to use a tool, even if supplied with SpamAssassin, that is broken for performing updates. So build a tool for yourself. I, myself, wouldn't call sa-update broken. Adding the each ruleset (one line) to a channel file doesn't seem like a big inconvenience. Creating the update channels is also pretty trivial. I've been automatically creating (and updating only when necessary) channels for all the SARE rules for a few weeks now with a script that, for comparison, is 1/9th the size of the rules_du_jour script. Daryl
Re: Image spam with inline jpeg image
jdow writes: > From: "Jim Maul" <[EMAIL PROTECTED]> > > > Bowie Bailey wrote: > > > >> It doesn't really matter to me who supports which pieces as long as > >> they all work. > >> > >> Someone may be able to fix sa-update so that it can take over from > >> RDJ, but as of now, that is not possible without configuring about 62 > >> sa-update channels (one for each ruleset RDJ manages). > >> > > > > True, but doesnt that make more sense than having 2 separate programs > > which both pull down updated rules for SA, but from 2 different locations? > > Nor does it make sense to use a tool, even if supplied with SpamAssassin, > that is broken for performing updates. what's the "broken" part? --j.
Re: Image spam with inline jpeg image
On Fri, 11 Aug 2006, Justin Mason wrote: jdow writes: Nor does it make sense to use a tool, even if supplied with SpamAssassin, that is broken for performing updates. what's the "broken" part? Well, this may not qualify as broken, but I would say it's an undesirable behavior that, upon successful download of the new set of rules, it immediately deletes your old set of rules. What happens if the new set is broken? There's no easy way to revert to the last known good state. I would prefer a system where it downloads every update to a new directory, then just changes a symlink to point to the newest one, leaving the old one in place in case you want to revert. Of course, this would require a system for expiring old updates (since you don't want to have 100 copies of the rules sitting around), but that shouldn't be too hard. - Logan
RE: Image spam with inline jpeg image
> On Fri, 11 Aug 2006, Justin Mason wrote: > > jdow writes: > > >> Nor does it make sense to use a tool, even if supplied > with SpamAssassin, > >> that is broken for performing updates. > > > what's the "broken" part? > > Well, this may not qualify as broken, but I would say it's an > undesirable behavior that, upon successful download of the new > set of rules, it immediately deletes your old set of rules. > What happens if the new set is broken? There's no easy way > to revert to the last known good state. > > I would prefer a system where it downloads every update to a new > directory, then just changes a symlink to point to the newest > one, leaving the old one in place in case you want to revert. > Of course, this would require a system for expiring old updates > (since you don't want to have 100 copies of the rules sitting > around), but that shouldn't be too hard. Symlinks aren't so easy when you're trying to be cross-platform. But they could easily tgz the ruleset to an archive subfolder using the old version number prior to replacing the rule set... At least for those people who are really sensitive about the update process. Note that the rules are only updated if they lint properly first. You could always add a bz ticket for the feature... I'm just happy that the tool actually works on Windows. Bret
Re: Image spam with inline jpeg image
Bret Miller writes: > > On Fri, 11 Aug 2006, Justin Mason wrote: > > > jdow writes: > > > > >> Nor does it make sense to use a tool, even if supplied > > with SpamAssassin, > > >> that is broken for performing updates. > > > > > what's the "broken" part? > > > > Well, this may not qualify as broken, but I would say it's an > > undesirable behavior that, upon successful download of the new > > set of rules, it immediately deletes your old set of rules. > > What happens if the new set is broken? There's no easy way > > to revert to the last known good state. > > > > I would prefer a system where it downloads every update to a new > > directory, then just changes a symlink to point to the newest > > one, leaving the old one in place in case you want to revert. > > Of course, this would require a system for expiring old updates > > (since you don't want to have 100 copies of the rules sitting > > around), but that shouldn't be too hard. > > Symlinks aren't so easy when you're trying to be cross-platform. But > they could easily tgz the ruleset to an archive subfolder using the old > version number prior to replacing the rule set... At least for those > people who are really sensitive about the update process. Note that the > rules are only updated if they lint properly first. > > You could always add a bz ticket for the feature... actually, that's really not a bad idea ;) could you do that? > I'm just happy that the tool actually works on Windows. cool ;) I'm amazed GPG does. --j.
RE: Image spam with inline jpeg image
> Bret Miller writes: > > > On Fri, 11 Aug 2006, Justin Mason wrote: > > > > jdow writes: > > > > > > >> Nor does it make sense to use a tool, even if supplied > > > with SpamAssassin, > > > >> that is broken for performing updates. > > > > > > > what's the "broken" part? > > > > > > Well, this may not qualify as broken, but I would say it's an > > > undesirable behavior that, upon successful download of the new > > > set of rules, it immediately deletes your old set of rules. > > > What happens if the new set is broken? There's no easy way > > > to revert to the last known good state. > > > > > > I would prefer a system where it downloads every update to a new > > > directory, then just changes a symlink to point to the newest > > > one, leaving the old one in place in case you want to revert. > > > Of course, this would require a system for expiring old updates > > > (since you don't want to have 100 copies of the rules sitting > > > around), but that shouldn't be too hard. > > > > Symlinks aren't so easy when you're trying to be cross-platform. But > > they could easily tgz the ruleset to an archive subfolder > using the old > > version number prior to replacing the rule set... At least for those > > people who are really sensitive about the update process. > Note that the > > rules are only updated if they lint properly first. > > > > You could always add a bz ticket for the feature... > > actually, that's really not a bad idea ;) could you do that? http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5042 > > > I'm just happy that the tool actually works on Windows. > > cool ;) I'm amazed GPG does. I am too, but it works surprisingly well with GPG for Windows. ;) Bret
Re: Image spam with inline jpeg image
On Fri, Aug 11, 2006 at 10:14:46AM -0500, Logan Shaw wrote: > What happens if the new set is broken? There's no easy way > to revert to the last known good state. sa-update lint checks the new files in a separate temp area before installing them into the real directory. Only if lint succeeds (which is also, of course, after verifying the sha1 and (by default) gpg signatures of the update file), will the currently installed channel files be removed and the new files installed. So there's no reverting involved for a "broken" update file. Note: "broken" means an update file which has errors in it. This algorithm doesn't address someone publishing valid config files that don't do what the publisher expected, ie: only empty or commented config files, no files, or . IMO, channel publishing QA is really outside the scope of sa-update. -- Randomly Generated Tagline: Turnaucka's Law: The attention span of a computer is only as long as its electrical cord. pgpt4N6mOwPg1.pgp Description: PGP signature
Re: Image spam with inline jpeg image
Bret Miller wrote: Bret Miller writes: On Fri, 11 Aug 2006, Justin Mason wrote: jdow writes: Nor does it make sense to use a tool, even if supplied with SpamAssassin, that is broken for performing updates. what's the "broken" part? Well, this may not qualify as broken, but I would say it's an undesirable behavior that, upon successful download of the new set of rules, it immediately deletes your old set of rules. What happens if the new set is broken? There's no easy way to revert to the last known good state. I would prefer a system where it downloads every update to a new directory, then just changes a symlink to point to the newest one, leaving the old one in place in case you want to revert. Of course, this would require a system for expiring old updates (since you don't want to have 100 copies of the rules sitting around), but that shouldn't be too hard. Symlinks aren't so easy when you're trying to be cross-platform. But they could easily tgz the ruleset to an archive subfolder using the old version number prior to replacing the rule set... At least for those people who are really sensitive about the update process. Note that the rules are only updated if they lint properly first. You could always add a bz ticket for the feature... actually, that's really not a bad idea ;) could you do that? http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5042 I'm just happy that the tool actually works on Windows. cool ;) I'm amazed GPG does. I am too, but it works surprisingly well with GPG for Windows. ;) Bret I think a status report would be a good option as well. SA already asks you for your admins email address at install time. Sending a report of what happened during the sa-update process would be very, very valuable. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: Image spam with inline jpeg image
On Fri, Aug 11, 2006 at 11:56:00AM -0400, DAve wrote: > I think a status report would be a good option as well. SA already asks > you for your admins email address at install time. Sending a report of > what happened during the sa-update process would be very, very valuable. Hrm. I'd say feel free to open a BZ ticket about that. I have certain initial issues wrt implementation, but it's not a bad idea. -- Randomly Generated Tagline: "The most useful pieces of engineering that you'll probably ever have to do will be to thwart some lawyer somewhere..." - Prof. Vaz pgpVjU9DAFD6V.pgp Description: PGP signature
Re: Image spam with inline jpeg image
Theo Van Dinter wrote: On Fri, Aug 11, 2006 at 11:56:00AM -0400, DAve wrote: I think a status report would be a good option as well. SA already asks you for your admins email address at install time. Sending a report of what happened during the sa-update process would be very, very valuable. Hrm. I'd say feel free to open a BZ ticket about that. I have certain initial issues wrt implementation, but it's not a bad idea. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5043 DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: Image spam with inline jpeg image
From: "Logan Shaw" <[EMAIL PROTECTED]>
On Fri, 11 Aug 2006, Justin Mason wrote:
jdow writes:
Nor does it make sense to use a tool, even if supplied with SpamAssassin,
that is broken for performing updates.
what's the "broken" part?
Well, this may not qualify as broken, but I would say it's an
undesirable behavior that, upon successful download of the new
set of rules, it immediately deletes your old set of rules.
What happens if the new set is broken? There's no easy way
to revert to the last known good state.
I would prefer a system where it downloads every update to a new
directory, then just changes a symlink to point to the newest
one, leaving the old one in place in case you want to revert.
Of course, this would require a system for expiring old updates
(since you don't want to have 100 copies of the rules sitting
around), but that shouldn't be too hard.
One would presume an intelligent system for doing such updates would
play directory rename tricks or simply copy off active rules to an
archive directory so that if a "spamassasssin --lint" fails on the
newly downloaded files recovery could be effected easily. One would
further presume that update would do this. Is this cyberunit faulty
for making this presumption?
{^_-}/2
Re: Image spam with inline jpeg image
From: "Justin Mason" <[EMAIL PROTECTED]>
jdow writes:
From: "Jim Maul" <[EMAIL PROTECTED]>
> Bowie Bailey wrote:
>
>> It doesn't really matter to me who supports which pieces as long as
>> they all work.
>>
>> Someone may be able to fix sa-update so that it can take over from
>> RDJ, but as of now, that is not possible without configuring about 62
>> sa-update channels (one for each ruleset RDJ manages).
>>
>
> True, but doesnt that make more sense than having 2 separate programs
> which both pull down updated rules for SA, but from 2 different locations?
Nor does it make sense to use a tool, even if supplied with SpamAssassin,
that is broken for performing updates.
what's the "broken" part?
Channels "sounds" like a most awkward way of putting it all together.
I figure two tools is not a bad thing. I have my working RDJ substitute
(created more or less synchronously with RDJ) so I figure to continue
using it and use update only for the SA native rules.
One thing concerns me - if both SARE and native rules are dynamically
changing managing scores becomes "awkward" to say the least when rules
overlap.
{^_^}
RE: Image spam with inline jpeg image
--On Wednesday, August 09, 2006 3:54 PM -0500 Logan Shaw <[EMAIL PROTECTED]> wrote: This is purely a philosophical argument, but something seems wrong about the idea of using a package manager to manage volatile data files in /var. The problem is not the use of the package manager but the placement of non-volatile files in /var. An update need not be considered "volatile", at least not any more so than a regular package update.
Re: Image spam with inline jpeg image
--On Wednesday, August 09, 2006 7:33 PM -0700 jdow <[EMAIL PROTECTED]> wrote: For about a femto-second, perhaps. There is too much YMMV involved with the SARE rule sets to make it practical as an rpm solution. True, this is the real problem with packaging SARE: There's no clear separation of configuration so that a single update package can serve all users.
Re: Image spam with inline jpeg image
On Fri, 11 Aug 2006, Kenneth Porter wrote: > --On Wednesday, August 09, 2006 7:33 PM -0700 jdow <[EMAIL PROTECTED]> > wrote: > > > For about a femto-second, perhaps. There is too much YMMV > > involved with the SARE rule sets to make it practical as > > an rpm solution. > > True, this is the real problem with packaging SARE: There's no > clear separation of configuration so that a single update package > can serve all users. How about: install ALL of the current SARE rules into a directory that SA does not look at (/usr/lib/SARE perhaps?), and set up RDJ or whatever to update them there, and in order to use a particular SARE ruleset the admin goes into the SA config directory and creates a symlink to the desired ruleset file(s). You could even write a pointy-clicky-gooey thingy to put a pretty face on activating/deactivating the rulesets: a list of the available rules, with their descriptions, caveats, masscheck results, and so forth, and a checkbox that indicates whether or not a symlink exists to expose that rule to SA. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- People seem to have this obsession with objects and tools as being dangerous in and of themselves, as though a weapon will act of its own accord to cause harm. A weapon is just a force multiplier. It's *humans* that are (or are not) dangerous. ---
RE: Image spam with inline jpeg image
> >>> Nor does it make sense to use a tool, even if supplied > with SpamAssassin, > >>> that is broken for performing updates. > > > >> what's the "broken" part? > > > > Well, this may not qualify as broken, but I would say it's an > > undesirable behavior that, upon successful download of the new > > set of rules, it immediately deletes your old set of rules. > > What happens if the new set is broken? There's no easy way > > to revert to the last known good state. > > > > I would prefer a system where it downloads every update to a new > > directory, then just changes a symlink to point to the newest > > one, leaving the old one in place in case you want to revert. > > Of course, this would require a system for expiring old updates > > (since you don't want to have 100 copies of the rules sitting > > around), but that shouldn't be too hard. > > One would presume an intelligent system for doing such updates would > play directory rename tricks or simply copy off active rules to an > archive directory so that if a "spamassasssin --lint" fails on the > newly downloaded files recovery could be effected easily. One would > further presume that update would do this. Is this cyberunit faulty > for making this presumption? Sa-update lints prior to updating, and updates only if the rules lint successfully. Bret
Re: Image spam with inline jpeg image
From: "Bret Miller" <[EMAIL PROTECTED]>
>>> Nor does it make sense to use a tool, even if supplied
with SpamAssassin,
>>> that is broken for performing updates.
>
>> what's the "broken" part?
>
> Well, this may not qualify as broken, but I would say it's an
> undesirable behavior that, upon successful download of the new
> set of rules, it immediately deletes your old set of rules.
> What happens if the new set is broken? There's no easy way
> to revert to the last known good state.
>
> I would prefer a system where it downloads every update to a new
> directory, then just changes a symlink to point to the newest
> one, leaving the old one in place in case you want to revert.
> Of course, this would require a system for expiring old updates
> (since you don't want to have 100 copies of the rules sitting
> around), but that shouldn't be too hard.
One would presume an intelligent system for doing such updates would
play directory rename tricks or simply copy off active rules to an
archive directory so that if a "spamassasssin --lint" fails on the
newly downloaded files recovery could be effected easily. One would
further presume that update would do this. Is this cyberunit faulty
for making this presumption?
Sa-update lints prior to updating, and updates only if the rules lint
successfully.
Bret, I'd have been utterly astonished if it didn't.
{^_-}
RE: Image spam with inline jpeg image
> -Original Message- > From: jdow [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 09, 2006 7:33 PM > Gary Funck wrote: > > Has anyone considered also supplying new rules in the > > form of rpm's available via a yum-compatible repository? > > It'd be nice to have the usual versioning and logging > > support as well as a central update facility. This > > could be done as a gateway to sa-update, perhaps > > providing the updates in other package formats as well. > > For about a femto-second, perhaps. There is too much YMMV > involved with the SARE rule sets to make it practical as > an rpm solution. I agree there's lots of room for variation, but for the rpm-minded, perhaps it'd make sense to have have a small number of pre-config'd packages - something like: (1) conservative, (2) aggressive, and (3) kitchen sink. Alternatively, perhaps the install of the rpm could be pre-conditioned by a config. file [not something that appeals to me, but possible]. I think offering a few canned packages is doable and probably would meet the 80/20 criteria for most users.
RE: sa-update broken? (was Image spam with inline jpeg image)
> On Fri, Aug 11, 2006 at 10:14:46AM -0500, Logan Shaw wrote: > > What happens if the new set is broken? There's no easy way > > to revert to the last known good state. > > sa-update lint checks the new files in a separate temp area before > installing them into the real directory. Only if lint succeeds > (which is also, of course, after verifying the sha1 and (by default) > gpg signatures of the update file), will the currently > installed channel > files be removed and the new files installed. > > So there's no reverting involved for a "broken" update file. Note: > "broken" means an update file which has errors in it. This algorithm > doesn't address someone publishing valid config files that don't do > what the publisher expected, ie: only empty or commented config files, > no files, or . IMO, channel > publishing QA is really outside the scope of sa-update. I agree, really. But I probably trust updates way more than most admins do. (At least that's the feeling I get.) And if someone updates a channel with a set of rules that lints but doesn't work right, they can just re-release the old set as a new version and tell us to re-update. But adding the option to archive will make at least some people more comfortable with running sa-update. So I added the bz ticket. We'll see where it goes. Bret
Re: sa-update broken? (was Image spam with inline jpeg image)
I received/responded to this privately before it was also sent to the list, so paraphrasing below... On Fri, Aug 11, 2006 at 08:45:43AM -0700, Bret Miller wrote: > But adding the option to archive will make at least some people more > comfortable with running sa-update. So I added the bz ticket. We'll see > where it goes. Yeah, I just wanted to make sure people understood that sa-update does a bunch of things to try protecting the current installation before putting a new update in place. It's more than "download a file, delete the current directory, untar the file, exit." :) -- Randomly Generated Tagline: "Leary ate psilocybin cubensis in Cuernavaca and saw the beauty of the universe; I ate goulash and saw the suckage of IT management. We both drank crappy beer. You be the judge." - Benjy Feen pgp2uV3hTxiV7.pgp Description: PGP signature
