Re: Spamhaus DBL
ram r...@netcore.co.in wrote in message news:1267506187.16095.11.ca...@darkstar.netcore.co.in... http://www.spamhaus.org/dbl/ I think sa-folks would have this already in some URIBL rule. What are the scores you assign for a dbl positive hit ? I assume my current datafeed would already extend to data access on the dbl list. I will have to setup my rbldnsd before trying this out. The new Spamhaus DBL may not be used with current versions of SpamAssassin. A new version of SpamAssassin will be released soon which adds support for the DBL. Check out the DBL FAQ at http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL which explains why - as quoted below: ** SpamAssassin 3.3.1 Upgrade *Required* SpamAssassin 3.3.1 is due to be released shortly and should coincide with the release of the DBL. SA 3.3.1 has new code for dealing specifically with domain-only URI BLs such as the DBL. To use the DBL you must upgrade to 3.3.1. SpamAssassin versions prior to 3.3.1 query URI blocklists for URIs of both type domain http://abc.domain.tld; and IP http://1.1.1.1;, however DBL does not support IP queries; in fact it prohibits them. DBL should not be used in versions of SpamAssassin prior to 3.3.1 because older versions of SpamAssassin make both IP and text queries to URI blocklists. The DBL supports only domain (text strings not dotted quads) queries. Do not 'hack' versions of SpamAssassin prior to 3.3.1 to add DBL support, for example by reusing a SURBL or URIBL configuration for DBL. You risk wrongly flagging legitimate email if you make IP queries to the DBL. ** Also check out the announcement at http://www.spamhaus.org/news.lasso?article=655 which goes into further detail on this new list. Cheers, Jeremy
Re: Spamhaus DBL
On Tuesday, March 2, 2010, 1:16:17 AM, Jeremy Fairbrass wrote: ram r...@netcore.co.in wrote in message news:1267506187.16095.11.ca...@darkstar.netcore.co.in... http://www.spamhaus.org/dbl/ I think sa-folks would have this already in some URIBL rule. What are the scores you assign for a dbl positive hit ? I assume my current datafeed would already extend to data access on the dbl list. I will have to setup my rbldnsd before trying this out. The new Spamhaus DBL may not be used with current versions of SpamAssassin. A new version of SpamAssassin will be released soon which adds support for the DBL. Check out the DBL FAQ at http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL which explains why - as quoted below: ** SpamAssassin 3.3.1 Upgrade *Required* SpamAssassin 3.3.1 is due to be released shortly and should coincide with the release of the DBL. SA 3.3.1 has new code for dealing specifically with domain-only URI BLs such as the DBL. To use the DBL you must upgrade to 3.3.1. SpamAssassin versions prior to 3.3.1 query URI blocklists for URIs of both type domain http://abc.domain.tld; and IP http://1.1.1.1;, however DBL does not support IP queries; in fact it prohibits them. DBL should not be used in versions of SpamAssassin prior to 3.3.1 because older versions of SpamAssassin make both IP and text queries to URI blocklists. The DBL supports only domain (text strings not dotted quads) queries. Do not 'hack' versions of SpamAssassin prior to 3.3.1 to add DBL support, for example by reusing a SURBL or URIBL configuration for DBL. You risk wrongly flagging legitimate email if you make IP queries to the DBL. ** Also check out the announcement at http://www.spamhaus.org/news.lasso?article=655 which goes into further detail on this new list. Please also see this bugzilla: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6335 Cheers, Jeff C. -- Jeff Chan mailto:je...@surbl.org http://www.surbl.org/
Re: can I roll back to an earlier version of updates
You'll love this..
My nightly sa-update cron ran last night and upgraded my modified
rules (was version 916621) to a newer version (version 917420). This, of
course, undid my changes. And equally surprising, --lint passed.
I looked at the diffs and sure enough, the same lines were back (number
of other changes too). Not sure why the gremlins were banished.
Interesting mystery.
-lee
Lee Dilkie wrote:
Final update folks, sorry for the noise if it's bothersome...
commented out the three offending lines in 72_active.cf and --lint
passed and I'm back up and running.
No idea what the issue is, those lines looked fine to me. I'm running
perl 5.8.9, could that be an issue?
-lee
details: ##lee is my handiwork
ifplugin Mail::SpamAssassin::Plugin::MIMEHeader
mimeheader __TVD_FW_GRAPHIC_ID1 Content-Id =~
/[0-9a-f]{12}(?:\$[0-9a-f]{8}){2}\@/
endif
ifplugin Mail::SpamAssassin::Plugin::MIMEEval
##lee mimeheader __TVD_MIME_ATT_AOPDF Content-Type =~
/^application\/octet-stream.*\.pdf/i
endif
ifplugin Mail::SpamAssassin::Plugin::MIMEEval
##lee mimeheader __TVD_MIME_ATT_APContent-Type =~ /^application\/pdf/i
endif
ifplugin Mail::SpamAssassin::Plugin::MIMEEval
##lee mimeheader __TVD_MIME_ATT_TPContent-Type =~ /^text\/plain/i
endif
ifplugin Mail::SpamAssassin::Plugin::MIMEHeader
mimeheader __TVD_OUTLOOK_IMG Content-Id =~ /image\d+\.(?:gif|jpe?g|png)\@/
endif
Lee Dilkie wrote:
progress report.. commented out the place where the lint results were
checked and rules got installed.
looking at 72_active.cf I see a number of lines ending in CR (^M). Is
this intentional?
ie.
header __SUBJ_3DIGIT Subject =~ /\b\d{3}[^0-9]/^M
header __SUBJ_APPROVE Subject =~ /Approve/i^M
header __SUBJ_RE Subject =~ /^R[eE]:/^M
-lee
Lee Dilkie wrote:
no joy.
doesn't look like the ports version of SA comes with any stock rules
(nothing obvious in the ports dir tree, the work/ directory had en empty
72_active.cf file)... I deinstalled and then installed and it all went
well but it tells me to run sa-update to get the rules, and that's my
problem
You may wish to run sa-update now to obtain the latest rules.
NOTE: FREEBSD users: If you are updating from a version prior to 3.20.
sa-update now places state files in /var/db/spamassassin and not
/var/lib/spamassassin. This is to be consistant with Freebsd file
directory conventions.
If you run sa-compile, you will notice that files are in
/var/db/spamassassin/compiled/perlversion/version instead of
/var/db/spamassassin/compiled/version.
No attempts have been made to move old versions over. You must recompile.
=== Installing rc.d startup script(s)
=== Compressing manual pages for p5-Mail-SpamAssassin-3.3.0_3
=== Running ldconfig
/sbin/ldconfig -m /usr/local/lib
=== Registering installation for p5-Mail-SpamAssassin-3.3.0_3
r...@spock: /usr/ports/mail/p5-Mail-SpamAssassin
$ sa-update
config: failed to parse line, skipping, in
/tmp/.spamassassin92852PBQ5Yktmp/72_active.cf: mimeheader
__TVD_MIME_ATT_AOPDF Content-Type =~ /^application\/octet-stream.*\.pdf/i
config: failed to parse line, skipping, in
/tmp/.spamassassin92852PBQ5Yktmp/72_active.cf: mimeheader
__TVD_MIME_ATT_AP Content-Type =~ /^application\/pdf/i
config: failed to parse line, skipping, in
/tmp/.spamassassin92852PBQ5Yktmp/72_active.cf: mimeheader
__TVD_MIME_ATT_TP Content-Type =~ /^text\/plain/i
channel: lint check of update failed, channel failed
So is there *any* way for me to get this ruleset and put it on my server
and edit out the offending lines in 72_active.cf?? Is there an archive I
can download? (I'm thinking of modifying sa-update to comment-out where
it removes the tmp files)
-lee
Karsten Bräckelmann wrote:
On Mon, 2010-03-01 at 06:45 -0500, Lee Dilkie wrote:
Karsten Bräckelmann wrote:
Anyway, what comes to mind: Did you run sa-update after the upgrade to
3.3.0 at all? If not, did you install the rules tarball alongside SA?
I was originally running the 3.3 rules and that was fine, and as far as
I know, I did even run sa-upgrade (can't tell you if it upgraded the
rules over the base ones) but it's the latest sa-update that pulled in
newer rules that didn't link. And it's my monkeying around, deleting
rules directories, that has left me without rules from updates
spamassassin_org. And boy! do they block a lot of spam or what! ;)
How did you upgrade? Any chance both versions ended up living on your
system?
Running 3.3.0 with a broken sa-update for whatever reason, can be cured
by removing the entire update dir, and installing the plain, stock 3.3.0
rules tarball, if not already done.
I'm on freebsd, I'm
Now with trusted_networks support Re: DNSWL --report plugin
If you have spamassassin's trusted_networks value configured properly, this module will now always report the correct IP to DNSWL when you run spamassassin --report. trusted_networks needs to be right for all DNS Blacklist checks (and DNSWL) to know which IP to check. Mine currently looks like: trusted_networks 64.71.152.40 208.93.0.48 trusted_network docs: http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html#network_test_options http://wiki.apache.org/spamassassin/TrustPath The change was on the server end, so the previous version of the plugin will work. The new version of the plugin also tells you the IP that was reported: http://www.chaosreigns.com/dnswl/dl/DNSWLh.pm You can also check the IP that was reported on http://www.dnswl.org/abuse/pastreports.pl ( http//www.dnswl.org / Report Abuse, Report / History ) If you have any problems, just email adm...@dnswl.org (or me, but I'm on that list). Just a repeat of the instructions: --- Download http://www.chaosreigns.com/dnswl/dl/DNSWLh.pm to /usr/share/perl5/Mail/SpamAssassin/Plugin/ (or your equivalent) In your spamassassin config, add the following three lines: loadplugin Mail::SpamAssassin::Plugin::DNSWLh dnswl_address u...@example.com dnswl_password yourpassword --- Note: This new feature, using trusted_networks, does not apply to using the web form directly, since SpamAssassin doesn't insert the header. This is what actually gets reported (I'm adding the three headers at the top): http://www.chaosreigns.com/dnswl/dnswlbody.1267458909.txt Currently, it only reads X-Spam-Relays-Untrusted if the Content-Description header is first, to avoid spammer forgeries. -- Anarchy is based on the observation that since few are fit to rule themselves, even fewer are fit to rule others. -Edward Abbey http://www.ChaosReigns.com
Spam Assassin Rejecting Comcast Validation Emails
Greetings all. I am sure that I would be better able to diagnose this problem if I was able to capture the incident email traffic, however, at this point I have not been able to retrieve the emails. The situation is that upon registration of a new username for comcast services, which is actually an email address, when the test email comes through, it is rejected with a score of 5.2/5.0 during the handshake for my citadel implementation. I currently have citadel in the standard setup where spamassassin is used to reject email prior to accepting them, if spamassassin determines that the email is spam. I was wondering if anyone else has this issue, or if I may be able to safely edit any settings within spamassassin to be more accomidating to the comcast.net email. -- Respectfully, Martes G Wigglesworth
Re: Spam Assassin Rejecting Comcast Validation Emails
On Tue, 2010-03-02 at 11:58 -0500, MGW-Discussions wrote:
I am sure that I would be better able to diagnose this problem if I was
able to capture the incident email traffic, however, at this point I
have not been able to retrieve the emails.
Check your logs for the rules the email triggered.
The situation is that upon registration of a new username for comcast
services, which is actually an email address, when the test email comes
through, it is rejected with a score of 5.2/5.0 during the handshake for
my citadel implementation. I currently have citadel in the standard
setup where spamassassin is used to reject email prior to accepting
them, if spamassassin determines that the email is spam.
This sounds slightly better than the Subject, which is just wrong. SA
does not reject anything. :)
I was wondering if anyone else has this issue, or if I may be able to
safely edit any settings within spamassassin to be more accomidating to
the comcast.net email.
Probably hard without a sample. You could either lower some rule's score
(see logs) or raise the required_score value -- temporarily at least, to
let that one mail through.
Rejecting at the required_score is quite risky in general. Common
approach for rejecting based on SA score is to use a second, higher
threshold. And keep marked spam lower than that for review.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Putting your dead domains to use
On Mon, 1 Mar 2010, Marc Perkel wrote: For what it's worth - if any of you have domains you don't use you can point them to my virus harvesting server for spam harvesting. Hmm ... how dead is dead ? :-) We had for some time three domains (our institute was moved from one national organization to another, so we had the old domain under the old organization, and the new official domain and an alias to it under the new one). All of them shared the same couple of MX. After several months, when we were sure that (almost) all our legitimate correspondants were using the new domains, and only spam was getting through the old domain, we had it removed it altogether from the DNS (no SOA record and no other DNS record of any sort). However for a long time we have been receiving on our MX's spam addressed to the really dead domain (of course this was interpreted as a non-existing domain and caused the appropriate sendmail error). Like the spammers had stored the MX somewhere. -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) Citizens entrusted of public functions have the duty to accomplish them with discipline and honour [Art. 54 Constitution of the Italian Republic] For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
Re: Spam Assassin Rejecting Comcast Validation Emails
On Tue, Mar 2, 2010 at 8:58 AM, MGW-Discussions mailinglistmem...@mgwigglesworth.net wrote: Greetings all. I am sure that I would be better able to diagnose this problem if I was able to capture the incident email traffic, however, at this point I have not been able to retrieve the emails. The situation is that upon registration of a new username for comcast services, which is actually an email address, when the test email comes through, it is rejected with a score of 5.2/5.0 during the handshake for my citadel implementation. I currently have citadel in the standard setup where spamassassin is used to reject email prior to accepting them, if spamassassin determines that the email is spam. I was wondering if anyone else has this issue, or if I may be able to safely edit any settings within spamassassin to be more accomidating to the comcast.net email. -- Respectfully, Martes G Wigglesworth I personally tag at 5.0 but reject at 15.0. I'm in the process of closing the gap, but rejecting at 5.0 (depending on your personal rule set) may be a little aggressive. I know for my mail flow that there would be a lot of false positives, much like your current issue. Do the emails always come from the same from envelope? You could whitelist the from address as an easy way around this specific problem. Certainly spammers could abuse this, but hopefully it would be a temporary solution anyways. Dave
Re: Putting your dead domains to use
Quoting Lucio Chiappetti lu...@lambrate.inaf.it: On Mon, 1 Mar 2010, Marc Perkel wrote: For what it's worth - if any of you have domains you don't use you can point them to my virus harvesting server for spam harvesting. Hmm ... how dead is dead ? :-) We had for some time three domains (our institute was moved from one national organization to another, so we had the old domain under the old organization, and the new official domain and an alias to it under the new one). All of them shared the same couple of MX. After several months, when we were sure that (almost) all our legitimate correspondants were using the new domains, and only spam was getting through the old domain, we had it removed it altogether from the DNS (no SOA record and no other DNS record of any sort). However for a long time we have been receiving on our MX's spam addressed to the really dead domain (of course this was interpreted as a non-existing domain and caused the appropriate sendmail error). Like the spammers had stored the MX somewhere. dead is dead. nowhere to go.
Re: [sa] Putting your dead domains to use
On Mon, 1 Mar 2010, Marc Perkel wrote: For what it's worth - if any of you have domains you don't use you can point them to my virus harvesting server for spam harvesting. (SNIP) The sender has to do several other things in order to be blacklisted. Simple question: Does your 'harvester' have the smarts to detect (possible) correspondence from domain *registrars* (or ARIN) to the owners of a domain name? I can't guarantee that someone somewhere doesn't have our old domain as a 'contact' even though the MX has been a non-existent server for the last several years. Subject to this important consideration for the one possible form of 'legitimate' mail, I have a domain that used to be excessively spammed, which would be *perfect* to feed to your harvester... (unless the domain is in fact so old that it has dropped from spammers lists). - Charles
Re: Spamhaus DBL
I've been running it since 1:51 Eastern (US) time, yesterday. You risk wrongly flagging legitimate email if you make IP queries to the DBL. For now, I'm :) cheating, by mapping one of the (officially) unused high bits to a negative score, which should wipe out the positive score for a raw IP URL lookup. Those are rare, plus I've long killed them on sight (unless skip listed), so that seemed like a reasonable SHORT term approach (I respect Spamhaus' logic in implementing things the way they did - they're honoring the laws of ;) natural selection). As soon as I get a chance, I'll add a raw IP exclusion option to my filter. So far, it looks good. It's hitting on about 11% of my spam (I'm ONLY running it on stuff that has NOT hit on Surbl/Uribl). It's been averaging about 130 msec to resolve (only a hundred lookups). I'll be deploying that to my users, starting this afternoon. First up will be a brickmortar business, with far more ham diversity than my Geek domain. I'll report back later in the week. The BIG issue is that apparently this had been planned for a while (I somehow missed that - SpamNation had an excellent article, yesterday, which twigged me to it). The spammers appear to have been ready, because I'm getting big volume spikes, and a MAJOR shift in payload types, with big jumps in subsite and shortener spam. Ugh! Also of interest is a steady increase in the number of RU TLD domains (59% today, average of 49% last month), with some containing garbage/low-ascii characters at the end of the URL. I've been scoring RU at 95% of kill for a while, so those aren't an issue (for me). Technically, those have been ramping up for a while. - Chip
Re: Finding URLs in html attachments
On Sun, 28 Feb 2010, LuKreme wrote: SPF! runs; ducking, shucking, and weaving You're a brave person. ;) It's easier to understand the challenge Dave faces, if we look at some actual From headers. In my stream, these started in early November of last year, so I just checked a few months of data from one domain which has had a steady trickle, AND has the richest ham diversity of all the domains I filter (translation: highest FP rate, and highest number of custom pass/skip rules (fortunately, also one of my MOST keen and helpful domain admins)). Since these started, they've had 19 of these phish: 1 Bank of Americasupp...@boa.com 1 PayPaIupd...@paypai.com 1 Paypal Inc.cust_s...@paypalsecurity.com 1 serv...@irs.govserv...@irs.gov 1 serv...@paypal.comc 1 serv...@paypal.comsecur...@act.embarqservices.net 3 serv...@paypal.comSecurity 1 U.S. Bancorpoff...@usb.com 1 Wachoviasupp...@wachovia.com 1 Wells Fargo Onlineofsreponline.al...@wellsfargo.com 1 Bank of America memberserv...@bofa.com 2 Bank of America serv...@boa.com 1 Bank of Americamemberserv...@boa.com 1 Internal Revenue Serviceservice.refun...@irss.com 1 Western Unionmemberserv...@poste.it 1 Western Unionmemberserv...@wumts.com (first column is frequency) This was from a sample size of: 106171 spams 43692 hams Note the variations on Paypal, none of which would trigger an SPF issue (some did have matching SMTP Senders). Note the clever use of RealNames to mask the actual From domain. By spam standards, these are VERY well crafted. Note that ALL hit my phish tests, as outlined last week. :) In that same sample, I found only 3 hams with base64 application/octet-stream html attachments. Given their ham diversity, that was most promising. The hams were: jcpenney.com (they're already part of our manually maintained bulk nations, with an implicit set of skip conditions) a local church (one html attachment was in amongst a ton of other stuff (mostly Word docs), all domains were already skip listed, and the sender already had a modest pass rule) Britannica Elementary Encyclopedia article (had _LOTS_ of other issues (including INVALID_DATE), and FP'd quite spectacularly!) When these phish first appeared, I did a similar ham check (further back, more domains), and found no major issues, so I ended up adding a base64 html attachment content rule. Dave, I do have one university professor research domain (and it was one of the corpora I ham checked), however it's in the social sciences, so it's probably a significantly different ham ecology from what you're seeing. I have a strong impression that you're a :) data analyzing kind of guy, and probably have decent logs. Do you see many ham base64 html attachments? That's more my curiosity, than anything. Those just feel like the sort of thing it's legitimate to penalize, though of course it depends on your FP pipeline tools, and user community. I've supported PhDs, and find quilting grannies far easier. ;) In my own post-SA filter, I've been extracting URLs from these, for years. In most cases the domains were VERY useful and did trigger on some blocklists. It's definitely the more technically correct approach. I still use the kludge content rule, mainly for belts-and-suspenders, since these ARE well crafted. Given the low rate of occurrence in ham, I didn't anticipate any significant extraction performance issues, though I do have a size constraint in place. If that's the concern, these have all been small-ish. John mentioned the reasoning for SA not extracting was: if the MUA doesn't display it automatically, why should we scan it? Which makes perfect sense as a general principle, however, in the case of these phish, social engineering is the vector for their display. Apologies if I'm missing blatant Perl or SA architecture issues, about which, I am only an egg. - Chip
Re: Putting your dead domains to use
Lucio Chiappetti wrote: On Mon, 1 Mar 2010, Marc Perkel wrote: For what it's worth - if any of you have domains you don't use you can point them to my virus harvesting server for spam harvesting. Hmm ... how dead is dead ? :-) We had for some time three domains (our institute was moved from one national organization to another, so we had the old domain under the old organization, and the new official domain and an alias to it under the new one). All of them shared the same couple of MX. After several months, when we were sure that (almost) all our legitimate correspondants were using the new domains, and only spam was getting through the old domain, we had it removed it altogether from the DNS (no SOA record and no other DNS record of any sort). However for a long time we have been receiving on our MX's spam addressed to the really dead domain (of course this was interpreted as a non-existing domain and caused the appropriate sendmail error). Like the spammers had stored the MX somewhere. Not everything that is redirected to us is blacklisted. So if some old freiend emails someone there it's not going to be blacklisted. dead is when there's no one using the domain for email.
Re: Now with trusted_networks support Re: DNSWL --report plugin
On Tue, 2010-03-02 at 10:32 -0500, dar...@chaosreigns.com wrote:
If you have spamassassin's trusted_networks value configured properly, this
module will now always report the correct IP to DNSWL when you run
spamassassin --report.
trusted_networks needs to be right for all DNS Blacklist checks (and DNSWL)
to know which IP to check.
Yes, this is crucial as I mentioned a few times on a previous thread.
The obvious ones (to the admin) are *known* forwarders, e.g. alias
addresses implemented using .forward or similar. Less obvious ones
include role accounts for mailing lists (owner-foo@). These servers
usually do not *originate* the spam...
Probably often forgotten or overlooked ones include mailing list
servers. If ML traffic is scanned.
All these might be obvious to the admin -- IFF he knows about them. But
does he know about all lists his users might be on? Good to think about
this for admins with a large-ish or anonymous user base before reporting
stuff to DNSWL.
guenther
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Finding URLs in html attachments
On Tue, 2 Mar 2010, Chip M. wrote: Since these started, they've had 19 of these phish: 1 Bank of Americasupp...@boa.com 1 PayPaIupd...@paypai.com 1 Paypal Inc.cust_s...@paypalsecurity.com 1 serv...@irs.govserv...@irs.gov 1 serv...@paypal.comc 1 serv...@paypal.comsecur...@act.embarqservices.net 3 serv...@paypal.comSecurity 1 U.S. Bancorpoff...@usb.com 1 Wachoviasupp...@wachovia.com 1 Wells Fargo Onlineofsreponline.al...@wellsfargo.com 1 Bank of America memberserv...@bofa.com 2 Bank of America serv...@boa.com 1 Bank of Americamemberserv...@boa.com 1 Internal Revenue Serviceservice.refun...@irss.com 1 Western Unionmemberserv...@poste.it 1 Western Unionmemberserv...@wumts.com In that same sample, I found only 3 hams with base64 application/octet-stream html attachments. I've had all the component rules in my sandbox for a while, but I just added one that combines the above two signs. Would you be willing to test this and see how well it does in practice? Scores are appropriate for experimental rules, rescore as you see fit, comments solicited. I don't know why the OBFU_*_ATTACH rules aren't showing up in ruleqa, I've had them in my sandbox for _months_... ifplugin Mail::SpamAssassin::Plugin::MIMEHeader mimeheader OBFU_HTML_ATTACHContent-Type =~ m,application/octet-stream;.+\.html?\b,i describe OBFU_HTML_ATTACHHTML attachment with non-text MIME type mimeheader OBFU_TEXT_ATTACHContent-Type =~ m,application/octet-stream;.+\.txt\b,i describe OBFU_TEXT_ATTACHText attachment with non-text MIME type mimeheader OBFU_DOC_ATTACH Content-Type =~ m,application/octet-stream;.+\.(?:doc|rtf)\b,i describe OBFU_DOC_ATTACH MS Document attachment with generic MIME type scoreOBFU_DOC_ATTACH 0.25 mimeheader OBFU_PDF_ATTACH Content-Type =~ m,application/octet-stream;.+\.pdf\b,i describe OBFU_PDF_ATTACH PDF attachment with generic MIME type scoreOBFU_PDF_ATTACH 0.25 meta OBFU_ATTACH_MISSP FROM_MISSPACED (OBFU_HTML_ATTACH || OBFU_TEXT_ATTACH || OBFU_DOC_ATTACH || OBFU_PDF_ATTACH) describe OBFU_ATTACH_MISSP Obfuscated attachment type and misspaced From endif -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Taking my gun away because I *might* shoot someone is like cutting my tongue out because I *might* yell Fire! in a crowded theater. -- Peter Venetoklis --- 12 days until Albert Einstein's 131st Birthday
Re: Finding URLs in html attachments
On Tue, 2 Mar 2010, John Hardin wrote:
Would you be willing to test this and see how well it does in practice?
{grumble} reply-to {grumble}
Sorry for spamming the list with this, it was meant just for Chip.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Taking my gun away because I *might* shoot someone is like cutting
my tongue out because I *might* yell Fire! in a crowded theater.
-- Peter Venetoklis
---
12 days until Albert Einstein's 131st Birthday
RE: Custom Rules Question SOLVED(ish)
The problem was multiline rules with rawbody. Changing it to full and things work. (I missed that little detail in the wiki, and there are body rules in the dist that have /is) Request A rule in-between rawbody/full? I.e. the whole body, but not the headers? Or even better, in addition to that, plain/html/etc.. scanning only the plain or html part of the body. /Request Hell, I'll try to write it if anyone can give me some pointers... e.g. * Can you add new targets (header/body/etc) from a plugin. * Where in the code do I look for the message and all its parts that is in memory. I know I'm being lazy, read the code. But hints would be greatly appreciated. michael...
Re: Spam Assassin Scoring Comcast Validation Emails as spam
Thanks for the advice guys. I will try to get a good sample, however, I will have to tweak some rulesets to even get it to stay in citadel long enough to view it. I haven't been able to play with my spamassassin install very much, other than automating the updates on rules. Thanks again, and I will post a sample when I am able to get it from the server. MGW-Discussions wrote: Greetings all. I am sure that I would be better able to diagnose this problem if I was able to capture the incident email traffic, however, at this point I have not been able to retrieve the emails. The situation is that upon registration of a new username for comcast services, which is actually an email address, when the test email comes through, it is rejected with a score of 5.2/5.0 during the handshake for my citadel implementation. I currently have citadel in the standard setup where spamassassin is used to reject email prior to accepting them, if spamassassin determines that the email is spam. I was wondering if anyone else has this issue, or if I may be able to safely edit any settings within spamassassin to be more accomidating to the comcast.net email.
Re: Spam Assassin Rejecting Comcast Validation Emails
On 02-Mar-10 09:58, MGW-Discussions wrote: when the test email comes through, it is rejected with a score of 5.2/5.0 You are REJECTING at a score of 5.0? That's a bad idea. Generally if you run SA at transaction you will tag at a score of 5.0 through maybe 10.0 or maybe even 12.0, it is only at 12.0 that you reject the spam. (this nunmber can be any number you want, but I think it would probably be pretty foolish to make it any lower than 9.0) -- 'It's always a good thing to let a few tales spread, you know. Pour encouragy le-poor encoura-to make everyone sit up and damn well take notice.' --Eric
