Re: Suggestion for use by ANY whitelist service....
LuKreme wrote: On 5-Dec-2009, at 13:58, Per Jessen wrote: No legislation is any good without enforcement. Provided you have both and the enforcement is heavy handed, spam is not a problem. Show where spam is not a problem? Spammers are immune to the law because they are largely untrackable. I didn't say nor meant to imply that a single countrys legislation would be sufficient. When there are many countries that send virtually no spam, it's because they have legislation, enforcement and a suitable infrastructure to prevent it. Implement the same legislation+ enforcement+infrastructure everywhere else and spam is gone. Of course there are millions of reasons why it will never happen, for instance countries who explicitly allow spamming. /Per Jessen, Zürich
RE: Suggestion for use by ANY whitelist service....
On Sat, 2009-12-05 at 22:12 -0800, R-Elists wrote: frankly, nothing against them, yet if an organization really needs Return Path to get their email through to mailboxes without rejection, then doesn't the originator of the email have problems? Of course they do! That's why ESP's exist - because bulk mailers get blocked and they turn to those that court the anti-spam markets. To get a handle on it, you only have to bad mouth any of them here, on a spam list or NANAE and watch them pop up in defence to smooth it all over. A truly clean company that always uses opt-in and never spams has nothing to fear from any anti-spam measure.
HABEAS numbers
Just for fun, I took a look at my logs for August, September, October and November and looked at the hits on HABEAS_ACCREDITED_COI: Total hits = 1009. Of those, 45 would have been filtered out without HABEAS_ACCREDITED_COI. 5 were most probably backscatter and got filtered out despite HABEAS_ACCREDITED_COI. 3 were blacklisted (by users). 565 had hits on HABEAS_ACCREDITED_COI and RCVD_IN_SSC_TRUSTED_COI. 271 had hits on HABEAS_ACCREDITED_COI and RCVD_IN_IADB_LISTED. 705 were greylisted (which means that the sending client matched certain criteria). 605 did not have a messageid. /Per Jessen, Zürich
Re: freemail vs dkim / spf
Benny Pedersen wrote: i think it could be added to freemail.pm to test if sender domain have spf or dkim and if no spf and or no dkim consider it as a freemail domain ? i dont know if it require code changes to do this, but it make sense for me atleast to make it, no ? objection, flames as i like to know how other thinks about it nothing in the RFC's requires the use of SPF or DKIM. (even if RFC's require RDNS, valid hostnames, valid matching helo, you will lose legit email if you bounce email that violates rfc's) RFC's require a working postmaster and abuse address (see www.rfc-ignorant.org), but you will bounce legit email if you use that. My point is two fold: #1, SPF and DKIM are not RFC required, and the lack of (or use of) these doesn't indicate freemail or not. #2, even if it WAS required by RFC's, not all legit mail servers will use it (they can't even get their RDNS right) oh, and that means we should mark all email from this mailing lists as freemail, because: #1, it doesn't use SPF records #2, it doesn't use DKIM signing (yes, maybe YOU signed your email with DKIM, but apache added stuff to the bottom of the email and broke the sig), AND, they don't use SPF) -- 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 _
Re: freemail vs dkim / spf
On Dec 6, 2009, at 12:02 AM, Benny Pedersen m...@junc.org wrote: i think it could be added to freemail.pm to test if sender domain have spf or dkim and if no spf and or no dkim consider it as a freemail domain ? Sorry, but SPF and DKIM simply don't have the saturation required for that. You could consider freemail without SPF or DKIM to be unverified freemail and give them an extra point or so, but beyond that I wouldn't see it as a useful spam sign. -- Dan McDonald
Re: freemail vs dkim / spf
On Sun, Dec 06, 2009 at 07:14:31AM -0600, McDonald, Dan wrote: On Dec 6, 2009, at 12:02 AM, Benny Pedersen m...@junc.org wrote: i think it could be added to freemail.pm to test if sender domain have spf or dkim and if no spf and or no dkim consider it as a freemail domain ? Sorry, but SPF and DKIM simply don't have the saturation required for that. You could consider freemail without SPF or DKIM to be unverified freemail and give them an extra point or so, but beyond that I wouldn't see it as a useful spam sign. And all this can be done with meta rules if you want to, no need to touch freemail code. I'll leave it as the OPs exercise..
Re: HABEAS numbers
On 06.12.09 10:53, Per Jessen wrote: Just for fun, I took a look at my logs for August, September, October and November and looked at the hits on HABEAS_ACCREDITED_COI: Total hits = 1009. Of those, 45 would have been filtered out without HABEAS_ACCREDITED_COI. 5 were most probably backscatter and got filtered out despite HABEAS_ACCREDITED_COI. 3 were blacklisted (by users). 565 had hits on HABEAS_ACCREDITED_COI and RCVD_IN_SSC_TRUSTED_COI. 271 had hits on HABEAS_ACCREDITED_COI and RCVD_IN_IADB_LISTED. 705 were greylisted (which means that the sending client matched certain criteria). 605 did not have a messageid. imho this says that HABEAS_* rules should be present in some meta rules that could give us some benefits (according to proposed 2+2!=4 rule) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
rule_du_jour: AXB_CID_YARIGHT
this rule won't work for long :-)
ifplugin Mail::SpamAssassin::Plugin::MIMEHeader
mimeheader AXB_CID_YARIGHT Content-ID =~ /^\00\{DIGIT2\}/
score AXB_CID_YARIGHT 3.0
endif
score higher if you wish...
have a {ENJOY_VAR} Sunday!
HABEAS 'date the UK' accreddited spam figures
My figures for date the UK in the last 72 hours: 118 mails *all* HABEAS accredited. == CHECKING DNSBL WHITE LISTS == 80.75.69.201 NOT WHITELISTED: sa-other.bondedsender.org, resl.emailreg.org, plus.bondedsender.org, ips.whitelisted.org WHITELISTED: sa-accredit.habeas.com Thusfar 18 reports to abuse@ (despite the fact it's missing from the rdns whois) The square to that, they are all catching on: Sanesecurity.Jurlbl.33575 - so there is a God :-)
Re: HABEAS 'date the UK' accreddited spam figures
rich...@buzzhost.co.uk wrote: Thusfar 18 reports to abuse@ (despite the fact it's missing from the rdns whois) FYI, abuse@ is specified in RFC2142, and need not be explicitly listed in the whois. /Per Jessen, Zürich
Re: HABEAS 'date the UK' accreddited spam figures
On Sun, 2009-12-06 at 18:07 +0100, Per Jessen wrote: FYI, abuse@ is specified in RFC2142, and need not be explicitly listed in the whois. Thanks. I knew it was somewhere :-)
Re: freemail vs dkim / spf
Benny Pedersen wrote: i think it could be added to freemail.pm to test if sender domain have spf or dkim and if no spf and or no dkim consider it as a freemail domain ? i dont know if it require code changes to do this, but it make sense for me atleast to make it, no ? objection, flames as i like to know how other thinks about it I don't see the relationship that SPF has to freemail domains.
Re: Suggestion for use by ANY whitelist service....
On 6-Dec-2009, at 02:24, rich...@buzzhost.co.uk wrote: A truly clean company that always uses opt-in and never spams has nothing to fear from any anti-spam measure. Oh, that is CERTAINLY not true. It's not even true of just SpamAssassin, but it is completely disingenuous to claim that for ANY anti-spam measure. completely clean messages that are not spam get miss-tagged ALL THE TIME. I dig mails out of my spam folder that I want at least on a weekly basis. Just this week I had someone I know quite well send me an evite invitation to a meeting next week. It was tagged with Bayes_99, probably due to all the fake 'marketing seminar' invitations that go out. Ironically enough, this one would have still squeaked under the wire had I not tagged it +2.0 for HABEAS_ACCREDITED_SOI, but that's another thread :) Another was an email from a friend of mine that for some odd reason tripped bayes_99 and a relay check and a couple of others. So there's two this week. OTOH, there's 410 more spam messages in that folder from this week that all appear to be correctly tagged. -- The way I see it, the longer I put it off, the better it'll end up being. Heck, school doesn't start for another 43 minutes.
Re: Suggestion for use by ANY whitelist service....
On Sun, 2009-12-06 at 12:02 -0700, LuKreme wrote: On 6-Dec-2009, at 02:24, rich...@buzzhost.co.uk wrote: A truly clean company that always uses opt-in and never spams has nothing to fear from any anti-spam measure. Oh, that is CERTAINLY not true. It's not even true of just SpamAssassin, but it is completely disingenuous to claim that for ANY anti-spam measure. completely clean messages that are not spam get miss-tagged ALL THE TIME. I dig mails out of my spam folder that I want at least on a weekly basis. Just this week I had someone I know quite well send me an evite invitation to a meeting next week. It was tagged with Bayes_99, probably due to all the fake 'marketing seminar' invitations that go out. Ironically enough, this one would have still squeaked under the wire had I not tagged it +2.0 for HABEAS_ACCREDITED_SOI, but that's another thread :) Another was an email from a friend of mine that for some odd reason tripped bayes_99 and a relay check and a couple of others. So there's two this week. OTOH, there's 410 more spam messages in that folder from this week that all appear to be correctly tagged. That would point more to the quality of the Bayesian db's IMHO, but it was careless to say 'any'. The point to get across is reputable businesses should not need the services of an ESP who attempts to subvert anti-spam systems. Optimising email for delivery is quite one thing, getting into bed with anti-spam vendors and coders to serious weight the deck in the favour of the bulker is not acceptable. ESP's are to be distrusted. They are mostly the devils advocate and I don't think that is unfair. When you have people like eBay spending money with you, you are not going to say 'sorry, we are dropping you because you occasionally spam millions of your users'. Feedback reminders spring to mind. A link tells you that you can update the preference to stop them, but follow the link and the option is nowhere to be found - but you get to see the latest adds going there.
Language detection in TextCat
I'm wondering if the language detection in TextCat can be improved. Here's the situation. It appears that TextCat was designed to be inclusive. You list the languages you want and it returns many possibilities so as not to trigger unwanted falsely. What I'm doing is extracting the language list for Exim where I hope to offer a language reject list. The problem is that when you are rejecting languages you want a smaller list that when you are including languages to avoid false positives. I'd rather have a single (non-english) result. I'm wondering if there's a way to add some more options to alter the behavior of the plugin so it is more optimized towards the idea of rejecting languages?
Re: freemail vs dkim / spf
On Dec 6, 2009, at 12:56 PM, Marc Perkel m...@perkel.com wrote: Benny Pedersen wrote: i think it could be added to freemail.pm to test if sender domain have spf or dkim and if no spf and or no dkim consider it as a freemail domain ? I don't see the relationship that SPF has to freemail domains. Most freemail domains support either SPF or DKIM. But I can't form a syllogism that helps much, other than: * spam often spoofs freemail addresses * ham freemail usually matches SPF or is DKIM signed * therefore, unsigned/unmatched freemail is likely spam. But I think my daughter's logic teacher would be unconvinced... -- Dan McDonald
ANNOUNCE: Apache SpamAssassin 3.3.0-beta1 available
Apache SpamAssassin 3.3.0-beta1 is now available for testing. Downloads are available from: http://people.apache.org/~wtogami/devel/ md5sum of archive files: 9b39e4e4fad09cfe9eff974f3d5a01ea Mail-SpamAssassin-3.3.0-beta1.tar.bz2 530fb1bd28977271f30b348bc2b68db1 Mail-SpamAssassin-3.3.0-beta1.tar.gz 637f6495b28e9ab9580206ee344a2074 Mail-SpamAssassin-3.3.0-beta1.zip cbd092c4e0e71b531f7aca81d4eb2781 Mail-SpamAssassin-rules-3.3.0-beta1.r886683.tgz sha1sum of archive files: b6aa2f21610e1de87bf21b629b98df9bddfa0988 Mail-SpamAssassin-3.3.0-beta1.tar.bz2 6750417097ce289a5b295c75bfc20a877bea87e6 Mail-SpamAssassin-3.3.0-beta1.tar.gz 95a54095f6e201a1b582f3715c81c9485aab5325 Mail-SpamAssassin-3.3.0-beta1.zip 3e2b23828dd3a7575ced80b2d6571995aebd7299 Mail-SpamAssassin-rules-3.3.0-beta1.r886683.tgz Note that the *-rules-*.tgz files are only necessary if you cannot, or do not wish to, run sa-update after install to download the latest fresh rules. The release files also have a .asc accompanying them. The file serves as an external GPG signature for the given release file. The signing key is available via the wwwkeys.pgp.net key server, as well as http://www.apache.org/dist/spamassassin/KEYS The key information is: pub 4096R/F7D39814 2009-12-02 Key fingerprint = D809 9BC7 9E17 D7E4 9BC2 1E31 FDE5 2F40 F7D3 9814 uid SpamAssassin Project Management Committee priv...@spamassassin.apache.org uid SpamAssassin Signing Key (Code Signing Key, replacement for 1024D/265FA05B) d...@spamassassin.apache.org sub 4096R/7B3265A5 2009-12-02 See the INSTALL and UPGRADE files in the distribution for important installation notes. Summary of major changes since 3.2.5 COMPATIBILITY WITH 3.2.5 - rules are no longer distributed with the package, but installed by sa-update - either automatically fetched from the network (preferably), or from a tar archive, which is available for downloading separately - CPAN module requirements: - minimum required version of ExtUtils::MakeMaker is 6.17 - modules now required: Time::HiRes, NetAddr::IP, Archive::Tar - minimal version of Mail::DKIM is 0.31 (preferred: 0.37 or later); expect some tests in t/dkim2.t to fail with versions older than 0.36_5; - no longer used: Mail::DomainKeys, Mail::SPF::Query - 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 - if keeping AWL database in SQL, the field awl.ip must be extended to 40 characters. The change is necessary to allow AWL to keep track of IPv6 addresses which may appear in a mail header even on non-IPv6 -enabled host. While at it, consider also adding a field 'signedby' to the SQL table 'awl' (and adding 'auto_whitelist_distinguish_signed 1' to local.cf); See sql/README.awl for details. The change need not be undone even if downgrading back to 3.2.* for some reason; - fixing a protocol implementation error regarding a PING command required bumping up the SPAMC protocol version to 1.5. Spamd retains compatibility with older spamc clients. Combining new spamc clients with pre-3.3 versions of a spamd daemon is not supported (but happens to work, except for the PING and SKIP commands). - it may be worth mentioning that a rule DKIM_VERIFIED has been renamed to DKIM_VALID, to match its semantics; - support for versions of perl 5.6.* is being gradually revoked (may still work, but no promises and no support) - preferred versions of perl are 5.8.8, 5.8.9, and 5.10.1 or later MAIN NEW FEATURES - IPv6 support was substantially improved (see below); - many improvements to the DKIM plugin (understands author domain signatures, supports multiple signatures, ADSP support with overrides) - (see below); - added 'if can(Class::method)' conditional statement, allowing configuration settings to be conditionalised on plugin capabilities without requiring new version releases to do so; - added a configuration option 'time_limit', defaulting to 300 seconds or whatever the caller (like spamd) provides; attempting to gracefully terminate the checking when a time limit is reached, reporting the score and test hits that were collected so far, along with an added hit on a rule TIME_LIMIT_EXCEEDED; - more expensive code sections are now instrumented with timing measurements; timing report is logged as a debug message by the end of processing, and made available to a caller and to 'add_header' directives through a TIMING tag; - added a configuration option skip_uribl_checks to the URIDNSBL plugin, cross-document it with skip_rbl_checks; - preserve order of declared 'add_header' header fields; - configurable network mask length for the AWL plugin (see below); - added support for DCC
Re: Language detection in TextCat
Marc Perkel wrote: I'm wondering if the language detection in TextCat can be improved. Here's the situation. It appears that TextCat was designed to be inclusive. You list the languages you want and it returns many possibilities so as not to trigger unwanted falsely. What I'm doing is extracting the language list for Exim where I hope to offer a language reject list. The problem is that when you are rejecting languages you want a smaller list that when you are including languages to avoid false positives. I'd rather have a single (non-english) result. I'm wondering if there's a way to add some more options to alter the behavior of the plugin so it is more optimized towards the idea of rejecting languages? The language detection would have to be radically redesigned to have enough accuracy support this. Currently TextCat is a *very* crude match, and will often will return multiple languages for plain English text. Textcat is not designed to decide what language the email is, but to find a set of languages it *might* be. It is very prone to declaring extra languages that are not really present due to it's design. This is useful in the if it can't be my language, then it's garbage sense, but not so useful in a reject if it could be this language I don't like. You'd really want reject if it *IS* this language I don't like, but textcat doesn't tell you what language an email is, only a set of what it might be.
Re: Language detection in TextCat
On Sun, Dec 06, 2009 at 11:49:25PM -0500, Matt Kettler wrote: Marc Perkel wrote: I'm wondering if the language detection in TextCat can be improved. Here's the situation. It appears that TextCat was designed to be inclusive. You list the languages you want and it returns many possibilities so as not to trigger unwanted falsely. What I'm doing is extracting the language list for Exim where I hope to offer a language reject list. The problem is that when you are rejecting languages you want a smaller list that when you are including languages to avoid false positives. I'd rather have a single (non-english) result. I'm wondering if there's a way to add some more options to alter the behavior of the plugin so it is more optimized towards the idea of rejecting languages? The language detection would have to be radically redesigned to have enough accuracy support this. Currently TextCat is a *very* crude match, and will often will return multiple languages for plain English text. Textcat is not designed to decide what language the email is, but to find a set of languages it *might* be. It is very prone to declaring extra languages that are not really present due to it's design. This is useful in the if it can't be my language, then it's garbage sense, but not so useful in a reject if it could be this language I don't like. You'd really want reject if it *IS* this language I don't like, but textcat doesn't tell you what language an email is, only a set of what it might be. Also beware of the case bug: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6229 I've got ok results with my corpus with textcat_acceptable_score ~1.02 and textcat_max_languages ~1-2. Of course I wouldn't plain reject anything..
Re: Language detection in TextCat
On 06.12.09 11:39, Marc Perkel wrote: I'm wondering if the language detection in TextCat can be improved. Here's the situation. It appears that TextCat was designed to be inclusive. You list the languages you want and it returns many possibilities so as not to trigger unwanted falsely. What I'm doing is extracting the language list for Exim where I hope to offer a language reject list. The problem is that when you are rejecting languages you want a smaller list that when you are including languages to avoid false positives. I'd rather have a single (non-english) result. I'm wondering if there's a way to add some more options to alter the behavior of the plugin so it is more optimized towards the idea of rejecting languages? What's the point? Why do you think that would an improvement? I think that most of people speak a few languages while there are dozens of languages they do not speak. Why do you think people would want all but a few languages? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe.
