The user interface for the end user is not very robust from the user's point of view. I want some more options.
Basically, I need to see or have access to the raw message at times. I don't really want to release a message I know is spam, all I want is the internal links so I know who the perpetrator of the spam is. For example, I get a Phishing message, and I want to know where you go when you click on the dangerous link.
Here are some options:
1. Allow me to release the one message without marking it as non-spam. I do this because I want to forward it, intact, to an abuse address.
2. Allow me to tell the gateway to forward the message, intact, to the abuse address.
3. Allow me to examine the raw source of the message, so I can copy and paste it into a message (or find the phishing links).
Allowing me to examine the raw headers is one helpful feature, and I like that, but why does the web interface require that it be only three lines long? It should be possible to enlarge that space somehow, perhaps using Ajax-ish technology.
When I release a message, does that tell the interface that I want to receive messages like it? I had one paid subscription that wound up in the Spam list once (part of why I examine all the spam carefully now, rather than trusting that it's all spam, which it is 99.9% of the time) as well as a few other false positives. In each case, I have whitelisted the sender's address because I was not confident that I would never lose another message. There needs to be a 'release, this one is not spam", vs. a 'release, this kind of message is not spam" interface option.
Finally, when I do receive a Spam message that doesn't get filtered, there should be a way to submit it to "spam central" so it can be analyzed. The daily messages I get from the gateway should contain a "mailto:" link to which I can forward those messages. Interestingly, some of those have come directly from "PBL"-positive addresses, so I wonder whether the PBL is used at all in this system?