doesn't drop email above required hits
Anyone uses qmail here. I just recently setup qmail with qmail-scanner and clamav and spamassin as scanner array. I just noticed in my spamassassin log that even though the required hits in spamassassin is 5, it still allow those email which has greater value of 5. Below is the logs of my spamassassin Thu Oct 23 13:21:47 2008 [4635] info: spamd: handle_user unable to find user: '[EMAIL PROTECTED]' Thu Oct 23 13:21:47 2008 [4635] info: spamd: checking message <[EMAIL PROTECTED]> for [EMAIL PROTECTED]:511 Thu Oct 23 13:22:01 2008 [4635] info: spamd: identified spam (12.5/5.0) for [EMAIL PROTECTED]:511 in 14.0 seconds, 32792 bytes. Thu Oct 23 13:22:01 2008 [4635] info: spamd: result: Y 12 - DNS_FROM_RFC_BOGUSMX,DYN_RDNS_AND_INLINE_IMAGE,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_MESSAGE,M IME_BASE64_TEXT,MIME_HTML_ONLY,RDNS_DYNAMIC,TVD_RCVD_IP scantime=14.0,size=32792,[EMAIL PROTECTED],uid=511,required_score=5.0,rhost=FREE-MX,raddr=127.0.0.1,rport=49631,mid=<[EMAIL PROTECTED]>,autolearn=spam Is there a config in local.that it will force to drop all those email that was tagged above the required hits. Here is my /etc/mail/spamassassin/local.cf required_hits 5 required_score 5 report_safe 0 rewrite_header Subject [SPAM] use_bayes 1 bayes_auto_learn 1 lock_method flock New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/ph/
Re: OT: unusual traffic from mail servers
Burton Windle a écrit : > Sorry for the off-topic post, but I can't think of a better list with > more sharp email server admins. > > I've just taken a new job with a company that does some (legit, opt-in, > with-working-remove-link, only sending to our paying customers) email > marketing. I'm seeing some very weird traffic from the remote email > servers that we are sending to, and can't figure out what it could be. > > Basically, we are seeing denied traffic on our firewall. The source of > the traffic is the mail servers we are sending to; it is coming FROM > their TCP/25, and going to some random high-level TCP port on our > sending host. If I didn't know better, I'd think it was denying part of > the three-way TCP handshake, but the email is flowing, and the mail > queues are low. > Sniff traffic and you'll probably see that the packets you drop are part of the smtp transaction and that your firewall is forcing the other end to retransmit. Make sure that your firewall can support the load. and while you are at it, make sure it correctly implements TCP window scaling and that it doesn't drop (all) icmp traffic. I'm saying this because it's a common misconfiguration/bug. > So far, I can count 1,019 unique external email servers which are doing > this, from all parts of the IPv4 address space. > > Does anybody know what this is from? I'm seeing it a lot from yahoo, > comcast, aol, mostly the larger players. >
Re: bogusmx [Was: DNS restrictions for a mail server]
Michael Scheidell a écrit : >> 3banatomy.co.kr > > Minor point, rfc's don't require an mx record an a record will satisfy the > rfc's just fine. (and one of the major saas email anti-spam providers used > to use cname records for all their clients.. Yes, they took them off, one at > a time, as clients complianted that they were blacklisted by > bogusmx.rfc-ignorant.com.. > "other" customers should complain too: $ host smtp.secureserver.net smtp.secureserver.net is an alias for smtp.where.secureserver.net. smtp.where.secureserver.net has address 64.202.166.12 > Maybe rfc's need to change.. There is no modern software that can't send to > a cnamed mx or mx'ed cname, whatever. > > > > host -t a 3banatomy.co.kr > 3banatomy.co.kr has address 211.189.26.139 > mea culpa. I've been tooo lazy. I'll have to script that so that I don't forget again!
Re: OT: DNS restrictions for a mail server
>># host mail.example.com >>mail.example.com is an alias for hostname.example.com. >>hostname.example.com has address 1.2.3.4 > > >Wrong. The MX record has to point to an A name, not a CNAME. what? MX record's data field is a domain name That domain name owns one or more A records. With mail, the shortest resolution path is always best practice, and resolving through a CNAME is not the shortest. Similarly, an MX's IP should have only one PTR record, whose domain name in the data field "matches" with an A record: d.c.b.a.in-addr.arpa. PTR label.domain.tld. label.domain.tld. A a.b.c.d Len __ IMGate OpenSource Mail Firewall www.IMGate.net
Re: OT: DNS restrictions for a mail server
--On Tuesday, October 21, 2008 2:37 PM +0200 Sebastian Ries < [EMAIL PROTECTED]> wrote: # host -t MX example.com example.com mail is handled by 100 mail.example.com. # host mail.example.com mail.example.com is an alias for hostname.example.com. hostname.example.com has address 1.2.3.4 Wrong. The MX record has to point to an A name, not a CNAME. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: bogusmx [Was: DNS restrictions for a mail server]
At 15:01 22-10-2008, Michael Scheidell wrote: Maybe rfc's need to change.. There is no modern software that can't send to a cnamed mx or mx'ed cname, whatever. I doubt that it will be changed to accommodate that. It's not only a matter of software. Such a change would have an impact on DNS. Regards, -sm
Re: OT: unusual traffic from mail servers
At 13:42 22-10-2008, Burton Windle wrote: Basically, we are seeing denied traffic on our firewall. The source of the traffic is the mail servers we are sending to; it is coming FROM their TCP/25, and going to some random high-level TCP port on our sending host. If I didn't know better, I'd think it was denying part of the three-way TCP handshake, but the email is flowing, and the mail queues are low. The traffic is not unusual given that you are originating the connection to the remote mail server. The above behavior may be caused by a misbehaving firewall. Regards, -sm
Re: Rule writing - spamassassin-3.2.5-1
On Wed, 22 Oct 2008, Tom Brown wrote: I am getting loads of spam about various topics but a common theme is the URL within the message and that is http://X7zfqxF7.spaces.live.com/ That was discussed within the past week, check the mailing list archives. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The yardstick you should use when considering whether to support a given piece of legislation is "what if my worst enemy is chosen to administer this law?" --- 13 days until the Presidential Election
Re: unusual traffic from mail servers
> Sorry for the off-topic post, but I can't think of a > better list with more sharp email server admins. > > I've just taken a new job with a company that does some > (legit, opt-in, with-working-remove-link, only sending to > our paying customers) email marketing. I'm seeing some > very weird traffic from the remote email servers that we > are sending to, and can't figure out what it could be. > > Basically, we are seeing denied traffic on our firewall. > The source of the traffic is the mail servers we are > sending to; it is coming FROM their TCP/25, and going to > some random high-level TCP port on our sending host. If I > didn't know better, I'd think it was denying part of the > three-way TCP handshake, but the email is flowing, and > the mail queues are low. > > So far, I can count 1,019 unique external email servers > which are doing this, from all parts of the IPv4 address > space. > > Does anybody know what this is from? I'm seeing it a lot > from yahoo, comcast, aol, mostly the larger players. I'm not an expert, but traffic from their port 25 to your port should be just return messagesfor normal smtp. Your server opened the connection from to their 25, and is getting responses thru that pipe. Maybe your firewall is broken? There is nothing to report, especially when it does not block it, and mail passes.
Re: bogusmx [Was: DNS restrictions for a mail server]
> 3banatomy.co.kr Minor point, rfc's don't require an mx record an a record will satisfy the rfc's just fine. (and one of the major saas email anti-spam providers used to use cname records for all their clients.. Yes, they took them off, one at a time, as clients complianted that they were blacklisted by bogusmx.rfc-ignorant.com.. Maybe rfc's need to change.. There is no modern software that can't send to a cnamed mx or mx'ed cname, whatever. host -t a 3banatomy.co.kr 3banatomy.co.kr has address 211.189.26.139 -- Michael Scheidell, CTO >|SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com _
Re: OT: DNS restrictions for a mail server
Dan McDonald wrote on Wed, 22 Oct 2008 11:11:13 -0500: > I'm not certain what you are talking about. SPF is very commonly > deployed. > > http://www.openspf.org/Statistics I don't see that you can deduce "is very commonly deployed" from that page. > See especially http://utility.nokia.net/~lars/meter/spf.html These figures are bogus. > Lars Eggert added SPF to his set of experimental deployment meters. At the > moment his statistics covers only "top"-Alexa sites for ten countries and > the world, plus the domains used in e-mail addresses of current > Internet-draft authors. On that somewhat limited base almost half of > these "top"-domains publish some kind of SPF policy. BTW: have you checked how SPF plays out in your SA rules? I find that SPF_FAIL, SPF_HELO_PASS or SPF_PASS all have over 90/95% ham which makes the rules somewhat indistinguishable. This means that 95% of the mail that fails SPF is actually desired mail. On the other hand the SPF_HELO_PASS/SPF_PASS seems to be indicate of ham, it hits on 95% ham. e.g. you can use it for negative scoring at least a little bit. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Validating XML email
On Wednesday, October 22, 2008 11:31 AM +0200 Kai Schaetzl <[EMAIL PROTECTED]> wrote: This is far away from reality. What makes you think that XHTML mail would be any better formed than HTML? I bet some makers of those many crap HTML web mailers will just rename the Doctype if a client asks them about XHTML compatibility. Or add that Doctype and DTD finally. It's a question of standards, and of forward-going enforcement. We don't have to live in a world where we accept sloppy (and malicious) input. I don't really care if I don't get mail from a "crappy web mailer", esp. if it was written recently enough to think it knows anything about XML. If it promises well-formed XML and then fails to deliver on that promise, I don't see any reason to let it through, any more than I should let through mail with fouled-up headers or improper SMTP transactions. I hate that I have to tolerate bad stuff from old and broken but widely-deployed mail clients, but why should we have to tolerate it from new senders? Have you already tested on the sheer use of XHTML? Maybe there's no spammer using it, so you could use it for whitelist scoring, at least for a while? I started the thread precisely because I was poking through some uncaught spam and found a bunch claiming to be XHTML, but with all kinds of parsing errors, mostly mismatched quotes and tags. I'd like to know if any legitimate senders are claiming XML compliance and being as broken in their implementation, so that I can tell if it's worth pursuing an actual test. XML parsing is slow. You probably gain little accuracy with a lot of performance hit. How does a simple well-formedness test compare to virus scanning or SA's regex scan? (I don't need the actual parse tree and I suspect it's not necessary to check the DTD, so it should be possible to stream the test.)
Rule writing - spamassassin-3.2.5-1
Hi I am getting loads of spam about various topics but a common theme is the URL within the message and that is http://X7zfqxF7.spaces.live.com/ Does anyone know how i can write a rule to eliminate these? spamassassin-3.2.5-1.el4.rf thanks
OT: unusual traffic from mail servers
Sorry for the off-topic post, but I can't think of a better list with more sharp email server admins. I've just taken a new job with a company that does some (legit, opt-in, with-working-remove-link, only sending to our paying customers) email marketing. I'm seeing some very weird traffic from the remote email servers that we are sending to, and can't figure out what it could be. Basically, we are seeing denied traffic on our firewall. The source of the traffic is the mail servers we are sending to; it is coming FROM their TCP/25, and going to some random high-level TCP port on our sending host. If I didn't know better, I'd think it was denying part of the three-way TCP handshake, but the email is flowing, and the mail queues are low. So far, I can count 1,019 unique external email servers which are doing this, from all parts of the IPv4 address space. Does anybody know what this is from? I'm seeing it a lot from yahoo, comcast, aol, mostly the larger players. -- Burton Windle [EMAIL PROTECTED]
Re: OT: DNS restrictions for a mail server
McDonald, Dan a écrit : >>> On 22.10.08 15:49, mouss wrote: In my understanding, these are different concepts. In particular, RMX doesn't hijack the TXT record, which is one of the major sins of SPF. >>> Yes, but they both were designed to do the same work. SPF however can do >>> more. TXT was used because nothing else could, at least I think so. >>> > > RFC 4408, section 3.1.1, defines a new RR type for SPF. yes, but my feeling is that it's too late. The purists are long gone away. I think there were many tactical errors (SPF was presented as "simple to implement" thanks to TXT, instead of "will help in this and that. and for compatibility, we could use a TXT record...". other tactical errors were "SPF will solve the spam problem" [and no, I am not inventing that. search...] which appears to be one of the reasons why outblaze removed their SPF records). > But waiting for > everyone in the world to upgrade their DNS resolver to handle the new RR > type would have greatly slowed the adoption of SPF. > >> Maybe. but hijacking the TXT record got many people against SPF. and it >> doesn't look like SPF is widespread. so the "compatibility"/-ease of >> deployment argument didn't really catch. > > I'm not certain what you are talking about. SPF is very commonly > deployed. > depends on how to quantify "widespread". I personally consider 12.6% (after this many years) not to be "widespread", exceptionally since this includes "corner cases" (cases when almost everybody agrees that SPF is good for. This includes domains that never send mail, ... etc) as well as "+all" records. > http://www.openspf.org/Statistics > See especially http://utility.nokia.net/~lars/meter/spf.html > >
Re: koi8-r ok_locales and ok_languages
i linted ever time and never got any errors, with or without the TextCat plugin thanks for the tips on the inactive languages ill post the emails asap Karsten � wrote: >> # Set ok_locals to just en >> ok_locales en >> > > Please note that the comment above is wrong. It actually means > # all Western char sets in general > > >> # Set ok_languages to just english and french >> ok_languages en fr >> >> # Set inactive_languages all defaults plus russian and korean >> inactive_languages bs cy eo et eu fy ga gd is ko la lt lv rm ru sa sco sl yi >> > > By that, you disabled Russian and Korean detection, err, guessing. ;) > The TextCat plugin thus will never detect any mail written in either > Russian or Korean -- and subsequently will not be able to tell it is an > UNWANTED_LANGUAGE_BODY, because it didn't guess any language. > > In other words: TextCat will not identify text to be written in the > languages specified by inactive_languages, because you told it to. If it > can't guess a language with sufficient confidence, it can't be sure it > is outside the list of ok_languages either. > > See the previously referenced documentation for the TextCat plugin. > > > >> all three were run seperately and together with no difference, aka spam >> still got through >> >> spamassassin was restarted /etc/init.d/spamassassin restart >> > > With "ok_locales en", did you lint the configuration? Any issues? > > (Yes, I do advocate ok_locales usage, were appropriate. It kicks some > serious butt here.) > > > >> and we sent email messages to our servers with russian and korean encoding >> >> im dbl checkin on what if any of those rules actually were reported >> > > Can you put a raw, sample message up a pastebin or any accessible place > (don't paste, don't attach to a post), that you believe should be caught > but wasn't by ok_locales, please? > > > >> btw that doc u sent doesnt have anything on ok_language >> it could use some updates on that dont forget to tell people to uncoment >> the TextCat module there too >> > > Sorry, if I'm wrong, but... That suggests you did *not* lint your > configuration. You would have gotten a warning when using ok_languages > without the TextCat plugin enabled. > > guenther > > >
Re: Really force a Bayes expire
Graham Murray wrote on Fri, 29 Aug 2008 19:42:34 +0100: > As does the 'normal' Bayes expiry mechanism of triggering (or > attempting) an expire when the number of tokens reaches the threshold. coming back to this old thread. Unfortunately, the expiry uses the same algorithm for all Bayes storage engines. So, if it fails on dbm it also fails on SQL. I may have misunderstood that, but my understanding from the postings on this list over the past few years was that the expiry algorithm for the SQL store would be more "intelligent" and thus succeed where it doesn't succeed on dbm. That's definitely not true. It's the same and fails the same ;-) After conversion I had to extract the latest records up to the number I wanted to keep into a new table, replace the old table bayes_token with it, flush bayes_seen and adjust bayes_vars accordingly. As I'm now way under my normal expiry limit I don't know if the normal expiry will work now, but I hope it. If not, it's definitely easier to "manually" expire the Bayes database once it's in SQL. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: OT: DNS restrictions for a mail server
On Wed, 2008-10-22 at 17:04 +0200, mouss wrote: > Matus UHLAR - fantomas a écrit : > >>> On 21.10.08 19:31, mouss wrote: > Search for RMX (Reverse Mail eXchanger). > > On 22.10.08 15:49, mouss wrote: > >> In my understanding, these are different concepts. In particular, RMX > >> doesn't hijack the TXT record, which is one of the major sins of SPF. > > > > Yes, but they both were designed to do the same work. SPF however can do > > more. TXT was used because nothing else could, at least I think so. > > > RFC 4408, section 3.1.1, defines a new RR type for SPF. But waiting for everyone in the world to upgrade their DNS resolver to handle the new RR type would have greatly slowed the adoption of SPF. > Maybe. but hijacking the TXT record got many people against SPF. and it > doesn't look like SPF is widespread. so the "compatibility"/-ease of > deployment argument didn't really catch. I'm not certain what you are talking about. SPF is very commonly deployed. http://www.openspf.org/Statistics See especially http://utility.nokia.net/~lars/meter/spf.html -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: Tuning the bayes-system?
Jeff Mincy schrieb: >From: Heinrich Christian Peters <[EMAIL PROTECTED]> >Date: Wed, 22 Oct 2008 14:43:55 +0200 > >It learns all detected spam mails with a score of 8 (or higher) and not >hitted by BAYES_70 (or higher). > > I would learn all spam messages including the ones that hit BAYES_70-BAYES_99 > There are other tokens in the spam message that will be learned > and the known tokens in the message will reinforced as spam. OK, I will see, how many mails would be learned this way - perhaps I will change it. Heiner
Re: OT: DNS restrictions for a mail server
Matus UHLAR - fantomas a écrit : >>> On 21.10.08 19:31, mouss wrote: Search for RMX (Reverse Mail eXchanger). didn't go far for now. > >>> Yes, was kinda superseded by SPF, > > On 22.10.08 15:49, mouss wrote: >> In my understanding, these are different concepts. In particular, RMX >> doesn't hijack the TXT record, which is one of the major sins of SPF. > > Yes, but they both were designed to do the same work. SPF however can do > more. TXT was used because nothing else could, at least I think so. > Maybe. but hijacking the TXT record got many people against SPF. and it doesn't look like SPF is widespread. so the "compatibility"/-ease of deployment argument didn't really catch. >>> which may also require additional DNS queries :) >> sure, but this also prevents silly decisions by poor dns caching >> implementations (In particular, implementations that set a reputation >> based on one spf lookup). > > Hmm? hot... mail. This is one of the reasons I don't set SPF records anymore.
Re: Tuning the bayes-system?
Kai Schaetzl schrieb: > Heinrich Christian Peters wrote on Wed, 22 Oct 2008 14:43:55 +0200: > >> It learns all detected spam mails with a score of 8 (or higher) and not >> hitted by BAYES_70 (or higher). > > Which means you miss all the spam that got hit by Bayes and scored that > high and was not autolearned. I think with a good trained Bayes the above > will likely not learn much - e.g. you could just skip it ;-) You also do > know that you can adjust the autolearning threshold? > >> But now I am unsure about the autolearning. Should I train autolearned >> messages or not? Or, in other words, can spamassassin learn the same >> message twice (to learn faster), if I tell him to do so? > > As already said: it will just ignore these for learning. I just want to be sure... > BTW: Some MUA software will have problems with dots in headers. You either > should upgrade to a newer MailScanner or change %org-name% in your > MailScanner.conf. Thanks for info. I will change %org-name% - so I can keep the original debian-package. Heiner
Re: Tuning the bayes-system?
Heinrich Christian Peters wrote on Wed, 22 Oct 2008 14:43:55 +0200: > It learns all detected spam mails with a score of 8 (or higher) and not > hitted by BAYES_70 (or higher). Which means you miss all the spam that got hit by Bayes and scored that high and was not autolearned. I think with a good trained Bayes the above will likely not learn much - e.g. you could just skip it ;-) You also do know that you can adjust the autolearning threshold? > > But now I am unsure about the autolearning. Should I train autolearned > messages or not? Or, in other words, can spamassassin learn the same > message twice (to learn faster), if I tell him to do so? As already said: it will just ignore these for learning. BTW: Some MUA software will have problems with dots in headers. You either should upgrade to a newer MailScanner or change %org-name% in your MailScanner.conf. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: OT: DNS restrictions for a mail server
> > On 21.10.08 19:31, mouss wrote: > >> Search for RMX (Reverse Mail eXchanger). > >> > >> didn't go far for now. > > Yes, was kinda superseded by SPF, On 22.10.08 15:49, mouss wrote: > In my understanding, these are different concepts. In particular, RMX > doesn't hijack the TXT record, which is one of the major sins of SPF. Yes, but they both were designed to do the same work. SPF however can do more. TXT was used because nothing else could, at least I think so. > > which may also require additional DNS queries :) > > sure, but this also prevents silly decisions by poor dns caching > implementations (In particular, implementations that set a reputation > based on one spf lookup). Hmm? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. The only substitute for good manners is fast reflexes.
Re: OT: DNS restrictions for a mail server
On Wed, 2008-10-22 at 15:49 +0200, mouss wrote: [...] > In my understanding, these are different concepts. In particular, RMX > doesn't hijack the TXT record, which is one of the major sins of SPF. SPF has it's own record type. Use "TYPE99" if your named doesn't understand "SPF" yet. The TXT record "hack" was IMHO just a means to be able to deploy something. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services
Re: OT: DNS restrictions for a mail server
Matus UHLAR - fantomas a écrit : >> Jorge Valdes a écrit : >>> Matus UHLAR - fantomas wrote: >>> > The point of MX is to point to hosts that receive mail, if you send mail > to > someone. > > The point of PTR is to provide host name when you receive mail from > someone. > > The PTR has NOTHING to do with MX records and vice versa! > >>> So maybe there should be a new type of DNS record: MS (name suggestions >>> welcomed :) ) to let everyone know the server is an _outbound_ only mail >>> server: a server that sends mail for a domain that _may_ also receive >>> mail for the domain. This is a lot simpler than having to parse a SPF >>> record, which may also require additional DNS queries. > > On 21.10.08 19:31, mouss wrote: >> Search for RMX (Reverse Mail eXchanger). >> >> didn't go far for now. > > Yes, was kinda superseded by SPF, In my understanding, these are different concepts. In particular, RMX doesn't hijack the TXT record, which is one of the major sins of SPF. > which may also require additional DNS > queries :) sure, but this also prevents silly decisions by poor dns caching implementations (In particular, implementations that set a reputation based on one spf lookup).
Re: Tuning the bayes-system?
Heinrich Christian Peters wrote on Wed, 22 Oct 2008 14:30:13 +0200: > Why? Won't Bayes get better, if I tell spamassassin more clearly, which > mails are spam *and* which are not? In general, yes. But we were talking about a specific context (MailScanner quarantine and automated Bayes learning beyond that what SA already does) and in this context it's undesirable (prone to FPs) and unlikely to even exist (do you archive all ham? In some countries that may even be illegal.) Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Tuning the bayes-system?
From: Heinrich Christian Peters <[EMAIL PROTECTED]>
Date: Wed, 22 Oct 2008 14:43:55 +0200
Kai Schaetzl schrieb:
> Just checked what I actually do, here it is:
>
> yesterday=`date -d "-1 day" +"%Y%m%d"`
> sa-learn --spam --progress /var/spool/MailScanner/quarantine/
> ${yesterday}/spam/
I implemented a solution with sieve and sa-learn-cyrus:
> if allof (
>header :contains "X-heinrich-peters.zz-MailScanner-SpamScore"
"",
> # not header :contains "X-heinrich-peters.zz-MailScanner-SpamCheck"
"autolearn=spam",
>not header :regex "X-heinrich-peters.zz-MailScanner-SpamCheck"
"BAYES_(9|8|7)(0|5|9)"
> ){
>addflag "\\Seen";
>fileinto "INBOX.SpamAssassin.spam";
> }
It learns all detected spam mails with a score of 8 (or higher) and not
hitted by BAYES_70 (or higher).
I would learn all spam messages including the ones that hit BAYES_70-BAYES_99
There are other tokens in the spam message that will be learned
and the known tokens in the message will reinforced as spam.
But now I am unsure about the autolearning. Should I train autolearned
messages or not? Or, in other words, can spamassassin learn the same
message twice (to learn faster), if I tell him to do so?
The autolearned messages have already been learned, you do not need to
learn the message again.Nothing bad will happen if you do learn a
message again, other than wasting CPU time.
-jeff
Re: Tuning the bayes-system?
Kai Schaetzl schrieb:
> Just checked what I actually do, here it is:
>
> yesterday=`date -d "-1 day" +"%Y%m%d"`
> sa-learn --spam --progress /var/spool/MailScanner/quarantine/
> ${yesterday}/spam/
I implemented a solution with sieve and sa-learn-cyrus:
> if allof (
> header :contains "X-heinrich-peters.zz-MailScanner-SpamScore"
> "",
> # not header :contains "X-heinrich-peters.zz-MailScanner-SpamCheck"
> "autolearn=spam",
> not header :regex "X-heinrich-peters.zz-MailScanner-SpamCheck"
> "BAYES_(9|8|7)(0|5|9)"
> ){
> addflag "\\Seen";
> fileinto "INBOX.SpamAssassin.spam";
> }
It learns all detected spam mails with a score of 8 (or higher) and not
hitted by BAYES_70 (or higher).
But now I am unsure about the autolearning. Should I train autolearned
messages or not? Or, in other words, can spamassassin learn the same
message twice (to learn faster), if I tell him to do so?
Thanks,
Heiner
Re: Tuning the bayes-system?
Kai Schaetzl schrieb: > Benny Pedersen wrote on Wed, 22 Oct 2008 01:04:42 +0200 (CEST): > >> will olso be good to learn ham in that script > > no, it won't Why? Won't Bayes get better, if I tell spamassassin more clearly, which mails are spam *and* which are not? Heiner
Re: OT: DNS restrictions for a mail server
> Jorge Valdes a écrit : > > Matus UHLAR - fantomas wrote: > > > >>> The point of MX is to point to hosts that receive mail, if you send mail > >>> to > >>> someone. > >>> > >>> The point of PTR is to provide host name when you receive mail from > >>> someone. > >>> > >>> The PTR has NOTHING to do with MX records and vice versa! > >>> > >> > > So maybe there should be a new type of DNS record: MS (name suggestions > > welcomed :) ) to let everyone know the server is an _outbound_ only mail > > server: a server that sends mail for a domain that _may_ also receive > > mail for the domain. This is a lot simpler than having to parse a SPF > > record, which may also require additional DNS queries. On 21.10.08 19:31, mouss wrote: > Search for RMX (Reverse Mail eXchanger). > > didn't go far for now. Yes, was kinda superseded by SPF, which may also require additional DNS queries :) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Quantum mechanics: The dreams stuff is made of.
Re: Validating XML email
On Wed, 2008-10-22 at 11:31 +0200, Kai Schaetzl wrote: > This is far away from reality. What makes you think that XHTML mail would be > any better formed than HTML? I bet some makers of those many crap HTML web > mailers will just rename the Doctype if a client asks them about XHTML > compatibility. Or add that Doctype and DTD finally. > Just to add to that: most of the HTML mail I've seen lacks a Doctype line, so using that to control a validator is probably a nonstarter. For that matter, a remarkable amount also omit the , and even tags. AOL's mailer is one of these. MS MTAs all seem to use .., ..<\head> and .. tags but some add a Doctype and some don't. Martin
Re: Tuning the bayes-system?
Benny Pedersen wrote on Wed, 22 Oct 2008 01:04:42 +0200 (CEST): > will olso be good to learn ham in that script no, it won't Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Validating XML email
Kenneth Porter wrote on Tue, 21 Oct 2008 09:49:47 -0700: > For legacy "un-XML", it's probably reasonable to let them get away with it. > But once something declares itself XML, I think it's fair to ask for a bit > more compliance, at the very least well-formedness. This is far away from reality. What makes you think that XHTML mail would be any better formed than HTML? I bet some makers of those many crap HTML web mailers will just rename the Doctype if a client asks them about XHTML compatibility. Or add that Doctype and DTD finally. > > Does SA include any ability to test for this, and get some kind of score, > perhaps a simple error count, that can be used in a plugin? I'd like to try > some metas that test for an XML or XHTML declaration plus some threshold of > errors (particularly mismatches in delimiters) to see how the degree of > badness (coupled with the implied promise of goodness) correlates with spam. XML parsing is slow. You probably gain little accuracy with a lot of performance hit. Have you already tested on the sheer use of XHTML? Maybe there's no spammer using it, so you could use it for whitelist scoring, at least for a while? Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: Public whitelists
Benny Pedersen wrote on Wed, 22 Oct 2008 04:19:23 +0200 (CEST): > 1: html mails is spam It's not spam. If you don't like HTML mail (like me), contact the sender off-list and ask him politely to stop that. > 2: cc is spam olso What problem do you have? That cc did not go to you. If you get a cc'ed mail, see no. 1. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
RE: exim spamassassin AFTER SMTP
Hi Put in an ACL for local machines so that you don't run SA for these people. Either that or if users are remote (ie you're an ISP) do authententication then use that for the ACL check. -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 > -Original Message- > From: TN [mailto:[EMAIL PROTECTED] > Sent: 22 October 2008 08:01 > To: users@spamassassin.apache.org > Subject: exim spamassassin AFTER SMTP > > Hi all, > > It seems that almost everyone wants spamassasin before SMTP, > but I need help in setting it up after delivery. > > At the moment, I am using Exim4.6x, with SA 3.1.7, and it's > default setup is to do the filtering at the ACL stage in > Exim. We find this a bit tedious since users sending email > have to endure quite a delay when sending, while SA does its > work.we would much prefer it to accept the delivery, so > that the user isn't waiting for their email client to finish > up. We don't reject spam anyway, we're just happy to rewrite > the subject, mark the email as spam and then let the email > client rules sort the ham from spam based on those 2 marks - > obviously we don't have a heavily laden email link so we can > afford to accept spam and filter it after SMTP. > > Alternatively, can it be configured to not do ANY filtering > on authenticated senders, but process every other incoming > email at ACL stage ? This would probably be best. > > How can I do either of these with Exim & SA ? > > > thanks > T > > > Make the switch to the world's best email. Get > Yahoo!7 Mail! http://au.yahoo.com/y7mail > ** Confidentiality : This e-mail and any attachments are intended for the addressee only and may be confidential. If they come to you in error you must take no action based on them, nor must you copy or show them to anyone. Please advise the sender by replying to this e-mail immediately and then delete the original from your computer. Opinion : Any opinions expressed in this e-mail are entirely those of the author and unless specifically stated to the contrary, are not necessarily those of the author's employer. Security Warning : Internet e-mail is not necessarily a secure communications medium and can be subject to data corruption. We advise that you consider this fact when e-mailing us. Viruses : We have taken steps to ensure that this e-mail and any attachments are free from known viruses but in keeping with good computing practice, you should ensure that they are virus free. Red Lion 49 Ltd T/A Solid State Logic Registered as a limited company in England and Wales (Company No:5362730) Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, United Kingdom **
Re: exim spamassassin AFTER SMTP
>On śro, 2008-10-22 at 00:01 -0700, TN wrote: >> It seems that almost everyone wants spamassasin before SMTP, > >Nh. > >> so we can afford to accept spam and filter it after SMTP. > >What are you using for local delivery? The most common solution, I think >is to use procmail and just include a rule that filters the mail thru SA >just before local delivery. I'm using cyrus2.2 for local delivery into virtual domains (using sasl/ldap for authentication/db). I thought that I'd probably need to create a router/transport maybe. Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail
Re: I get a lot of these spams, obviously by one software program
Igor Chudov a écrit : > example is here > > http://igor.chudov.com/tmp/spam004.txt > Content analysis details: (8.2 points, 5.0 required) pts rule name description -- -- 2.1 RCVD_IN_NJABL_SPAM RBL: NJABL: sender is confirmed spam source [216.117.203.6 listed in combined.njabl.org] 2.0 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: awardsforum.com] 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.] 0.1 DIET_1 BODY: Lose Weight Spam 0.0 COUNTRY_US Relayed via US 0.6 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) The sample triggers URIBL_BLACK, but I guess the URI was listed after you got the spam. if you get many of these, pass them to sa-learn (so that you get BAYES_99 instead of BAYES_50). > I get a lot of these, always for different companies, but obviously > emailed by one spammer. > > I am on Ubuntu 8.04 using their stock spamassassin. > SA 3.2.4? > Are there some rulesets that I am missing? > unrelated to your sample, but do use sa-update to update the rules. also add some channels, in particular sought.rules.yerp.org (JM_SOUGHT).
Re: exim spamassassin AFTER SMTP
On śro, 2008-10-22 at 00:01 -0700, TN wrote: > It seems that almost everyone wants spamassasin before SMTP, Nh. > so we can afford to accept spam and filter it after SMTP. What are you using for local delivery? The most common solution, I think is to use procmail and just include a rule that filters the mail thru SA just before local delivery. -- d'`'`'`'`'`'`'`'`'`'`'`'`'Yb BorgDOS 6.0: Now with real-time assimilation `b [EMAIL PROTECTED] d' on the fly. d' http://epsilon.eu.org/ Yb `b,-,.,-,.,-,.,-,.,-,.,-,.d'
bogusmx [Was: DNS restrictions for a mail server]
Matt Kettler a écrit : > Stefan Jakobs wrote: >> On Tuesday 21 October 2008 14:57, Matt Kettler wrote: >> >> >>> In general it is recommended to not point a MX record to a CNAME, but >>> that's just to reduce repetative querries. It is extraordinarily >>> commonplace in the real world, and AFAIK 100% RFC legal. >>> >> I don't think so. See: http://www.rfc-ignorant.org/policy-bogusmx.php >> >> "Section 10.3 of RFC 2181 points out that pointing an MX RR at a hostname >> which is actually a CNAME RR is invalid, and such hosts are also listed." >> >> >> >> Greetings >> Stefan >> > Fair enough. It is still extraordinarily common. > > It's also not actually the point of the OP's restrictions, but it was a > part of his example. > > (Also, I have to point out just because it's a RFC violation and RFCI > chooses to list it does not make it useful in spam filtering. RFCI is > interesting data, but it's also extremely FP prone nowdays) > The bogusmx and dsn sublists are still useful for score based filtering (some people even use them in smtp reject as well, although I find that "unsafe"). The current 50_scores.cf has: score DNS_FROM_RFC_BOGUSMX 0 2.125 0 1.482 # n=0 n=2 score DNS_FROM_RFC_DSN 0 2.527 0 1.495 # n=0 n=2 It would be intersting to divide the bogusmx list according to the type of error and see which errors are indicative of spam. I'll bet that the CNAME error is neutral, but I have no evidence. but errors like the following ones either mean spam or unreachable sender (and if you can't reach the sender, it is probable that you want him to get an error to fix his config): $ host -t mx 06688.com 06688.com mail is handled by 0 dev.null. $ host -t mx 0h.cn 0h.cn mail is handled by 10 mail.0h.cn.$ host mail.0h.cn. Host mail.0h.cn. not found: 3(NXDOMAIN) $ host -t mx socks.xmission.com socks.xmission.com mail is handled by 10 127.0.0.1 $ host -t mx 3banatomy.co.kr 3banatomy.co.kr has no MX record
exim spamassassin AFTER SMTP
Hi all, It seems that almost everyone wants spamassasin before SMTP, but I need help in setting it up after delivery. At the moment, I am using Exim4.6x, with SA 3.1.7, and it's default setup is to do the filtering at the ACL stage in Exim. We find this a bit tedious since users sending email have to endure quite a delay when sending, while SA does its work.we would much prefer it to accept the delivery, so that the user isn't waiting for their email client to finish up. We don't reject spam anyway, we're just happy to rewrite the subject, mark the email as spam and then let the email client rules sort the ham from spam based on those 2 marks - obviously we don't have a heavily laden email link so we can afford to accept spam and filter it after SMTP. Alternatively, can it be configured to not do ANY filtering on authenticated senders, but process every other incoming email at ACL stage ? This would probably be best. How can I do either of these with Exim & SA ? thanks T Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail
