Re: Possible to whitelist *all* incoming emails that contain specific text in the subject line?
nathang wrote: Hi, I'd like to setup an email account in cPanel so that I receive *all* incoming emails that contain a specific word in the subject line. It would be critical that I get 100% of the emails sent to me (that contain a specific word in the subject line), and that none of them get trapped by a spam filter or whatnot, as these emails would signify my paying customers with their order details. I know that you can whitelist individual email addresses, but is it possible to whitelist based on subject line text? If this possible to do in cPanel / WHM, how would I go about doing it? Probably, but this is the *SpamAssassin* mailing list, not the cPanel / WHM mailing list so I'm not sure why you are asking here? I could tell you how to do this in SpamAssassin, but I have no idea in cPanel / WHM as I've never used it :)
Re: Possible to whitelist *all* incoming emails that contain specific text in the subject line?
nathang wrote: Hi, I'd like to setup an email account in cPanel so that I receive *all* incoming emails that contain a specific word in the subject line. It would be critical that I get 100% of the emails sent to me (that contain a specific word in the subject line), and that none of them get trapped by a spam filter or whatnot, as these emails would signify my paying customers with their order details. I know that you can whitelist individual email addresses, but is it possible to whitelist based on subject line text? If this possible to do in cPanel / WHM, how would I go about doing it? Thanks! Assuming a non-ancient version of SA (3.1.0 or higher), the whitelist_subject plugin should be loaded. So you can just add this to your configuration (i.e.: local.cf): whitelist_subject customer which would whitelist any email with the word customer in the subject. As for doing it in cPanel / WHM... no clue, I've never used either tool.
Re: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
Warren Togami wrote: Apache SpamAssassin 3.3.0-beta1 is now available for testing Builds cleanly on CentOS 5.4 64-bit w/ perl 5.10.0.
Re: [sa] RE: Suggestion for use by ANY whitelist service....
On Mon, 7 Dec 2009, R-Elists wrote: Nonsense. I had to score this list -2000 just to keep it from scoring so darn high that it was hitting the 'automatic' rejection at the SMTP gate before any of my whitelists could function. Charles, you would be better off properly whitelisting the SA mailing list... depending on your situation, possibly to and from... That -2000 score IS the 'whitelisting'. As mentioned in OP, my SMTP gateway is set to detect mail scoring very high (over 10) and issue an SMTP REJECT response, so that I don't have to deal with the bounce, or an overly cluttered spam file. The very rare false positive results in the sender seeing their rejection, so they see what to fix in their mail. Works well except for cases like the SA list where I trip over my own poison pill rules LOL also possibly telling bayes to ignore those emails to and from as well... Sadly, with such a diverse user base, I cannot use a single Bayes DB that would work well for all our users. My SMTP gateway (Mail Avenger) works best if mail is scanned for *all* recipients, and so it is not possible to use individual per-user Bayes. This is not an SA problem, but just the nature of the SMTP gateway. It has to decide to accept or reject the DATA transaction for ALL recipients. Once mail proves to be lower scoring than the 10 threshold, individual user whitelists and blacklists come into play, and other special per-user tests, but that merely results in mail being diverted to their 'spamtrap' folder. I do not 'bounce' mail once the SMTP gate is closed. :) - Charles
RE: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
From: Warren Togami [mailto:wtog...@redhat.com] Subject: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available ... - if module Digest::SHA is not available, a module Digest::SHA1 will be used, but at least one of them must be installed; a DKIM plugin requires Digest::SHA (the older Digest::SHA1 does not support sha256 hashes), so in practice the Digest::SHA is required It appears that Net::DNS requires Digest::HMAC_MD5 and that Digest::HMAC_MD5 requires Digest::SHA1. So that for full functionality, both SHA and SHA1 are needed.
Re: Suggestion for use by ANY whitelist service....
On Mon, 7 Dec 2009, Ted Mittelstaedt wrote: Yes, this is the grand new frontier of e-mail marketing. Technically, you *are* opting-in. It meets satisfactory criteria because you are using some other form of identification to substantiate that you are *really* you (you are buying stuff). But it puts the burden back on the customer to remember to later 'opt out' after the genuine purpose for having that e-mail has been completed. Very sneaky. So, technically if I hire someone to kill you, I'm technically not guilty of murder since I didn't pull the trigger? Technically speaking. Technically speaking, your analogy is bad, but I'll work with it. To make it work, the two aspects that matter are: 1) You (murderer) used a sneaky method to get me to sign up for a service to be beaten up (I'm a masochist, okay?), but failed to notice the option that says in addition to the requested beating the customer is also asking to be nurdered. So technically it's not murder. At best it's assisted suicide. 2) When you hire someone to murder me, you show them that you got 'permission' on your website form, so the guy you hire doesn't think he's being asked to murder anyone, but merely provide a *requested* service. The arguments and issues with respect to that third party is to exercise due dilligence in determining whether I *really* MEANT to request my murder. :) But now, because 'technically' you have people 'opting-in' you once again face the problem that *some* people actually *want* the after-sale advertising e-mails, and some don't and consider it spam. What default score do you set in a situation like that? How much strength does a whitelist get? Well, since it's a MINORITY of my users that WANT the spam We've all agreed that spam, by definition is UNWANTED (advertising) mail, therefore your above statement is an oxymoron. There is NO SUCH THING as 'wanted spam'. This looks like a pathetic word game to get around the fact that some people actually want the mail that YOU don't. So it's spam to YOU, but that does not make it spam for them, and their right to have their WANTED (AKA NON-SPAM-TO-THEM) mail is just as important, or more so, as your right to blindly stop every ad you can. Stop mussing up the arguments with idiotic straw man arguments. Or it will quickly become a one-sided argument. Because the fact is if I use Habeas then the majority who DON'T want the marketing stuff, (or don't care either ay) even though they technically signed up for it, now have the burden of unsubscribing or blacklisting. Yes, that burden exists. Is it fair? Not really. That's why companies like Habeas need to raise their standards to ensure that proper 'double' opt-in is used for all lists. Any website hiding 'we can send you more email' in their boilerplate/policy rather than as a clear check here to receive future mail should not be whitelisted. Any website that 'checks the box for you' should NEVER get accreditation. Indeed, if anyone ever starts to identify those kinds of sites, I'd blacklist them, just for that sleazy practice. :) BUT WE'RE NOT TALKING ABOUT THIS. The examples cited in recent posts have been genuine unsolicited mails. Mail to honeypot addresses, etc. There is an abuse issue, and it is not related to the otherwise worthwhile point made above. Didn't bother to address this point, did you? That's why Habeas customers need a whitelist in the first place - because they are adopting a point of view of what spam is that is contrary to what most users hold. This is self-defeating hyperbole. My first instinct is to argue with this brash mis-statement of their Who is their That's your reponse? You use brash hyperbole to totally skew the motives of Habeas and the people who might use it, and you think to question who I refer to rather than face the bald lie in your hyperbole? The real truth of it is Habeas is operating in that grey area of trying to please 2 opposing camps. On the one side they have the e-mail admins that aren't going to use them unless they can convince those admins to sign on, and unless they can, they won't have anything to sell the mass-marketers. On the other side they have the mass-marketers who have an incentive to use guile, and sneakiness as you said, to create large mailing lists of users who may or many not want to be on those lists, and a huge incentive to push Habeas to ignore complaints about their mailings. Which is all VERY GOOD, and leads back to the single fundamental difference we can make here. Regardless of our *opinions*, if the NUMBERS show that Habeas is letting through spam, then SA is going to adjust its scores accordingly (though I sometimes wish they would react more quickly with interim updates to scores/tests at least every few months). So Habeas ultimately WANTS to keep *us* happy. You and me. My problem with Habeas, and the reason that I'll never use them on any
How to score jokes from non-spam sources
Some of my users have people they normally to corrospond with, but who also send large numbers of massivly CC'd jokes. Does anybody have an example of a rule that would score messages with large numbers of CCs higher, without hosing filtering for the user's normal messages? Thanks! Terry
Re: How to score jokes from non-spam sources
On Tue, 8 Dec 2009, Terry Carmen wrote: Some of my users have people they normally to corrospond with, but who also send large numbers of massivly CC'd jokes. Does anybody have an example of a rule that would score messages with large numbers of CCs higher, without hosing filtering for the user's normal messages? I don't think the number of CC's alone would qualify (and might not be present if someone properly uses Bcc), but many joke mails tend to accumulate nested 'forwarding' headers You would have to examine a few pieces for the pattern, but it should be fairly easy to identify mail that has been repeatedly forwarded from peson to person - C
Re: How to score jokes from non-spam sources
Terry Carmen wrote:
Some of my users have people they normally to corrospond with, but who
also send large numbers of massivly CC'd jokes.
Does anybody have an example of a rule that would score messages with
large numbers of CCs higher, without hosing filtering for the user's
normal messages?
header __MANY_CC_10CC =~ /([^,\s]+,\s*){10}/
/Per Jessen, Zürich
Re: How to score jokes from non-spam sources
Charles Gregory wrote: On Tue, 8 Dec 2009, Terry Carmen wrote: Some of my users have people they normally to corrospond with, but who also send large numbers of massivly CC'd jokes. Does anybody have an example of a rule that would score messages with large numbers of CCs higher, without hosing filtering for the user's normal messages? I don't think the number of CC's alone would qualify (and might not be present if someone properly uses Bcc), but many joke mails tend to accumulate nested 'forwarding' headers You would have to examine a few pieces for the pattern, but it should be fairly easy to identify mail that has been repeatedly forwarded from peson to person That would help quite a bit. I hadn't thought about the forwarding, but most of them have accumulated many levels of nested quotes. Thanks! Terry
Re: How to score jokes from non-spam sources
Per Jessen wrote:
Terry Carmen wrote:
Some of my users have people they normally to corrospond with, but who
also send large numbers of massivly CC'd jokes.
Does anybody have an example of a rule that would score messages with
large numbers of CCs higher, without hosing filtering for the user's
normal messages?
header __MANY_CC_10CC =~ /([^,\s]+,\s*){10}/
Cool regex!
Thanks,
Terry
Re: [sa] RE: Suggestion for use by ANY whitelist service....
On 08/12/2009 16:35, Charles Gregory wrote: Sadly, with such a diverse user base, I cannot use a single Bayes DB that would work well for all our users. My SMTP gateway (Mail Avenger) works best if mail is scanned for *all* recipients, and so it is not possible to use individual per-user Bayes. This is not an SA problem, but just the nature of the SMTP gateway. It has to decide to accept or reject the DATA transaction for ALL recipients. Once mail proves to be lower scoring than the 10 threshold, individual user whitelists and blacklists come into play, and other special per-user tests, but that merely results in mail being diverted to their 'spamtrap' folder. I do not 'bounce' mail once the SMTP gate is closed. :) In cases were there is only a single recipient, I run SpamAssassin at SMTP time as the destination user. In cases where there are multiple recipients, it runs as the nobody user. This allows me to have per user preferences and bayes applied to the vast majority of incoming mail, during SMTP; only a tiny proportion of incoming mail here is multi-recipient... YMMV -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ Technical Blog: https://secure.grepular.com/blog/
RE: Suggestion for use by ANY whitelist service....
On Tue, 8 Dec 2009, Mike Cardwell wrote: On 08/12/2009 16:35, Charles Gregory wrote: . My SMTP gateway (Mail Avenger) works best if mail is scanned for *all* recipients, and so it is not possible to use individual per-user Bayes. In cases were there is only a single recipient, I run SpamAssassin at SMTP time as the destination user. Unfortunately, Mail Avenger does not have a mechanism to make decisions like that. I simply tell it which script to run against the body/data. If that script has user-specific code, the SMTP engine forces all recipients after the first to tempfail before it ever sees the body. Not the best design, but at least for me it is a simple script-controlled way of putting SA on the SMTP transaction. :) This also prevents determination of almost-full mailbox conditions, so that I sometimes have to generate bounces... :( I've written to the Mail Avenger author, hoping he'll add a 'feature' to distinguish when there is only one recipient and allow scripts to do more under that condition no response yet :) - C
Re: Suggestion for use by ANY whitelist service....
Charles Gregory wrote: On Mon, 7 Dec 2009, Ted Mittelstaedt wrote: Yes, this is the grand new frontier of e-mail marketing. Technically, you *are* opting-in. It meets satisfactory criteria because you are using some other form of identification to substantiate that you are *really* you (you are buying stuff). But it puts the burden back on the customer to remember to later 'opt out' after the genuine purpose for having that e-mail has been completed. Very sneaky. So, technically if I hire someone to kill you, I'm technically not guilty of murder since I didn't pull the trigger? Technically speaking. Technically speaking, your analogy is bad, but I'll work with it. I see no point in beating that analogy to the extent that you have, the point I made is that it's pretty apparent that purveyors of this grand new frontier are lying when they make the claim that just because they manage with clever fine print language to put the onus back on the customer to remember to opt-out later, that this somehow means the customer put forth effort to subscribe to their bulk-email-advertising. But now, because 'technically' you have people 'opting-in' you once again face the problem that *some* people actually *want* the after-sale advertising e-mails, and some don't and consider it spam. What default score do you set in a situation like that? How much strength does a whitelist get? Well, since it's a MINORITY of my users that WANT the spam We've all agreed that spam, by definition is UNWANTED (advertising) mail, therefore your above statement is an oxymoron. There is NO SUCH THING as 'wanted spam'. This looks like a pathetic word game to get around the fact that some people actually want the mail that YOU don't. So it's spam to YOU, but that does not make it spam for them, and their right to have their WANTED (AKA NON-SPAM-TO-THEM) mail is just as important, or more so, as your right to blindly stop every ad you can. The real issue is what constitutes WANTED mail. I'll agree that spam that is wanted is bulk-email-advertising if you will agree that bulk-email-advertising that is NOT wanted is spam, OK? Yes, that burden exists. Is it fair? Not really. That's why companies like Habeas need to raise their standards to ensure that proper 'double' opt-in is used for all lists. It is my understanding after reviewing the Habeas material that Habeas has defined multiple tiers of permission-based bulk-email-advertising so that bulk-email-advertising senders are classified now according to the level of opt-in they do. The Redbox-style bulk-email-advertisers are the lowest tier, the people actually running mailing lists that customers have to make significant effort to get on to, are the highest tier. Any website hiding 'we can send you more email' in their boilerplate/policy rather than as a clear check here to receive future mail should not be whitelisted. Any website that 'checks the box for you' should NEVER get accreditation. Indeed, if anyone ever starts to identify those kinds of sites, I'd blacklist them, just for that sleazy practice. :) Then you probably want to block the lowest level of Habeas-accredited bulk-email-advertisers since that appears to be what they are. BUT WE'RE NOT TALKING ABOUT THIS. The examples cited in recent posts have been genuine unsolicited mails. Mail to honeypot addresses, etc. There is an abuse issue, and it is not related to the otherwise worthwhile point made above. Didn't bother to address this point, did you? To most users there is no difference between spam and bulk-email-advertisements They DON'T WANT the bulk-email-advertisements even if they have allegedly given permission by supplying an e-mail address to do something like rent a DVD and overlooked unchecking the box in the fine print allowing the company to send bulk-email-advertisements to them. It is only a minority that will go out of their way to sign up for bulk-email-advertisements therefore, that minority should carry the burden of personally whitelisting these bulk-email-advertisements on a shared mailserver. Habeas's existence helps to make it more difficult for the MAJORITY of people to have these bulk-email-advertisements filtered from their mail stream, because now that the system admin is giving a free pass to all the alleged bulk-email-advertisers the majority now has the burden placed on it to unsubscribe from these mailing lists. This is the case unless Habeas changed their business practices to ONLY accredit bulk-email-advertisers who ran explicit opt-in (ie: the highest tier) But if Habeas did, they would not be using the term permission-based e-mail in their business marketing, they would be using opt-in which is the industry-recognized term. You seem to think that mail to a honeypot is the only form of abuse. I say that anytime a user gets a bulk-email-advertisement that they don't want, EVEN if they gave permission by
Re: Suggestion for use by ANY whitelist service....
Yet Another Ninja wrote: Save your bullets. Habeas is history... it's been swallowed and the new mothership will be in SA 3.3.0 meanwhile you'll probably want to disable the relevant rules. How about the DNSWL rules? Are they toast as well, or might they have more sane default scores?
RE: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
SpamAssassin version 3.3.0-beta1 running on Perl version 5.10.1 Solaris 9 Sparc I am getting the following errors in make test: t/timeout.t ... 5/27 # Failed test 5 in t/timeout.t at line 63 t/timeout.t ... 7/27 # Failed test 7 in t/timeout.t at line 71 t/timeout.t ... 9/27 # Failed test 9 in t/timeout.t at line 79 t/timeout.t ... 11/27 # Failed test 11 in t/timeout.t at line 87 t/timeout.t ... 13/27 # Failed test 13 in t/timeout.t at line 95 t/timeout.t ... 16/27 # Failed test 16 in t/timeout.t at line 108 # Failed test 17 in t/timeout.t at line 109 # Failed test 18 in t/timeout.t at line 110 t/timeout.t ... 22/27 # Failed test 22 in t/timeout.t at line 122 # Failed test 24 in t/timeout.t at line 124 t/timeout.t ... 25/27 # Failed test 25 in t/timeout.t at line 129 # Failed test 27 in t/timeout.t at line 131 t/timeout.t ... Failed 12/27 subtests Thanks, Larry -Original Message- From: Warren Togami [mailto:wtog...@redhat.com] Sent: Sunday, December 06, 2009 10:01 PM To: SpamAssassin Users List; Development discussions related to Fedora Core Subject: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available Apache SpamAssassin 3.3.0-beta1 is now available for testing.
Can sa-compile use distributed compile services, e.g. distcc/icecream?
Hi, I've just installed Spamassassin on an old/dedicated Mail Server. It runs fine. When I compile rules on that box with sa-compile, it takes forever, ~2-3 hours per run. I've got plenty of CPU lying around -- on different arch/OS-es. Typically, for just cc tasks, I can use 'distcc' or Suse's variant of it, IceCream, to offload CPU tasks from the underpowered server. Can 'sa-compile' be made to use these distributed cross-compile services? It would be great to offload the CPU tasks, still using, of course, all the local rules, headers, etc etc on the server. Thanks, BenDJ
Re: Suggestion for use by ANY whitelist service....
Assuming they below refers to Habeas. Please ignore this mail if it refers to Return Path. Ted Mittelstaedt wrote: They have had the option to do this already for years, now, and have elected to use implied threats to the world's ISP's, rather than regularly participating on this list. To my knowledge Return Path hasn't owned Habeas for years yet (I think they bought it a little more than a year ago or so). If your view of Return Path is the same as your view of Habeas your statement makes sense, but otherwise I think you ought to let your view of Return Path color your opinions of Habeas. This might still be a good time (though a little late) to get Habeas' current owners to make the necessary changes to the Habeas part of their company for the Habeas brand to get a a somewhat better reputation among anti-spam folk. After all, the reputation of Habeas can now tarnish the reputation of their main brand as well. Regards /Jonas -- Jonas Eckerman Fruktträdet Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
On Tuesday December 8 2009 23:27:19 Rosenbaum, Larry M. wrote: SpamAssassin version 3.3.0-beta1 running on Perl version 5.10.1 Solaris 9 Sparc I am getting the following errors in make test: t/timeout.t ... 5/27 # Failed test 5 in t/timeout.t at line 63 t/timeout.t ... 7/27 # Failed test 7 in t/timeout.t at line 71 t/timeout.t ... 9/27 # Failed test 9 in t/timeout.t at line 79 t/timeout.t ... 11/27 # Failed test 11 in t/timeout.t at line 87 t/timeout.t ... 13/27 # Failed test 13 in t/timeout.t at line 95 t/timeout.t ... 16/27 # Failed test 16 in t/timeout.t at line 108 # Failed test 17 in t/timeout.t at line 109 # Failed test 18 in t/timeout.t at line 110 t/timeout.t ... 22/27 # Failed test 22 in t/timeout.t at line 122 # Failed test 24 in t/timeout.t at line 124 t/timeout.t ... 25/27 # Failed test 25 in t/timeout.t at line 129 # Failed test 27 in t/timeout.t at line 131 t/timeout.t ... Failed 12/27 subtests Thanks for testing! Which version of a perl module Time::HiRes do you have installed? See what is reported by: $ perl -MTime::HiRes -le 'print Time::HiRes-VERSION' Could you please try upgrading this module if yours is rather old, and see if that helps. Mark
Re: ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
Thanks for testing! Which version of a perl module Time::HiRes do you have installed? See what is reported by: $ perl -MTime::HiRes -le 'print Time::HiRes-VERSION' Could you please try upgrading this module if yours is rather old, and see if that helps. P.S., does the following change to t/timeout.t on your system make any difference in test results? --- timeout.t 2009-12-09 03:29:12.0 +0100 +++ timeout.t 2009-12-09 03:29:19.0 +0100 @@ -23,3 +23,3 @@ use strict; -use Time::HiRes qw(time sleep); +use Time::HiRes qw(time sleep alarm); Mark
Note from SA PMC: Removal of an abusive list member
Dear List Members, As you are all aware there has been a lot of name calling going on lately and, in my opinion, at least one instance of what could be considered a threat. This is not acceptable behaviour in our community. What you are probably not aware of is that there has also been a number of instances of a certain list member sending abusive emails to Apache SpamAssassin project members and members of our mailing list community. This is not acceptable and will not be tolerated. As such the member has had their mailing list posting privileges revoked. They are no longer a welcomed member of our community. Please be aware that we are by no means singling out this member. We will not accept, nor tolerate, similar or other abuse towards us or our community by anyone at any time. We do, however, encourage rational, productive and civilized debate on our mailing lists. If you have been a target of any on- or off-list abuse please make the Apache SpamAssassin PMC aware of it. We can be reached at priv...@spamassassin.apache.org. The private@ list is moderated so it may take a while for your message to make it through. If you have been a target of any threats please make the appropriate authorities aware of the situation if you deem it appropriate to do so. Best Regards, Daryl C. W. O'Shea VP Apache, Chair Apache SpamAssassin (on behalf of the Apache SpamAssassin PMC)
Re: Note from SA PMC: Removal of an abusive list member
...if you feel the need to reply, please reply to this email. Not the original one in the thread. There is no need to copy responses to bo...@apache.org and priv...@sa. Thanks! Daryl On 08/12/2009 11:01 PM, Daryl C. W. O'Shea wrote: Dear List Members, As you are all aware there has been a lot of name calling going on lately and, in my opinion, at least one instance of what could be considered a threat. This is not acceptable behaviour in our community. What you are probably not aware of is that there has also been a number of instances of a certain list member sending abusive emails to Apache SpamAssassin project members and members of our mailing list community. This is not acceptable and will not be tolerated. As such the member has had their mailing list posting privileges revoked. They are no longer a welcomed member of our community. Please be aware that we are by no means singling out this member. We will not accept, nor tolerate, similar or other abuse towards us or our community by anyone at any time. We do, however, encourage rational, productive and civilized debate on our mailing lists. If you have been a target of any on- or off-list abuse please make the Apache SpamAssassin PMC aware of it. We can be reached at priv...@spamassassin.apache.org. The private@ list is moderated so it may take a while for your message to make it through. If you have been a target of any threats please make the appropriate authorities aware of the situation if you deem it appropriate to do so. Best Regards, Daryl C. W. O'Shea VP Apache, Chair Apache SpamAssassin (on behalf of the Apache SpamAssassin PMC)
