Applying the wftk: -- Use Cases

[ wftk documentation home ] [ lartmeister example home ]

Use Cases

There are a number of ways in which people can interact with the LARTmeister system. We'll ignore the ways which are already afforded by the standard tools (for instance, direct query of objects is provided by the repository manager, so it would add nothing to this presentation to include it here; instead, we will focus on system-specific usage.)

Here are the use cases I'll be working through in this document:

More will doubtlessly present themselves as time goes on. Let's look at these in detail.

Spam submission via Web interface

This is the obvious way to get new content into the database: you provide a screen into which a user can paste a spam email message, including headers. Here's what should happen:

Spam submission via email interface

This would be a handy little tool to take up some of the burden of abuse submissions at; essentially it does exactly the same behind the scenes as Web submission, except that there need be no interactive component.

Scam Website submission via Web interface

Here, the submission isn't an email but rather a Website dedicated to a scam. The process is fairly similar to spam handling:

Scam Website submission via email interface

This may also facilitate submission from automatic sources, like the above email submission, but I don't expect it to be nearly as useful as other submission sources.

Status check

In this scenario, a user checks on the status of an abuse incident. This may be reached from the link in a notification email, or if the user is a registered user then the system may keep a list of open incidents belonging to that user.

Sending an abuse report

Assuming that a reasonable abuse report address has been identified, the system will format a stock abuse report for the user, to which arbitrary text may be added. If the system can't find an abuse address, the user can supply one; the user may also supply any Cc: or Bcc: addresses desired.

Receiving an abuse report response

Responses return via email, of course, and the system routes them to the correct incident using their recipient address. All responses are attached to their incidents automatically.

Closing an incident

If the user is satisfied that an incident is closed, then it can be archived.


There could be any number of additional use cases. For instance, once there are investigatory tools available, those could be exposed for use independent of any abuse case. For instance, a whois query is a nice little tool to have around. Of course, there are already any number of such tools floating around, but as it's no real trouble to provide, it would be logical to include it. But since these "use cases" are essentially peripheral to the core functionality of the site, I'm not going to document them here.

There are a number of system requirements entailed in these cases already. Some are already implemented; others will need a little more work. Let's look at some of them.

Man. Looked at this way, this really shouldn't be so onerous. This document took me roughly an hour to create, on 19 Jan 2002, bringing me to 2.5 hours on the demo project so far.

Copyright (c) 2002
Vivtek. Please see the licensing terms for more information.