Forum OpenACS Q&A: Spam Module - Status

Posted by defunct defunct on
Hi All,

Can someone tell me what state/status/plans there are for Spam system.
At the I have a requirement for this kind of thing and therefore
thought I'd use the Spam System as a start point and thus get in some
testing/fixing at the same time.

However I'm not entirely clear whether this package in its current
form is worth continuing with.

The docs are, of course, well out-of-date (unless anyone has more up
to date ones).

In the docs it suggest that by default Spam integrates with
admin/groups/one but that certainly isn't what I'm seeing.

It also talks quite a lot about acs-messaging (and acs-mail). I
remember that acs-messaging is a potential candidate for
'disappearing' therefore if Spam truly relies on this does that
effectively consign Spam in its present for to the bin?

I could figure all this out by trawling the code... but if anyone else
can give me some info it would save me a lot of trouble.

Also, unless I'm missing something obvious, the Spam system appears to
have pretty limited functionality. i.e. it tells acs-mail to send out
an email to a list of users.. supplied in the first instance by a
query that you have to create yourself anyway..

This almost seems so trivial that i may even suggest its not really
worth having a package to cover this, a good API may be more

Are there any plans therefore to change/drop this before I go too much



Posted by Don Baccus on
Open Force is working on spam as part of dotLRN, because it's wholely inadequate for dotLRN's needs.  But I don't know if we'll dump the existing one entirely or not, it's too early to tell.

Spam did - in 3x - integrate with the user search page but apparently that hasn't carried over to 4x.  It would be easy enough to make it do so, though.

If you visit the user admin pages you may find that it does, actually - the integration in 3x was pretty lame.  The page returning user search query results (where you check off conditions or put in dates for "registered before", that kind of thing - an API so you don't have to write your own query) let you spam the found users.

This was done outside the spam package proper.

Then you took a hike over to the spam package to see if it was successfully sent out and all that.

I plan to spend time Saturday looking at as many OpenACS 4.5 beta issues that have been raised as I can, including this one, as well as inspecting and applying patches that have been accumulating (we have such cool people here, fixing things faster than I can apply the patches!)

Posted by Eric Lorenzo on

As Don says, OpenForce is working on revamping the spam module for dotLRN, and to meet the requirements of another client. We're going to be adding some basic templating, so that messages can be personalized, and some features to track clickthroughs from links embedded in the messages. My apologies for the lack of detail here -- we're really just starting on this.

However, having reviewed the current spam module, I'm inclined to agree with you that the current module isn't really worth maintaining, and we won't be building the new system from it. There's not a lot of functionality there.

We're also going to be building this on top of a new mail system. The current acs-mail is pretty complicated and painful to use and maintain. I've started on an acs-mail-lite package that will be checked into OpenACS next week. At first, this package will only provide a simple ns_sendmail like API, but enqueues messages in the database to provide transactionality and reliability. If anyone has any ideas for how to extend this package to provide more powerful facilities without becoming the beast that is acs-mail, I'd love to hear them.

Posted by MaineBob OConnor on

Well, here are some ideas from an earlier threads:

List Software solution for email from OpenACS

Email Autorespoder via AOLserver


Posted by MaineBob OConnor on
Posted by Henry Minsky on
YOu should modify ns_sendmail to take an extra argument, a "sender" address in addition to the "from" address. The current implementation uses the "from" address for both the mail "envelope" as well as the "from:" header. This makes it impossible to do reasonable things like automated bounce checking, error reporting, etc.

The "envelope" address is the email address sent in the SMTP "MAIL FROM" command. This is the email addresss that is used by the mailer at the other end to send error messages back to.
For a proper spam system, this should be set to some magic encoding
of the spam id or destination user id, so you can automatically collect and parse what email addresses are bouncing.