On 9-Dec-2009, at 07:04, Benny Pedersen wrote: > On ons 09 dec 2009 14:56:53 CET, LuKreme wrote >> I don't speak German, however with the help of Google I think the answer to your question is 'you don't'. As I recall, when moving from file-based bayes to MySQL based bayes, you have to retrain. > > no just --backup filebased bayes, and reconfigure to sql based bayes, and then --restore the bayes backup > > its only awl that cant be done from filebased to sql Ah, thanks for the clarification. I keep meaning to get around to switching my bayes to sql, but… -- Never age. Never die. Live for ever in that one last white-hot moment, when the crowd screamed. When every note was a heartbeat. Burn across the sky. You will never grow old. They will never say you died. --Soul Music
On ons 09 dec 2009 14:56:53 CET, LuKreme wrote > I don't speak German, however with the help of Google I think the > answer to your question is 'you don't'. As I recall, when moving > from file-based bayes to MySQL based bayes, you have to retrain. no just --backup filebased bayes, and reconfigure to sql based bayes, and then --restore the bayes backup its only awl that cant be done from filebased to sql -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
On Wed, 9 Dec 2009, Hans-Werner Friedemann wrote:
> Hallo zusammen!
>
> ich speichere meine Bayes-Daten (autolearn) bislang in Configuration
> Files.... Nun würde ich gern auf eine MySQL-DB umsteigen. Wie geht das
> mit dem Umzug (Konfiguration), ohne Daten zu verlieren? Hat man durch
> die Verwendung einer MySQL-DB eine bessere Performance zu erwarten?
I can't say how well (or even whether) you can transfer an existing BDB
bayes database to MySQL, but I will say that it's a good idea to keep your
training corpora available in case you need to retrain from scratch for
some reason.
Granted, that's difficult if you're autolearning, but you should keep your
initial training corpora as well as any other manually-selected training
messages, such as ones that were misclassified.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
6 days until Bill of Rights day
On 9-Dec-2009, at 03:15, Hans-Werner Friedemann wrote: > ich speichere meine Bayes-Daten (autolearn) bislang in Configuration Files.... > Nun würde ich gern auf eine MySQL-DB umsteigen. > Wie geht das mit dem Umzug (Konfiguration), ohne Daten zu verlieren? > Hat man durch die Verwendung einer MySQL-DB eine bessere Performance zu erwarten? I don't speak German, however with the help of Google I think the answer to your question is 'you don't'. As I recall, when moving from file-based bayes to MySQL based bayes, you have to retrain. -- He wasn't good or evil or cruel or extreme in any way but one, which was that he had elevated greyness to the status of a fine art and cultivated a mind that was as bleak and pitiless and logical as the slopes of Hell. --The Light Fantastic
Hans-Werner Friedemann wrote:
> Everytime I restart the Spamassassin Daemon I get the following Errors
> in my Logfile:
>
> Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line,
> skipping, in "/etc/mail/spamassassin/local.cf": 10_local_whitelist.cf
> Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line,
> skipping, in "/etc/mail/spamassassin/local.cf": 10_local_extratest.cf
> Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line,
> skipping, in "/etc/mail/spamassassin/local.cf": 10_local_imagehosting.cf
>
> What´s the matter?
>
>
you don't need those lines, SA will include anything with a *.cf in that
directory anyway.
besides, the syntax is 'include 10_local_whitelist.cf'. not
'10_local_whitelist.cf'
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
_________________________________________________________________________
Everytime I restart the Spamassassin Daemon I get the following Errors in my Logfile: Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": 10_local_whitelist.cf Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": 10_local_extratest.cf Wed Dec 9 09:49:25 2009 [12309] info: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": 10_local_imagehosting.cf What´s the matter?
Lucio Chiappetti wrote:
> whitelist_from xyzt@lambrate.inaf.it
> whitelist_from xyzt@iasf-milano.inaf.it
> whitelist_from_rcvd *@lambrate.inaf.it lambrate.inaf.it
> whitelist_from_rcvd *@iasf-milano.inaf.it lambrate.inaf.it
>
> ... the word "supplement" leaves me perplexed. Does this mean the two
> conditions above are ANDed instead of ORed ?
it basically means, use whitelist_from_rcvd if you can, so its ORed.
(but use spf or dkim whitelisting if you can, and SA whitelist only
subtracts -100 points, where amavis would just whitelist it.
see amavis group) but don't whitelist a local user without _from
rcvd,dkim or spf
> If so, messages coming e.g. from root@ourserver.lambrate.inaf.it
> should not be subject to the whitelist_from_rcvd (which is not what we
> want).
>
whitelist_from xyzt@lambrate.inaf.it
you didn't include root@ourserver.lambrate.inaf.it, only lambrate.inaf.it.
either case, lots of spammers use the 'from/to' address (forge the from
address), so whitelisting anyone on your local network that way WILL get
them spam.
use dkim/spf whitelisting or from_rcvd.
whitelist_from_rcvd *@lambrate.inaf.it lambrate.inaf.it
you didn't include 'ourserver' in that glob
also, LOCALLY generated emails might look like 'localhost'.
> We did also a check_whitelist /etc/mail/spamassassin/awlst/awl looking
> for address root@ourserver.lambrate.inaf.it and ip=155.253 (so truly
> from our LAN), and found a score of -1.0 (which should mean it is
> correctly whitelisted).
>
that is AWL, not SA whitelisting.
don't confuse the two.
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________
btw might be worth getting this into a bug. On Wed, Dec 9, 2009 at 02:30, Mark Martinec <Mark.Martinec+sa@ijs.si<Mark.Martinec%2Bsa@ijs.si> > wrote: > > 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.000000000 +0100 > +++ timeout.t 2009-12-09 03:29:19.000000000 +0100 > @@ -23,3 +23,3 @@ > use strict; > -use Time::HiRes qw(time sleep); > +use Time::HiRes qw(time sleep alarm); > > > > > Mark > > -- --j.
We have an institute-wide spamassassin+amavisd arrangement running on our
mx's, which generally behaves very well. Spam is quarantined in a system
wide folder, and then a daily crontab sends a "spam report" to each user
(so that they can reclaim false positives, which occurs about once per
month).
We have this in the spamassassin systemwide local.cf
whitelist_from xyzt@lambrate.inaf.it
whitelist_from xyzt@iasf-milano.inaf.it
whitelist_from_rcvd *@lambrate.inaf.it lambrate.inaf.it
whitelist_from_rcvd *@iasf-milano.inaf.it lambrate.inaf.it
which we interpreted as :
- everything coming "apparently" (From kwd) xyzt (not the real username,
anyhow it's our system manager personal account) should pass unfiltered
- everything coming THROUGH (Received kwd) one of our local machines,
from an user in either one of our two domains, should pass unfiltered
Now reading "perldoc Mail::SpamAssassin::Conf", I find
whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
Use this to supplement the whitelist_from addresses with a
check against the Received headers.
... the word "supplement" leaves me perplexed. Does this mean the two
conditions above are ANDed instead of ORed ?
If so, messages coming e.g. from root@ourserver.lambrate.inaf.it should
not be subject to the whitelist_from_rcvd (which is not what we want).
In fact we noticed (for the first time, and after a long weekend holiday
during which there was a burst of spam, which was quenched in a couple of
days) that a few of our daily spam reports (originated by the crontab and
sent as root@ourserver.lambrate.inaf.it) were quarantined (and also the
relevant mailer-daemon replies), with a score marginally above threshold.
We did also a check_whitelist /etc/mail/spamassassin/awlst/awl looking for
address root@ourserver.lambrate.inaf.it and ip=155.253 (so truly
from our LAN), and found a score of -1.0 (which should mean it is
correctly whitelisted).
Nevertheless the reports were quarantined. So the suspects are :
- whitelist_from_rcvd does NOT unconditionally whitelist messages
irrespective of other scores
- whitelist_from_rcvd is de facto NOT ENABLED for root (because of
the AND/OR confusion quoted above)
Any clue ? Thanks
--
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
Multi pertransibunt et augebitur scientia
Francis Bacon Instauratio Magna (http://tinyurl.com/2j3qk5)
------------------------------------------------------------------------
> R-Elists wrote: > > > perkel wrote: > > I have yet to find ANY use for SPF. And SPF causes nothing but > problems. > > Marc, > > why nothing but problems? > > is a lot of your system "mail forward" orientated? > > care to elaborate w/o going into the same old SPF diatribe? > > maybe there is something useful you havent had the "aha" factor on... > > - rh On 07.12.09 11:59, Marc Perkel wrote: > Definitely no AHA. It breaks forwarding. Tell me about the aha. It does NOT break e-mail forwarding. What is _affected_ by SPF is mail forwarding without changing mail from:, which is already broken by design. Since the original sender sends mail to forwarder, not to forwarded address, and it's the forwarder, who sends mail to forwarded address - thus the forwarder should take care about deliverability and should not provide senders address. Btw, please configure your MUA to quote, and use plaintext e-mail. -- Matus UHLAR - fantomas, uhlar@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. 2B|!2B, that's a question!
Hallo zusammen! ich speichere meine Bayes-Daten (autolearn) bislang in Configuration Files.... Nun würde ich gern auf eine MySQL-DB umsteigen. Wie geht das mit dem Umzug (Konfiguration), ohne Daten zu verlieren? Hat man durch die Verwendung einer MySQL-DB eine bessere Performance zu erwarten?
> On 08/12/2009 11:01 PM, Daryl C. W. O'Shea wrote: >> 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. It never ceases to amaze me how worked up some people get about the spam problem. There are worse problems in life to get angry about. -- 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/
...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 board@apache.org and private@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 > private@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) >
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 private@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)
> 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.000000000 +0100 +++ timeout.t 2009-12-09 03:29:19.000000000 +0100 @@ -23,3 +23,3 @@ use strict; -use Time::HiRes qw(time sleep); +use Time::HiRes qw(time sleep alarm); Mark
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
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/
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
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:wtogami@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. >
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?
On 12/8/2009 9:38 PM, Ted Mittelstaedt wrote: > 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. 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.
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 NOT unchecking a "can we send you "bulk-email-advertisements" box, that instantly becomes spam - and thus it is ALSO ABUSE. And, I would also state that any time a user gets one of these "bulk-email-advertisements" that they did not EXPLICITLY sign up for, EVEN IF they don't object to it after getting it, that it is ALSO abuse. >>> > 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? > who DID you refer to? Your statement can be read either way and means differently depending on how it's read. >> 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. > No, what Habeas wants is to get SA to put the support into SA for their rankings, so that the typical "install-and-ignore" system admin will be automatically using the Habeas system once they install SA, whether they agree with it or not. >> My problem with Habeas, and the reason that I'll never use them on any >> mailserver I administer, is that they aren't trying to work with both >> those camps to bring them together. If they were, then a Habeas >> representative would be responding to the Habeas detractors posting on >> the SA mailing list, not you. > > Actually, there is a guy from Habeas on here. But is he really going to > talk rationally with someone who accuses him of being in the spammer's > pocket and/or redefining the word spam? No. And why not? It's those people that he needs to convince that he's doing a public service, not the ones who already agree with him. DUH! > Though honestly, given the > nature of this list, I find it a *very* weak response to simply say > "file a report" and then not respond when people say that is difficult > or doesn't get results. > > Is the 'date the UK' spam STILL coming through for those who complained > about it? If so, why hasn't Habeas acted on it yet? > >> 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. > > Implied threats? More hyperbole? Got an example? > >> Charles, perhaps in real life you ARE a Habeas employee, which is why >> you are so pro-Habeas. > > Actually, I'm pro-make-Habeas-listen-and-respect. Your hyperbole makes > us all sound like a bunch of irrational whiners who are 'anti-Habeas' > which simply results in a deaf ear where we could really use it the most. > >> I respect a company that is out there doing something that I disagree >> with, and is willing to come and debate with me why they have chosen >> to do it... > > Then stop with the hyperbole. Stop calling wanted mail 'spam', and > instead open a respectful discussion to have someone at Habeas > *question* whether the standards of 'wanted' mail are too loose. Why? Habeas has not proven to me yet that what they are doing is anything more than helping increase "bulk-email-advertising" which ultimately just gives more coverage to the real spammers who aren't participating in Habeas in the first place. In my opinion the issue isn't whether Habeas is doing what their doing the "right" or the "wrong" way. There is NO "right" way to support bulk-e-mail non-opt-in mailers, period. Until the bulk-email-advertisers PAY $0.25 or $0.15 or $0.44 or whatever the paper-bulk-mailers pay for EACH one of their "bulk-email-advertisements" they send out, they are nothing more than flies on the back of the dog, stealing resources from everyone else. When my employer has to drop thousands of dollars into mailserver hardware to buy a bigger and faster server so as to handle the increased workload that these bulk-email-advertisers are laying on, a workload that 98% of my paying customers don't give a rat's ass if it comes into their mailbox or not, my employer has less money to pay ME, thus, in my view, those bulk-email-advertisers are stealing money out of MY pocket. > Calling > it 'spam' just makes you look like someone who should be ignored. And > then they paint us all with that same 'birds of a feather' brush, just > the same way you wanted to paint me as a Habeas employee. Really, do you > think they read that and want to take you at all seriously? You sound > like a conspiracy nut. > > Which is as close to ad-hominem arguing as I ever want to get, but the > point is to start being a bit more mature, and not shoot the REST of us > here in the metaphoric 'foot' while we'er trying to build a respectful > relationship with people who just *might* tighten up their rules if we > tell them about problems nicely. > When those people see fit to explain how they are HELPING the Internet, then I'll listen. So far, all I hear is crickets chirping. Ted
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
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/
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_10 CC =~ /([^,\s]+,\s*){10}/
>
>
>
Cool regex!
Thanks,
Terry
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
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_10 CC =~ /([^,\s]+,\s*){10}/
/Per Jessen, Zürich
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
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
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 > mailserver I administer, is that they aren't trying to work with both those > camps to bring them together. If they were, then a Habeas representative > would be responding to the Habeas detractors posting on > the SA mailing list, not you. Actually, there is a guy from Habeas on here. But is he really going to talk rationally with someone who accuses him of being in the spammer's pocket and/or redefining the word spam? No. Though honestly, given the nature of this list, I find it a *very* weak response to simply say "file a report" and then not respond when people say that is difficult or doesn't get results. Is the 'date the UK' spam STILL coming through for those who complained about it? If so, why hasn't Habeas acted on it yet? > 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. Implied threats? More hyperbole? Got an example? > Charles, perhaps in real life you ARE a Habeas employee, which is why > you are so pro-Habeas. Actually, I'm pro-make-Habeas-listen-and-respect. Your hyperbole makes us all sound like a bunch of irrational whiners who are 'anti-Habeas' which simply results in a deaf ear where we could really use it the most. > I respect a company that is out there doing something that I disagree > with, and is willing to come and debate with me why they have chosen to > do it... Then stop with the hyperbole. Stop calling wanted mail 'spam', and instead open a respectful discussion to have someone at Habeas *question* whether the standards of 'wanted' mail are too loose. Calling it 'spam' just makes you look like someone who should be ignored. And then they paint us all with that same 'birds of a feather' brush, just the same way you wanted to paint me as a Habeas employee. Really, do you think they read that and want to take you at all seriously? You sound like a conspiracy nut. Which is as close to ad-hominem arguing as I ever want to get, but the point is to start being a bit more mature, and not shoot the REST of us here in the metaphoric 'foot' while we'er trying to build a respectful relationship with people who just *might* tighten up their rules if we tell them about problems nicely. - C
> From: Warren Togami [mailto:wtogami@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.
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
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.
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.
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 :)
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! -- View this message in context: http://old.nabble.com/Possible-to-whitelist-*all*-incoming-emails-that-contain-specific-text-in-the-subject-line--tp26688677p26688677.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
On 07/12/2009 22:16, JaredDetroit wrote: > Hi, I don't know if I'm posting the right type of content here but I'm sure > I'll find out. I'm trying to create a newsletter and I keep receiving the > following spam assassin scores: > > I'm sending out a basic HTML newsletter with a pdf attachment to subscribers > in Aweber. I've searched extensively for solutions to these scores but I > only find people with the same issues or random SA dumps. > > 1.3 URI: URI hostname has long hexadecimal sequence > Does anyone know what the issue is with the URI? I can't find anything on > this. I don't see anything that could be an issue in my message. > > 1.7 BODY: Message only has text/html MIME parts > I believe this is if you only have an HTML version of an email. I have both > a text and HTML version... > > 2.8 BODY: BASE64_LENGTH_79_INF > I know that it's because the length of Base64 is longer than 79 but I can't > find any information about what this actually is and what could cause it. > > I really appreciate any help. Paste the raw source of an example email into http://pastebin.com/ after it has been processed by SpamAssassin, with the report header, then reply to this email with the link. Then we can look at what is causing the rules to trigger. -- 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/
On Mon, 7 Dec 2009, JaredDetroit wrote: > I really appreciate any help. We'd be most able (and willing) to help if we had an actual example message to look at. If you can post a complete scored message, including _all_ headers, to a website like pastebin or to a website you control, and send the URI for that sample to the list (_please_ don't send the sample message itself to the list!), then we can take a look at it and perhaps make meaningful suggestions. -- John Hardin KA7OHZ http://www.impsec.org/~jhardin/ jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. -- Lyndon B. Johnson ----------------------------------------------------------------------- 8 days until Bill of Rights day
Some good news... possibly. I finally complained to ARIN (for the 4th time) that the contact information for the Inktomi address blocks was incorrect, as Inktomi hasn't existed as a corporate (and legal) entity for some time... it was acquired by Yahoo! 3 years ago, and their address blocks have all been repurposed for Yahoo! server infrastructure and as such should reflect that reality. So ARIN flagged the address block registry information as INVALID, and will ask the Yahoo contact person (Joan Luster) to address this issue next time they are in communication with her. Why is this useful? Well, every time I personally report an issue with them, I get the very annoying auto-reply that says: > Once you have identified the IP address, you can conduct an IP lookup to > determine which ISP provides this person with Internet access. One such > lookup tool you may want to try is: > > http://www.arin.net/whois/ > > You can then attempt to contact that ISP to report any abuse activities > occurring within their service. > which raises my blood pressure, because ARIN whois indicates they *are* the owner of that netblock (as Inktomi). The upshot is that the OrgID: and NetName: records will no longer be INKT and INKTOMI-NET-* respectively... so that gives them one less rock to hide under. (And it's entirely possible their autoresponders are mistakenly keying off these particular record fields when doing prefiltering... giving them the benefit of the doubt.) We'll see how it goes, and I'll try to keep the list current. Keep your fingers crossed. -Philip
Hi, I don't know if I'm posting the right type of content here but I'm sure I'll find out. I'm trying to create a newsletter and I keep receiving the following spam assassin scores: I'm sending out a basic HTML newsletter with a pdf attachment to subscribers in Aweber. I've searched extensively for solutions to these scores but I only find people with the same issues or random SA dumps. 1.3 URI: URI hostname has long hexadecimal sequence Does anyone know what the issue is with the URI? I can't find anything on this. I don't see anything that could be an issue in my message. 1.7 BODY: Message only has text/html MIME parts I believe this is if you only have an HTML version of an email. I have both a text and HTML version... 2.8 BODY: BASE64_LENGTH_79_INF I know that it's because the length of Base64 is longer than 79 but I can't find any information about what this actually is and what could cause it. I really appreciate any help. Thanks, Jared -- View this message in context: http://old.nabble.com/Trouble-finding-info-on-Spam-issues-tp26685217p26685217.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.