Applying the wftk: lartmeister.com -- 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:

Spam submission via Web interface
Spam submission via email interface
Scam Website submission via Web interface
Scam Website submission via email interface
Status check on an abuse case
Sending an abuse report
Receiving an abuse report
Closing an abuse case

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:

User arrives at page, pastes spam, clicks Submit button.
A new abuse instance is created and given a unique ID.
The initial-discovery process is started. This consists of:
- Header processing to identify originating IP and/or open relays used to inject the spam.
- Body processing to identify drop boxes, spamvertised Websites, and/or chain letter participants.
- If any IPs or Websites are identified, then an analysis is made of ownership, domain ownership, and upstream.
- If any whitehats are known to be in a position to take action (e.g. a known effective admin found in the perpetrator's upstream) then this is noted.
Spam categorization is also initiated on the body; the aim of this is to categorize the spam.
The initial discovery may take some time, so while it's running, the user is forwarded to a status screen encoded with the unique identifier. This status screen may have an auto-reload on a delay of several seconds, which could be removed after the traceroute (probably the longest segment of initial discovery) is complete.

Spam submission via email interface

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

Submission is received at (e.g.) spam-submit@lartmeister.com
The email is analyzed to find how the spam has been submitted (attachment, in body, mistaken post to the wrong address, etc.) and a new abuse incident created if appropriate. If this step fails, then the submission is placed onto a queue to be manually categorized.
The initial discovery is initiated as above.
A notification response is delivered containing the unique abuse instance identifier and a link to the status page of the incident.

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:

User arrives at page, enters URL of scam site, clicks Submit.
A new abuse instance is created; if the URL is known then the instance is attached to it, but otherwise a new scam site URL is created. Scam sites, once known, are monitored periodically to see if they've been deactivated, reactivated, or modified.
Initial discovery is initiated, consisting of pretty much the same things as spam discovery. Links may also be analyzed, and if several pages are clustered on the site, they may all be cached for future reference. All hosting and upstream ToS's are checked, if known.
The user is directed to a status page, as with spam submission.

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.

Submission is received at (e.g.) site-submit@lartmeister.com
The email is parsed for the submitted URL -- this should be easy, anyway. A unique abuse instance identifier is assigned.
Discovery processes are initiated.
A response is delivered containing the unique identifier and a link to its status page.

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.

User views status page of incident
User may choose between possible further activities: report the incident, close the incident, enter notes or log entries, attach a response received in external email or communication, etc.

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.

The user submits the report, once created.
A copy of the report is attached to the incident.
The report is sent including an envelope and return address unique to the incident; the report explains its provenance and includes a link to the incident status page, which includes all relevant information and case history.
The user can optionally supply a timeout; if the timeout expires before a response is received, the user will be notified and can take further action if 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.

The user is notified immediately of each response, by means of an email containing a link to the incident status page plus a full quote of the response.

Closing an incident

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

User chooses the "close" action from the status page. Note that to close, the user must be a registered user of lartmeister.com, because we don't want random strangers closing cases.
The entire object is archived to some other location; a copy may optionally be sent to the user.

Conclusion

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.

Objects
Abuse incident, user, spam category, spammer, IP, ISP, Website, and so on. Nothing surprising here.
Web interface
At the moment (19 Jan 2002), there is no Web interface for the repository manager or wftk. That will be changing quite soon.
Email client
Same story. While I can imagine that it's not going to take me too long to implement an interface which will allow sendmail to add an object, I haven't actually done it yet. Since the repository manager has a very functional command line, however, it really shouldn't be too involved: essentially this will be a "submit" command with a registered on-add process. Easy.
Tools
The discovery processes will make use of several tools; it will be an interesting thing to think through how those tools should be implemented. I suspect they'll turn out to be query adaptors. We'll see.

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.