On Tue, 19 Feb 2013, Kevin A. McGrail wrote:
On 2/18/2013 9:47 PM, Dan Mahoney, System Admin wrote:
Hey there,
Spamcop has an undocumented feature that they allow you (if they trust you)
to "quick report" spam, where you send to a different mail address, and
it's reported instantly, without having to hit the web interface. When you
do this, you are still free to report spam in the usual way (with the
confirm screen) by using your usual reporting-address.
How hard would it be to extend spamassassin's "report" syntax to allow
this?
Unfortunately, I'm not seeing a good way to pass config-options to spamd,
so that's out. (I suppose this email could be interpreted as a case of "is
this useful?").
Running the "report" against spamassassin locally would lose me the other
learning (bayes, etc).
Creating an alternate user with the quick-reporting mail address sent is
similarly problematic (althouth I *might* be able to do this by playing
with the userpref sql query).
I'm open to any other ideas people have come up with.
Hi Dan,
Looking a this in a high level, I think you are referring to spamc's
reporting feature.
I am. I receive email for my entire domain, and I have several mailboxes
which meet spamcop's definition of traps -- they have NEVER been used to
receive legit mail, and were basically made up by list-sellers to pad
lists, and are not even close (typographically) to any other email
addresses I've got.
They have "real names" and other such demographic information, and
are doctors, apparently, based on the crap they get.
For a while, I tried reaching out to the people mailing me (who looked
legit) and tried to tell them "okay, this is the first time I'm seeing
mail to this address, you got scammed by whomever sold you this list").
But bulk-mailers (legit or not) deal in volume, and can-spam basically
says they don't have to care.
Faced with this, I had three options:
1) Unsubscribe, basically self-listwashing.
2) Route the mail to /dev/null.
3) Allow these email addresses to act like a poisoned fruit, and serve as
a marker of the spam and irresponsible list-buyers, and act as a sigil
with razor/pyzor/spamcop.
With #3, the annoyance is that I now send to "spamc -C report", but get a
steady stream of emails that say "spamcop has accepted one email for
processing". And of course, because spamcop wants their mail to be
"fresh" it means I'm dealing with a constant stream of having to log in
and click through.
Aside:
What's more braindead, on Spamcop's end, is that while they won't accept
mail over two days old, if you don't go in and click report/cancel, it
will wait for you in the queue, for weeks. (And from what they tell me,
they don't parse the mail until you hit "report now", so they cite CPU
overhead on doing advanced expiry). They seem to have missed the bit that
they have the date-of-submission without having to parse the body.
/Aside.
However, that's likely not the best avenue unless you are just trying to send
spamcop examples of algorithmically determined spam. I wonder if it is time
for a separate reporting binary and perhaps build on the existing
"collaboration reporting" in spamc/d and add RPS::Mail::EventReporter for
reputation collaboration.
I would be in favor of this. It would also seem that DCC's reputation
code/reporting should have support in the latest version of SA. As I now
read that spamcop's "quick" reporting isn't as thorough as their manual
report, I'm somewhat less interested, but better support in a tool could
change that.
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
