Re: no reporting methods available
On 2015-07-31 18:28 -0500, David B Funk wrote: Reporting is separate from learning. It is the case that spamassassin -r is supposed to report and learn. However it isn't quite the same as sa-learn --spam in that unlike sa-learn --spam it won't override the spam learn prohibition of BAYES_00. Thanks, that is useful to know. However, it isn't really relevant to this situation. My point is: if learning _is_ part of the job of spamassassin -r, then does it have to fail for the no method available message to be emitted? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Hashcash not working
On Fri, 31 Jul 2015 13:36:21 +0200 Christian Jaeger wrote: On July 30, 2015 2:40:35 AM CEST, RW rwmailli...@googlemail.com wrote: The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value That's disappointing. For me that barely counts as on by default. I was thinking that implementing hashcash would help get my mail delivered to at least the spamassassin users, but this means that no, only to the subset that cares about configuring it. Does SA not know which address(es) an email is being delivered to? If it knows (knew), it could just compare those addresses, no? (E.g. qmail sets various environment variables, e.g. RECIPIENT, when running filters, can't SA use this? I'm using QPSMTPD, I suppose spamc could be modified to pass recipients, too?) SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default. It's probably for the best that it doesn't work by default. It would likely have been exploited by spammers if it were. If the answer is no, then I realize that there's also an accidental double-spend issue? My qmail-remote wrapper adds a X-Hashcash header for every receipt address the qmail-remote is being called with. I was thinking that the receiver could restrict itself to only look (and mark in the database) the header for the delivery that's being made. Now I worry that if I send an email with To: f...@bar.com, b...@bar.com with two X-Hashcash headers that, if SA is run separately for each sub-delivery, then it will mark both headers in the first delivery and add a penalty for used hashcash to the second. From the quick look I had at the code, I think it only cancels one on each scan - it wouldn't matter which. The more significant problem is that for unix users and virtual home directories it creates per user databases by default. You can opt for a single database path, but it's still a Berkeley database file with all the problems that implies. My decision to spend time to implement this was based on reading in wikipedia[1] that SA is checking them. I think this needs a mention that it only happens when configured. If you don't disagree, I'll change that. [1] https://en.wikipedia.org/wiki/Hashcash Hashcash for email isn't a very good idea. Even if it were ubiquitous and email couldn't be sent without it, it wouldn't be a major impediment to spammers. If spammers don't have to add a hashcash header to everything, it doesn't even slow them down, it's just an opportunity to make some of their spam more deliverable.
Re: Hashcash not working
nevermind, envelope recipient, but that's also easy and contained in the Received headers Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43 +0200 (CEST) Am 31.07.2015 um 16:45 schrieb Reindl Harald: Am 31.07.2015 um 16:37 schrieb RW: On Fri, 31 Jul 2015 13:36:21 +0200 Christian Jaeger wrote: On July 30, 2015 2:40:35 AM CEST, RW rwmailli...@googlemail.com wrote: The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value That's disappointing. For me that barely counts as on by default. I was thinking that implementing hashcash would help get my mail delivered to at least the spamassassin users, but this means that no, only to the subset that cares about configuring it. Does SA not know which address(es) an email is being delivered to? If it knows (knew), it could just compare those addresses, no? (E.g. qmail sets various environment variables, e.g. RECIPIENT, when running filters, can't SA use this? I'm using QPSMTPD, I suppose spamc could be modified to pass recipients, too?) SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default really? wonder how the SPF tests which need the envelope by defintion would work than? i guess because the heuristics mentioned below the same for FREEMAIL_ENVFROM_END_DIGIT HK_RANDOM_ENVFROM which all works out of the box https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html _ envelope_sender_header Name-Of-Header SpamAssassin will attempt to discover the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. This is used in the EnvelopeFrom pseudo-header, and for various rules such as SPF checking. By default, various MTAs will use different headers, such as the following: X-Envelope-From Envelope-Sender X-Sender Return-Path SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 and bug 4747 in the SpamAssassin BugZilla.) signature.asc Description: OpenPGP digital signature
Re: Hashcash not working
Am 31.07.2015 um 16:37 schrieb RW: On Fri, 31 Jul 2015 13:36:21 +0200 Christian Jaeger wrote: On July 30, 2015 2:40:35 AM CEST, RW rwmailli...@googlemail.com wrote: The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value That's disappointing. For me that barely counts as on by default. I was thinking that implementing hashcash would help get my mail delivered to at least the spamassassin users, but this means that no, only to the subset that cares about configuring it. Does SA not know which address(es) an email is being delivered to? If it knows (knew), it could just compare those addresses, no? (E.g. qmail sets various environment variables, e.g. RECIPIENT, when running filters, can't SA use this? I'm using QPSMTPD, I suppose spamc could be modified to pass recipients, too?) SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default really? wonder how the SPF tests which need the envelope by defintion would work than? i guess because the heuristics mentioned below the same for FREEMAIL_ENVFROM_END_DIGIT HK_RANDOM_ENVFROM which all works out of the box https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html _ envelope_sender_header Name-Of-Header SpamAssassin will attempt to discover the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. This is used in the EnvelopeFrom pseudo-header, and for various rules such as SPF checking. By default, various MTAs will use different headers, such as the following: X-Envelope-From Envelope-Sender X-Sender Return-Path SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 and bug 4747 in the SpamAssassin BugZilla.) signature.asc Description: OpenPGP digital signature
Re: Hashcash not working
On Fri, 31 Jul 2015 16:47:34 +0200 Reindl Harald wrote: nevermind, envelope recipient, but that's also easy and contained in the Received headers Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43 +0200 (CEST) It's usually there, but some servers never add it. There are also some mail systems where all mail has a recipient header like Delivered-To, even if received for multiple recipients.
Re: Hashcash not working
On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. It's probably for the best that it doesn't work by default. It would likely have been exploited by spammers if it were. Well, it seems that right now hashcash is of no use. If we actually use it then the worst that could happen (in the case that spammers can really generate hashcash as easily as legitimate senders) is that it's also of no use. But isn't there also a chance that it's not turning out as bad? Hashcash for email isn't a very good idea. Even if it were ubiquitous and email couldn't be sent without it, it wouldn't be a major impediment to spammers. If spammers don't have to add a hashcash header to everything, it doesn't even slow them down, it's just an opportunity to make some of their spam more deliverable. I don't really see the logic in your statement. It doesn't need to be ubiquitous, my thinking is that it would be useful as an additional indication for *important* email that the email isn't spam (especially if end client applications (web or otherwise) would adopt it, so that it could use something like 20 seconds of CPU time). E.g. not for mailing list emails, but for personal email where you don't want the email to be lost (have a button that says retry more forcefully or something, that you could push when you suspect the receiver didn't get a mail, or when you're contacting someone the first time and think it's important, that then does the 20 second (or more) hashcash calculation). 20+ seconds would be rather hard to compete against I'd think. If it means that a spammer could only afford say 2 seconds, and even for the 2 seconds would have to reduce sending rate to a tenth, that would already be good? If it means that they can only make *some* of ther spam as well deliverable as currently, that's also success, no? I expec t the scores to adapt so that low-effort hashcash would have zero effect on the spam score, but high-effort hashcash would still point towards ham. I think it boils down to the question of whether spammers really have enough CPU power for multi-second hashcash per recipient calculations (or, as much as legitimate senders). Others have argued that the heat/fan activity would make some people more suspicious and make them get rid of the abuser. (This by itself would already be a good thing.) I also wonder whether it wouldn't be more worthwhile for criminals to use the available CPU power for Bitcoin mining instead? Any sources for numbers? Why not simply try it? Wouldn't the worst case be that the scores would be adapted to around zero when spammers would really start using it? Is it fear of making the system more complex and then not understanding it anymore? (BTW is there a framework in SA to statistically analyze combinations of characteristics? So that by learning (sa-learn) client installations could adapt automatically? Or is that too CPU heavy? Or precalculate the data for everyone but let client installations adapt those (implicit) 'scores' through learning?) Christian.
Re: Hashcash not working
On 31 Jul 2015, at 7:36, Christian Jaeger wrote: On July 30, 2015 2:40:35 AM CEST, RW rwmailli...@googlemail.com wrote: The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value That's disappointing. For me that barely counts as on by default. I was thinking that implementing hashcash would help get my mail delivered to at least the spamassassin users, but this means that no, only to the subset that cares about configuring it. As it should be. There is no default value that could be reasonable for a broad range of sites and users for the commonplace neglect times of SA installations. One of the features of hashcash that raises it a millimeter above most other species of the naive conceptual genus of e-postage is the ability of receivers to arbitrarily set their own price AND to raise the price over time to compensate for Moore's Law and botnet growth. If you are not prepared to actively manage a hashcash deployment, it is not going to be useful and over time will reduce your SA accuracy in the unlikely event that hashcash becomes popular enough for spammers to notice. John Levine wrote a definitive debunking of e-postage schemes including hashcash over a decade ago (http://www.taugh.com/epostage.pdf) and published an update (substantively unchanged) via Virus Bulletin in 2009 (https://www.virusbtn.com/spambulletin/archive/2009/03/sb200903-epostage.dkb?mobile_on=no). All of his points against e-postage in general and hashcash specifically have held up over time.
Re: Hashcash not working
On July 31, 2015 4:51:02 PM CEST, Bill Cole sausers-20150...@billmail.scconsult.com wrote: John Levine wrote a definitive debunking of e-postage schemes including hashcash over a decade ago (http://www.taugh.com/epostage.pdf) and published an update (substantively unchanged) via Virus Bulletin in 2009 (https://www.virusbtn.com/spambulletin/archive/2009/03/sb200903-epostage.dkb?mobile_on=no). All of his points against e-postage in general and hashcash specifically have held up over time. I've read both links, they both bring the same two arguments: The technical problems are that some computers are a lot faster than others I see a social problem with this: that in principle it penalizes poor people. But let me restate: As I already said in my other email, for me hashcash seems to make sense where you really need to deliver a particular important, personal email. I don't care for a fairy dust solution that would solve sending legitimate mass email (be it mailing lists or ). I'm fine with those being filtered the way they are now. I'm caring to reduce the risk of loss of *important* emails, especially in situations where currently the risk is high, i.e. there's no whitelisting through previous communications. Those cases are few. It's easy to spend even minutes of CPU time on such cases. Or, since the article argues that grandma has a 100 Mhz computer, the ISPs could offer premium email, where the piece costs a few cents (hey, cheaper than SMS with many providers!), and then run hashcash on a few powerful servers in parallel for a minute with a total CPU budget of several minutes. Now I would expect that ISPs in 3rd world countries would offer hashcash generation for a lower margin, and hence even people there could easily afford sending important mails with hashcash. (If grandma's ISP wouldn't offer premium email, she'd have to send the email without hashcash, and it would still have a decent chance of deliverability, or she would have to let her computer up for an hour until it is sent. As I said, it would be rare to need it.) Yes, that's when user's clients get the ability to compute hashcash, and ISPs adopt it. I.e. when it really catches on. Before that point, there's a phase where we're experimenting and hashcash doesn't play a big role in spam recognition (and grandma doesn't even come into play). The article argues in an absolute that ignores possible developments. and that currently spammers have a lot more computer power at their disposal than legitimate senders do Furthermore, spammers have vast arrays of hijacked `zombie' computers at their disposal. Blacklist maintainers report adding 10,000 newly hijacked computers to their blacklists per day. No legitimate mailer has anything like 10,000 computers dedicated to sending mail, much less 10,000 additional computers a day, meaning that it would be easier for spammers to satisfy hashcash than for legitimate senders. It compares a daily differential in the numbers of hijacked computers worldwide with the numbers of computers available to a single mailer? (How many are *removed* from the blacklists per day, btw?) Please give me actual real numbers and I can do actual calculations. So where's the actual debunking? Christian.
Re: Hashcash not working
On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. I can see why they went with hashcash_accept, it always works - even if the recipient is rewritten. Hashcash for email isn't a very good idea. Even if it were ubiquitous and email couldn't be sent without it, it wouldn't be a major impediment to spammers. If spammers don't have to add a hashcash header to everything, it doesn't even slow them down, it's just an opportunity to make some of their spam more deliverable. I don't really see the logic in your statement. It doesn't need to be ubiquitous, In the hashcash FAQ they argue that hashcash is useful against botnets because it slows them down. But this would only be correct if hashcash were essential to delivery. If it isn't then hashcash support in spamfilters would benefit spammers because they can send a mixture of spam with and without the header. They'd get extra deliverability without any slow down at all. I think it boils down to the question of whether spammers really have enough CPU power for multi-second hashcash per recipient calculations (or, as much as legitimate senders). One of the problems with hashcash is that its algorithm is well optimised for GPUs and other heavily parallel hardware. The 20 seconds on an ordinary core could be milliseconds on a machine made from just gaming hardware. Spammers also have the advantage that they don't have to work in real time - they can generate postdated stamps in advance of a spam run.
no reporting methods available
I run spamassassin -r from cron nightly. Last night I got this output: Jul 30 23:00:11.830 [31065] warn: reporter: no reporting methods available, so couldn't report Jul 30 23:00:11.830 [31065] warn: spamassassin: warning, unable to report message Jul 30 23:00:11.830 [31065] warn: spamassassin: for more information, re-run with -D option to see debug output I tried to follow the instructions and run spamassassin -D -r `ls spam` but that hangs without producing any output. The only external reporting method I'm aware of that should be active is Razor. Running razor-report `ls spam` works normally as expected. Aside from getting an explanation of what happened this time, I'd also like to clarify more generally what spamassassin -r does. From a recent thread here I learned that it also does the equivalent of sa-learn --spam. Right? So presumably it doesn't consider this a reporting method or how could it be not available? Also I recently installed the bogofilter plugin by Christian Laußat, and my understanding is that (when bogofilter_learn is set to 1, as it is), it advertises itself as another external reporting agent. So shouldn't this also happen during a spamassassin -r run, and how could it be not available? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Hashcash not working
On July 31, 2015 9:13:03 PM CEST, RW rwmailli...@googlemail.com wrote: On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. When does RECIPIENT break? man qmail-command says that RECIPIENT is the envelope recipient address. Shouldn't this be the unchanged To/Cc/BCC address that the mail is currently being delivered to, assuming no forwarding was done? I can see why they went with hashcash_accept, it always works - even if the recipient is rewritten. I don't expect hashcash in forwarded email to be found without special configuration. If it finds the matching hashcash in non-forwarded configuration that sounds fine to me. I don't really see the logic in your statement. It doesn't need to be ubiquitous, In the hashcash FAQ they argue that hashcash is useful against botnets because it slows them down. But this would only be correct if hashcash were essential to delivery. If it isn't then hashcash support in spamfilters would benefit spammers because they can send a mixture of spam with and without the header. They'd get extra deliverability without any slow down at all. Hm, I see your point, they could use the CPU they have available but still saturate their network capability, too. The effect will be complicate to calculate. Possibly by sending spams without hashcash over the same network their IPs will be blacklisted enough to prevent the spam with hashcash from being delivered either. I guess their strategy will be to pregenerate as much hashcash as they can, then first send spam with hashcash, then when they've run out of hashcash send spam without, thus staying more likely in the green while they have hashcash then continue as long as they can or makes sense without. (I don't have deep insights into how spammers work, I'm just reckoning here. Hopefully at least as well as the writers of some articles.) One of the problems with hashcash is that its algorithm is well optimised for GPUs and other heavily parallel hardware. The 20 seconds on an ordinary core could be milliseconds on a machine made from just gaming hardware. Normal CPUs have SIMD instructions, and one could use all cores, then the difference shouldn't be that vast (make that number of milliseconds something in the range of thousands, then?). But agreed, scrypt would make more sense here. This is an attack on the hashing algorithm, not the concept as a whole. (Calculating hashes in browsers will eagerly await widespread support of SIMD in JavaScript; but this is again a problem that could go away if hashcash really got successful, browsers could include hashing functions implemented in C/C++/Rust/ASM.) Spammers also have the advantage that they don't have to work in real time - they can generate postdated stamps in advance of a spam run. Ok, that means they can keep their moves quick (quick bursts until IP blocked etc.), but the total amount of hashcash they can produce stays the same. (Also see the above.) Maybe the concept could be extended to use a challenge-response scheme (e.g. where the receiving SMTPd would present a challenge, then let the sender (optionally) disconnect, calculate the hashcash with the challenge as additional input, then reconnect; or provide the challenge over DNS with short TTL). Is there a(nother) good place already to discuss these concepts? (Wiki, etc.) I don't intend to 'spam' this list too much with this. But I think it's interesting to read and think more about this. (There seems to be a ML linked from hashcash.org, but the last message in the archives is from 2012.) Christian.
Re: Hashcash not working
Christian Jaeger wrote: On July 31, 2015 9:13:03 PM CEST, RW rwmailli...@googlemail.com wrote: On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. When does RECIPIENT break? man qmail-command says that RECIPIENT is the envelope recipient address. Shouldn't this be the unchanged To/Cc/BCC address that the mail is currently being delivered to, assuming no forwarding was done? First of all, not everyone uses qmail. Exim and Postfix can call SA directly in certain configurations. Exim, Postfix, and sendmail can all use Mailscanner or Amavis IIRC. Postfix and sendmail can use milters like MIMEDefang or spamass-milter. Most of these configurations plug SA into the mail system at a point where one message may have many recipients who may have different filter policies as expressed in the SpamAssassin configuration. There *is* no The recipient. -kgd
Re: Ignore forwarding headers from specific sender
On 30.07.15 18:27, Al B wrote: I wasn't aware that Hotmail's filters work when you have forwarding turned on. I also would prefer to have all my blacklist in one place instead of having maintain 2 list. it's bad idea to let spam being forwarded and blocked on the destination. I wouldn't wonder if gmail would start marking mail forwarded through your account as spam... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Silvester Stallone: Father of the RISC concept.
Re: Hashcash not working
On July 30, 2015 2:40:35 AM CEST, RW rwmailli...@googlemail.com wrote: The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value That's disappointing. For me that barely counts as on by default. I was thinking that implementing hashcash would help get my mail delivered to at least the spamassassin users, but this means that no, only to the subset that cares about configuring it. Does SA not know which address(es) an email is being delivered to? If it knows (knew), it could just compare those addresses, no? (E.g. qmail sets various environment variables, e.g. RECIPIENT, when running filters, can't SA use this? I'm using QPSMTPD, I suppose spamc could be modified to pass recipients, too?) If the answer is no, then I realize that there's also an accidental double-spend issue? My qmail-remote wrapper adds a X-Hashcash header for every receipt address the qmail-remote is being called with. I was thinking that the receiver could restrict itself to only look (and mark in the database) the header for the delivery that's being made. Now I worry that if I send an email with To: f...@bar.com, b...@bar.com with two X-Hashcash headers that, if SA is run separately for each sub-delivery, then it will mark both headers in the first delivery and add a penalty for used hashcash to the second. Luckily, I'm running SA from qpsmtpd, which should only run it once when it receives the double delivery. I suppose SA could prevent this issue from happening in other cases by storing the message-id together with the spent token. My decision to spend time to implement this was based on reading in wikipedia[1] that SA is checking them. I think this needs a mention that it only happens when configured. If you don't disagree, I'll change that. [1] https://en.wikipedia.org/wiki/Hashcash In any case, I've configured it now and it still doesn't work. Off again working on debugging it. Christian.
Re: Hashcash not working
On Fri, 31 Jul 2015, RW wrote:
On Fri, 31 Jul 2015 16:47:34 +0200
Reindl Harald wrote:
nevermind, envelope recipient, but that's also easy and contained in
the Received headers
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id
3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43
+0200 (CEST)
It's usually there, but some servers never add it. There are also some
mail systems where all mail has a recipient header like Delivered-To,
even if received for multiple recipients.
The embedding of the envelope recipient in Received headers is MTA configuration
dependent and even those that do will usually omit it when there's more
than one envelope recipient for a message.
The Delivered-To header and its ilk (EG: Return-Path) are usually only added
at the final delivery MTA point and may not be visible at an intermediate point.
It's best if the mail-system glue used explicity makes envelope sender and
recipient available to SA via reliable mechanism.
For example if using a milter, make it add synthesized X-Envelope-From
X-Envelope-To headers to the stream it passes to SA.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: no reporting methods available
On Fri, 31 Jul 2015, RW wrote:
[snip..]
I'd also
like to clarify more generally what spamassassin -r does. From a
recent thread here I learned that it also does the equivalent of
sa-learn --spam. Right? So presumably it doesn't consider this a
reporting method or how could it be not available?
Reporting is separate from learning.
It is the case that spamassassin -r is supposed to report and learn.
However it isn't quite the same as sa-learn --spam in that unlike
sa-learn --spam it won't override the spam learn prohibition of BAYES_00.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: no reporting methods available
On Fri, 31 Jul 2015 12:38:00 -0700 Ian Zimmerman wrote: I run spamassassin -r from cron nightly. Last night I got this output: Jul 30 23:00:11.830 [31065] warn: reporter: no reporting methods available, so couldn't report Jul 30 23:00:11.830 [31065] warn: spamassassin: warning, unable to report message Jul 30 23:00:11.830 [31065] warn: spamassassin: for more information, re-run with -D option to see debug output I tried to follow the instructions and run spamassassin -D -r `ls spam` If the problem persists, I'd run spamassassin -r one spam at a time until you get the error and then run spamassassin -D -r on that particular spam. The only external reporting method I'm aware of that should be active is Razor. Running razor-report `ls spam` works normally as expected. I think the error message is a bit misleading. According to the documentation a plugin can set two flags, one to say that reporting is available and another to say it completed successfully. In all the plugins that support reporting, both flags are set in the same place. So no reporting methods available really means that no plugin succeeded in reporting one of the spams. In your case that just means that a razor report failed. I'd also like to clarify more generally what spamassassin -r does. From a recent thread here I learned that it also does the equivalent of sa-learn --spam. Right? So presumably it doesn't consider this a reporting method or how could it be not available? Reporting is separate from learning.
