Agreed - this will allow easier reporting to Knujon etc. in addition to SpamCop (something I have to use hMailServer locally to achieve currently). Something it may be worth considering for each destination address is whether to connect via the local SMTP server or directly to the destination SMTP server (similar to the bounce options "Use remote SMTP servers only", "Use local SMTP server only" and "Use remote with local fallback").
The reasons for wanting to connect directly: some ISP SMTP servers have spam filtering (preventing messages getting through or potentially getting an account shut down for sending spam), or may also have limits on the number of messages that can be sent (in 1 session or specific timeframe).
The reasons for wanting to connect via ISP SMTP server: some ISPs block connections to any SMTP servers other than their own, and some recipients block incoming connections from IP ranges known to be public consumer IP ranges.

Something else to consider (may be separate suggestion) is whether to delegate reporting to a separate background process i.e. MW could add items to report to the queue then immediately be able to perform other tasks (processing, checking etc.). The queue could then work through items in the background almost like a local SMTP server - retrying (after certain time) if connection failures occur, holding items for delivery if SMTP server details are incorrect (connection refused) etc.

Nice suggestions here. Its going to be tricky to try and work out how we manage the user interface for this. A drop down list in the report column is an easy way to select who to report to, but its not the most efficient way to do things if you've got lots you want to report. Clicking a tick box vs clicking a drop down, navigating to the selection and releasing the mouse button.

I'm guessing people are going to want to report phishing emails to one authority and not to another. Perhaps the way to do this is create groups of reporting entities. Lets say you can have a max of 3 groups, and an icon associated for each. It might be easier to display those icons (not selected by default) to quickly click rather than use drop downs?

But icons are not as clear/definite as selecting something from a drop down written in plain language, so thats something to consider.
Any ideas?

Let me try this again. You can't give users the ability to forward their spam to just anyone. They'll forward it to their ex-girlfriend. I think reporting addresses should be built in, like SpamCop and Blue Security were.

But you'd have to contact who you are reporting to. I know Knujon would love to get the spam from a few million people. They might even put a link up to your website. ;)

But if a few million people started sending me their spam without me expecting it, hoping I could pick out phish, I'd get pretty pissed.

That said, how does this sound? (and I sure hope you're as talented as you look)

Say I get a phish. I would have my normal columns (delete, blacklist, etc.) but add one for phish. Click the box, and it gets reported to a general phish site. Now, if you could make that a drop-down menu, you could report 419's to one address, banks to another. Just checking the box would send a report to the general phish site, but using the drop-down would send it to a specific phish "terminator".

It has to be fairly simple from the user's end, and the people getting the reports have to know they are coming. It works smoother that way. Just ask ICANN. ;D

Nick said:
"Its going to be tricky to try and work out how we manage the user interface for this. A drop down list in the report column is an easy way to select who to report to, but its not the most efficient way to do things if you've got lots you want to report. Clicking a tick box vs clicking a drop down, navigating to the selection and releasing the mouse button."

Good point. Mass selections (of anything really) might better be done via selection of particular msgs (either or having a "Select" column). When all appropriate msgs have been selected, any combination of checkboxes and pulldowns can be set, and an "OK" button clicked.

Red said:
"You can't give users the ability to forward their spam to just anyone. They'll forward it to their ex-girlfriend. I think reporting addresses should be built in, like SpamCop and Blue Security were."

Anything can be abused Red. I can place whatever email address I want in the registry, even the email box for the current SpamCop Spam Tool. ;) I agree though that some will be ignorant of the implications of what they are configuring. Perhaps a default template of reporting orgs and their email addresses would be the way to avoid the problem.

Red said:
"You can't give users the ability to forward their spam to just anyone. They'll forward it to their ex-girlfriend. I think reporting addresses should be built in, like SpamCop and Blue Security were."

Ike said:
"Anything can be abused Red. I can place whatever email address I want in the registry, even the email box for the current SpamCop Spam Tool. ;) I agree though that some will be ignorant of the implications of what they are configuring. Perhaps a default template of reporting orgs and their email addresses would be the way to avoid the problem."

I know anything can be abused and changes to the registry can be made. That wasn't really my main point. I'm more concerned with adding reporting addresses that might not be able to handle the load of millions of people reporting to them. Any addresses "built in" should know we will be reporting to them. The reports have to be in an acceptable format, that kind of thing. Be nice, you know?

If there are "built in" addresses these will either need to be lists of allowed domains, or allowed addresses including wildcards as individual reporting addresses needed for some e.g. *@spam.spamcop.net for SpamCop, *@coldrain.net for KnujOn.

There is also the problem of the speed at which addresses can be added/removed to the list if they are built in. If they are literally built into the program then additions/removals are tied to MW releases, otherwise there may need to be a whitelist that can be checked/updated locally (if a file) or looked up online?

Regarding the interface - I'd also prefer tickboxes to dropdowns, though as said there may need to be a limit to how many addresses/groups can be added. Might be nice if the column title can be customised for each address/group (either text or from an appropriate set of icons - including fish, virus, currency ($? £?) etc.)?

Point #1 -- built in addresses. We can currently report to SpamCop in 6.3, so I'm assuming that functionality will be in the new release. You have to have a SpamCop account, though.

Knujon doesn't have that requirement. Anyone can report to knujon@coldrain.net. I was thinking of a dedicated account for MW users so you can see the stats, but I don't know if they'll do that. Anyway, it could be a simple ticbox under spam tools. SpamCop requires configuration, Knujon can just be a Yes/No box and the address built in. Idiot-proof (he says, knowing there is no such thing).

Point #2 -- changing built in addresses: Those are kept in the registry, at least in 6.3. A simple .reg file could be released as an update.

Point #3 -- ticbox/dropdown: My problem is I don't know where to report those various types of spam. Spamcop goes after the headers, Knujon goes after the links, but PIRT only handled certain types of phish. I win millions of dollars a day in lotteries that don't exist. Soldiers want me to make sure their parents get a share of a hidden cache in Iraq. Relatives I didn't know I had have died and left me millions. PayPal security warnings are common, as are eBay sale inquiries.

That many checkboxes would be confusing, and there are those that would report to all of them. I don't know of a generic phish hunter site that could sort it out, but that would be a cool third reporting option. If not, when the ticbox was checked, a drop-down could be enabled to select who to report to.

Again, this will require the cooperation of the sites we are reporting to. Knujon dropped ICANN's servers with reports that were expected. Whoops!

Red said:
"I'm more concerned with adding reporting addresses that might not be able to handle the load of millions of people reporting to them. Any addresses "built in" should know we will be reporting to them."
Good point. Default addresses could be limited to spamcop knujon and other reporting agencies capable of handling large volumes of spam/phish. There's also the issue of some reporting agencies accepting only reports from citizens and/or residents of that country. That list might be extensive where only one or two might be appicable for any particular user.

Red said:
"The reports have to be in an acceptable format, that kind of thing."

In my proposal for this feature I did suggest:
"b) allow text to be tagged to the msg being forwarded so as to clarify why the msg is being reported and/or to comply with the requirements of agencies to which the report is being sent."

Do you think that covers it or is something more needed?

Red said:
"Point #2 -- changing built in addresses: Those are kept in the registry, at least in 6.3. A simple .reg file could be released as an update."
I believe the new version's config will NOT be kept in the registry. I understand it will be a database of some sort. In any event users should be able to add addresses i.e. be able to customize their list of reporting agencies.

Red said:
"That many checkboxes would be confusing, and there are those that would report to all of them. I don't know of a generic phish hunter site that could sort it out, but that would be a cool third reporting option. If not, when the ticbox was checked, a drop-down could be enabled to select who to report to."
Exactly! Just to perhaps clarify what I'd proposed, while default "Report Types" would be supplied, for example "Spam" and perhaps "Phish", I envision each Report Type on the dropdown to be customizable by the user and that additional Report Types like "Generic Phish Hunter" could be added as appropriate. Each Report Type could be configured to one or zero default addresses but users could configure additional addresses as applicable. Dunno if a checkbox would be needed but if so, default should prolly be "Spam" so as to minimize the need for changing the pulldown setting. Actually I'd rather a means of mass changes be supported with the GUI such that whichever msgs are selected would be marked for deletion, report type, and whatever other action might be applicable for the selected msgs.

I gotta think on this, Ike. Suzi is a bit worried about too much publicity. Bob said bring it on.

I'm not exactly against having a "fill-in-the-blank" reporting address, but years ago it was a concern, and I think it still is. If I report to the wrong Australian address, I'll get my butt kicked.

I'll see if I can create a graphic on my idea for a drop-down. The auto-update feature would take care of changing addresses, but that's a different idea. Anyway, I'm tired and I have to go to bed.

I'm almost awake now, Ike, so I'm going to try this again.

Red (that's me) said:

"The reports have to be in an acceptable format, that kind of thing."

Ike said:

"In my proposal for this feature I did suggest:
"b) allow text to be tagged to the msg being forwarded so as to clarify why the msg is being reported and/or to comply with the requirements of agencies to which the report is being sent."

Do you think that covers it or is something more needed?"

Red is saying now:
"I was just reinforcing your solid point (posted way up there). I know if I send Yahoo a complaint because some scam has a Yahoo return address, I have to include a note pointing out the scam has a Yahoo return address. Otherwise, I get a note that the e-mail didn't come from Yahoo, it didn't include the full headers, etc. Any reporting address included in MW should be tested and approved to the satisfaction of the entities we are reporting to.

"I remember when Blue Security wasn't getting enough lines to catch a link they could pursue. We have to take care of the "minor details" with anyone we deal with.

Red said:
"Point #2 -- changing built in addresses: Those are kept in the registry, at least in 6.3. A simple .reg file could be released as an update."

Ike said: "I believe the new version's config will NOT be kept in the registry. I understand it will be a database of some sort. In any event users should be able to add addresses i.e. be able to customize their list of reporting agencies."

I'm saying now:
"If it is in a database, that would be slick. Eventually (and I'm thinking long term development here, not beta release reporting), the current "blacklists" MW uses could be linked to corresponding reporting addresses, their requirements, etc.

"But for now, how about we try this? This is a beta. Put in the user defined reporting address, and let's see if we get any complaints. We can talk about it until we're blue in the face, but no one will know until we try it."

"Of course, I say this knowing they aren't going to complain to me. ;-)"

I'd prefer a column for each type of report, most folks aren't going to be reporting to that many places and with planning you'd only need a minimal width column showing the first letter of the title in the header.

This would be good for me as I want the ability to report a spam message to one of two Spamcop addresses (quick. or submit.) based on the spam message.

I dug this out of the forums, it has some good info on spamcop reporting.

Background, there are two parts to a spamcop report:

1. The header derived reports that go to the sending ISP and adds to the spamcop blocklist, for that to work all you need is a couple (#?) lines of the message body and the full header.

2. The body derived reports attempt to identify the spamvertized website from the message body, that is a real challenge given all the spammer tricks but when it works the ISPs hosting the websites are notified after the reporter confirms the automated detection.

Just in case you thought that wasn't complicated enough there are three types of spamcop.net reporting:

1. free reporting
2. normal reporting
3. quick reporting

Free and normal are quite similar except the free adds some aggravation factors to get folks to pony up for the normal reporting that is faster but has a service charge. The main difference in their use is that a paid reporter might wish to limit the amount of data (attachments, graphics, viri or just filler all eat up your bytes quickly) while the free reporter could care less about byte counts. Now the quick reporter is different in that a quick report doesn't look at the body other than to check that one is there so that anything past a few (I haven't checked the minimum) lines of body is wasted data.

So in a perfect reporting system you'd have three options:

1. normal - trimmed body- user set line count
2. normal - full body - MW grabs full message beyond spam throttle
3. quick - severely trimmed body

The two normal reports would be sent to submit.xxxxx@spamcop.net while the quick report would go to quick.xxxxx@spamcop.net for processing.

I don't expect to see this full setup added any time soon even though it would be very handy, the only tricky part would be the normal - full report that would require fetching the rest of the message body beyond the spam throttle. Allowing the trimmed and severely trimmed settings to be adjusted would be nice but for the most part it wouldn't be a big savings over the 200 lines that seems to be a sweet spot for the spam throttle setting anyway.

The only times trimming reports would pay off enough to make it worth paying the coders to add it to MW is for paid spamcop.net reporters that are happy sending trimmed or quick reports and IF MW was changed to download full copies of messages set to be deleted.

Full download and reporting would be a real help to folks sending full reports but without some idea of their numbers cost/benefit is impossible to guess.

With FA needing 350 lines in the current beta, the trimming option is becoming more important. The byte count really matters when you are reporting a batch of a several thousand bogus bounces, 25 lines of body would be plenty for that.

Re: the interface. The problem with multiple check boxes for multiple reporting addresses -- like expanding on the current one-for-spamcop/one-for-FA! setup -- is that there's only so much room for columns, and it's crowded already. Spam reporting is very fragmented. Spamcop reporting is time consuming, and Knujon has a very limited scope. Neither deals with spam with email address links instead of URL links, for instance, and the current deluge of 419 spam is not getting reported very effectively.

Reporting everything to one law enforcement address is useful so they can one day trot out five gabillion messages when they get around to indicting someone, but it won't get any spamvertised websites or email addresses closed down in the short term. You have to report to the entities actually responsible for the resources being abused by the spammer.

My suggestion would be complicated, but what I envision is having one column "mark for reporting" in the current inbox view. That's it.

Then in a *separate* tab, there would be a reporting interface that would show the messages that had been marked for reporting in the main view. The reporting tab would have entirely different columns than the main inbox. (In particular, it would NOT have a "from" column, to emphasize that the "from" field is not useful for deciding where to report.)

Besides Spamcop, Knujon, and FirstAlert!, there might be columns of check boxes set up for your own country's law enforcement abuse addresses. There might be columns to report to free email providers like yahoo or hotmail for 419 spams that use those addresses for contact rather than having a URL link. There might be an "other" column with a drop down menu or form where someone could type in less common reporting addresses. Spammers often will suddenly start using some small provider or URL shortening service for a brief time until that service gets control of things, and having spam reporters jump on a situation early helps nip that in the bud.

It would be quite useful if Firetrust established communication with a lot of the entities to which we would be reporting to ensure that our reports were recognized as valid. Many people new to spam reporting will report to the wrong provider based on the address in the "from" field -- just as they try to use the MWP bounce feature. In response, email providers like hotmail and yahoo have set up filters to reject spam reports if the headers in the reported spam don't show it originating on their network, even if the reason we're referring it to them is that the spammer is asking victims to contact them at one of their email addresses, not that we think the spam came from their mailserver. If the abuse desk staff were expecting reports in a format generated by MWP and knew that the MWP interface encouraged accurate reporting, it would help our reports get flagged for attention.

You may say that kind of complex interface is way over the top, because only a few people are that serious about reporting spam. But part of the reason few people report it is that it's currently quite difficult to do it effectively. Only a tiny minority of spams get reported. 419 fraudsters thrive because most of their email accounts don't get reported and stay open long enough for victims to contact them.

People are choosing MWP because of the infamous spam bounce feature. They *want* to do something about spam, and are willing to click a few extra buttons to do it. If you gave them more productive buttons to click, I think MWP would attract a lot of attention as a spam management tool, and not just another spam filter struggling to compete in a field of so many other spam filters.

PS, I do like the suggestion of having it work in the background and keep trying if the first attempt at reporting fails, rather than allowing the reporting to fail and proceeding with deleting the spam. That drives me crazy when it happens.

Red said (way back up there, and I didn't see any challenge to it):
"Knujon doesn't have that requirement. Anyone can report to knujon@coldrain.net. I was thinking of a dedicated account for MW users so you can see the stats, but I don't know if they'll do that. Anyway, it could be a simple ticbox under spam tools. SpamCop requires configuration, Knujon can just be a Yes/No box and the address built in. Idiot-proof (he says, knowing there is no such thing)."
While you can report spam to a general reporting address at KnujOn, they prefer that you use your own assigned reporting address if you are a registered user.

I really like the reporting phishing mail idea. They come in waves, like for banks or ebay or whatever. I have to mark all my ebay mail as blacklisted now and then uncheck it for what is real. I often overlook stuff when I am in a hurry. Would love to nail those who do that phishing. I am voting for this topic for this reason.

I like this concept. I came here to make a suggestion like this, because I get repeated malware spam emails from the same sender using the same hotmail account. It seems to me that hotmail would like to know about this and close the account. I would very much like to be able to right click on a message and select who to forward the full message to, with an appropriate cover note that I can either set up, or type in when I select to forward an email, and have the option to add the recipient's email address, with or without the cover note.

Implementation note: It would be nice if Filters could specify which reporting entity(ies) to report to when there is a Filter match.

I think it would be a great idea. I would like to send my spam and fishing emails to the Federal Government website spam@uce.gov as I did before using Mail Washer. I would also like to send them to Microsoft (Hotmail) because that's where so many of my come from.