sure!  sounds like a good idea to me, if KnujOn are amenable to receiving reports from the SA user population.

btw are you speaking on behalf of KnujOn here, or just as a concerned citizen?

finally -- the lack of code for a plugin that implements this would be the main barrier to inclusion ;)

Hmm, that does kind of read like I'm representing KnujOn ... oops.  I'm a concerned citizen (who happens to spend far too much time tweaking his company's spam filters).

I sent an email to the KnujOn people referring them here so they can work with whomever is implementing this.  I suspect it will look very similar to the SpamCop plugin and can probably start as a fork of it.

I am for the idea in concept (and actually do report "excessively spammy" messages to Knujon), but modifying SA to do this directly may not be the best way to do it, nor is it how I do it.  If the SA community does wish to modify SA to do this directly, then I suggest that it allow an adminstrator to specify a [LOCAL] virtual mailbox with which to deliver the spam.  That mailbox may be expanded or aliased (e.g. sendmail's aliases file, or via mailing list software) to deliver to more than one spam collecting service.

The above is what I do at my system.  I call SA via the MIMEDefang package using the latter's "filter_end()" hook.  Depending on the actual score SA reports, I progressively add more reporting-service mailboxes via the "add_recipient()" function.  Knujon's mailbox is one of those aliased to one of 4 levels of reporting, including a routine that looks up the envelope sender's domain at "abuse.net" to retrieve the abuse mailboxes.  (Either there was no SPF or DK/DKIM records, or those records passed in order to get this far -- so I'm either reporting spam that has NOT been forged, or spam where the domain used doesn't care to protect itself against forgery.)  NONE of this requires any modification to SpamAssassin, so modification is technically unnecessary.

Therefore, if I had a "vote" in the matter, I vote NO.  This can be done without modification to SA -- and let's keep SA simple and efficient.

Is there any difference in reporting to KnujOn with respect to SpamCop? I mean, differences in the reporting algorithms/protocols, not in the net effects.

DCC, Pyzor and Razor report message hashes to their own engines. These hashes are computed and reported in different ways, so that it is reasonable to me they have their own report handling methods.

The SpamCop plugin instead envelopes and ships the first spamcop_max_report_size kbytes of the reported message to a specified mailbox address. This plugin is actually used only for reporting.

So, isn't it suitable for reporting to KnujOn, too?

If yes, wouldn't it be better to renate/alias the SpamCop plugin with a more general way, instead of adding yet another message reporting plugin?

Is there any difference in reporting to KnujOn with respect to SpamCop? I mean, differences in the reporting algorithms/protocols, not in the net effects.

DCC, Pyzor and Razor report message hashes to their own engines. These hashes are computed and reported in different ways, so that it is reasonable to me they have their own report handling methods.

The SpamCop plugin instead envelopes and ships the first spamcop_max_report_size kbytes of the reported message to a specified mailbox address. This plugin is actually used only for reporting.

So, isn't it suitable for reporting to KnujOn, too?

If yes, wouldn't it be better to rename/alias the SpamCop plugin with a more general way, instead of adding yet another message reporting plugin?

(In reply to comment #5)

> If yes, wouldn't it be better to rename/alias the SpamCop plugin with a more
> general way, instead of adding yet another message reporting plugin?

KnujOn has (quite deservedly) been getting headlines for their work over the past few years, but they're far from the only anti-spam project seeking spam reports -- not to mention law enforcement agencies in many jurisdictions, and often your local sysadmin.

A generic plug-in with configurable recipients (and a warning not to ever forward spam reports to anyone without asking them first) would indeed seem like the most scalable and balanced option.

(In reply to comment #6)
> A generic plug-in with configurable recipients (and a warning not to ever
> forward spam reports to anyone without asking them first) would indeed seem
> like the most scalable and balanced option.

I agree.

I would also suggest to include a per-recipient option to "munge" the spam recipients. SpamCop accounts may be configured to munge recipients. I was unable to understand if KnujOn does or doesn't it by its own, but I figure a lot of possible spam-reporting services don't munge spam recipients.

This is quite an important issue at least in Europe, where (very silly) laws may get an ISP guilty of personal information disclosure if it sends spam verbatim to a non-munging reporting service.

I think the spamcop plugin will work as is, since it already allows specifying the address to report to, so just:

spamcop_to_address nonregistered@coldrain.net

So the only changes needed would be to allow multiple addresses to report to, so spamcop and knujon can be used at the same time, and probably some renaming.

Nope, the spamcop plugin is hardcoded to deliver to port 587 (mail submission), and knujon doesn't listen on that port.

I don't know what is KnujOn, but they would be best advised to allow submission on port 587 because it is far more likely to work on most networks while outgoing port 25 is blocked or filtered by default.

Re - Spamcop reporting hardcoded to port 587 (or any hardcoded port)?

Why is that a problem?  The standard URL construct and syntax provides for a port number designation for other than the "standard" port of a particular service for a protocol.  Therefore, a "mailto:" URL should be able to support a port number designation that should be also be understood by a standard MSA.  Whether or not this was specifically done for the mailto URL type will require a review of STD 10 and the various RFCs, and if not specified, it should be added.

As for port 25 being blocked, why would that happen?  If someone is operating an MTA, they will already have port 25 available (incoming), and if port 25 outbound is blocked, they're running an MTA when they shouldn't be (e.g. an ISP customer, especially those with dynamic IP assignments).  Therefore, I don't consider that a problem which needs addressing.

What needs to be checked is this:  Does the current SA construct allow multiple addresses?  If so, then nothing need be changed.  Otherwise, SA must construct a submission list looping through the CSV (comma separated values), delivering a copy to each.  Unfortunately, the local MSA cannot be used - else a recursive operation with no termination may result.

(In reply to comment #9)
> Nope, the spamcop plugin is hardcoded to deliver to port 587 (mail submission),
> and knujon doesn't listen on that port.

Adding something like the "spamcop_report_smtp" setting to the SC plugin (see bug#5402) would probably do the trick as well as fix the problems outlined in that bug.

Then, the only limit I see with the actual SC plugin is that it can be configured to report only to a destination: it can't report both to SC and KnujOn...

Closing old stale bugs.

It's dead anyway.

"As of 8 March 2018 the service stopped accepting new subscriptions and email submissions began bouncing. On 22 May 2018 the service was shut down."