Re: SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On 9-Mar-2010, at 02:45, Brian wrote:
On Tue, 2010-03-09 at 02:36 -0700, LuKreme wrote:
On 08-Mar-10 23:51, Brian wrote:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind. Unless you know different?
You don't let messages even GET to SA until they pass sane checks (like
reject_non_fqdn_sender and reject_non_fqdn_recipient).
Which spam happily passes, hence the need for Spamassassin to do content
inspection - unless you are telling me Postfix can offer the same level
of content inspection as Spamassassin? (Clue: stock answer - 'Postfix
is an MTA, it does not do..)
Please read the whole thread. We were talking about a specific threat, as
detailed in the subject.
--
Send beer, words simply can't adequately express your gratitude -- James
Sedgwick
Re: SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On 9-Mar-2010, at 05:51, Brian wrote: On Tue, 2010-03-09 at 13:17 +0100, Ralf Hildebrandt wrote: * Brian brel.astersik100...@copperproductions.co.uk: In the year 2010 it is not unreasonable to expect the MTA that takes responsibility for accepting a message to make reasonable checks about the validity or content of that message. Postfix can do this either via the milter interface OR the smtpd_proxy_filter It's very easy. GROAN *** WE KNOW THAT! Look at the title and read the post Ralf. The point is you need to use a milter or proxy/policy daemon to do this with Postfix. No you don't. You can completely eliminate the ACI issue with sane checks on the SMTP transaction. No milters, plugins, or voodoo required. -- Well I've seen the Heart of Darkness/Read the writing on the wall/an the voice out in the desert/Was the voice out in the hall
Re: SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On 9-Mar-2010, at 06:50, Brian wrote: Postfix remains an MTA for the 1990's as it is, but that's just a view. If 9x% of the traffic an MTA gets to see is unwanted SPAM, it's not unreasonable to expect a solid and reliable built in mechanism to reject it. My postfix rejects more than 90% of all connections attempts at transaction stage. It does this without proxies or milters of any kind. -- I am by nature made for my own good, not my own evil
RE: [sa] Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
Now THAT is off-topic. We are discussing the use of SA at SMTP time. Please stay on-topic for this group, and for this thread. If you actually care to continue, I expect a reasonable response to my arguments about rejection being better than bouncing or silent diversion. Geez, you didn't even try to advocate a system of notices to the user to overcome the 'silent' portion of that argument. Do I have to argue both sides for you? :) - C Charles, with all due respect and in right spirit you know way too much for anyone to have an argument with you... if you cannot implement all processing and reject in DATA phase, then well... there it is... work on it... your next post says you sometimes have to reject after... and i quote you --- Charles Gregory Quote:Re: [sa] Re: SMTP REJECT after DATA The only efficiency to be gained is to reject as much as possible after the RCPT_TO, before accepting DATA. But for systems like mine, with lousy user cooperation, rejecting some of the mail after DATA is still the best option. --- i would say you are arguing both sides and that it might be the issue. i would tend to believe that most have made the choice not to straddle the fence are you blaming the users for your administration? ;-) - rh
[Fwd: Re: rules]
Sent just to Matt by mistake. Apologies Forwarded Message From: Martin Gregorie mar...@gregorie.org Reply-to: mar...@gregorie.org To: Matt Kettler mkettler...@verizon.net Subject: Re: rules Date: Wed, 10 Mar 2010 12:19:23 + On Tue, 2010-03-09 at 20:52 -0500, Matt Kettler wrote: I'm not really an expert on simscan, but if it calls spamc as an interface to spamd, by default spamc will skip scanning messages over 500kb (to avoid bogging SA down on emails that are more likely to be business emails with large attachments). Are the affected messages all over 500k? Simscan is a single C source file available here: http://www.inter7.com/?page=simscan It goes on a bit but is quite easy to read and there's a README documenting its arguments in the documentation wiki. Simscan calls spamc rather than spamassassin. What it does depends on a set of options: --enable-spam=y|n Turn on spam scanning. default no. --enable-spam-passthru=y|nPass spam email thru or reject Default: disable (reject) --enable-spamc-user=y|n Set user option to spamc. --enable-spam-hits=number Reject spam above this hit level. Default 10.0 --enable-spamc=PATH Full path to spamc program. --enable-spamc-args=ARGSArguments to pass to spamc. The --enable-spamc-user controls whether it runs in per-user mode. The -u option is always used together with any spamc arguments defined with the simscan --enable-spamc-args=ARGS option, so the OP needs to read his qmail config to see what, if any, overrides have been supplied. Martin
Re: SMTP REJECT after DATA (was: SpamAssassin Milter Plugin...)
On Wed, 10 Mar 2010, R-Elists wrote: Charles Gregory Quote:Re: [sa] Re: SMTP REJECT after DATA The only efficiency to be gained is to reject as much as possible after the RCPT_TO, before accepting DATA. But for systems like mine, with lousy user cooperation, rejecting some of the mail after DATA is still the best option. i would say you are arguing both sides and that it might be the issue. I'm arguing that with such a strong component of YMMV there is NO side in this debate that is so woefully wrong as to be labelled 'misguided', which is what I was responding to in my first posdt in this thread. i would tend to believe that most have made the choice not to straddle the fence I made my own choice, as outlined above, but 'sit on the fence' with regard to my opinion on 'best practice' or 'misguided decisions', because I don't belive there really is any one 'good' or 'bad' decision (except maybe the decision to backscatter, but we all agree that is 'bad'). are you blaming the users for your administration? ;-) Naturally. All good adminsitration is customer driven. |-D - C
Inconsistent Application of Rules?
I am using spamassassin v 3.2.5 invoked via spamc from Postfix v2.3.3. My local.conf file is pretty basic. The only change is to shut off the FH_DATE_PAST_20XX rules which triggers for every message from Jan 1, 2010 on required_hits 5 report_safe 0 rewrite_header Subject [SPAM] skip_rbl_checks 0 score FH_DATE_PAST_20XX 0 I've been seeing several emails lately that are being scored low that, from what I know of the SA rules should be scored higher. A recent example was a typical spam message: --- Begin --- March 10, 2010 12:59:09 --- Enter shop here [URL deleted because it causes my message to be rejected] bunch of random sentence frasgments deleted --- End --- The original incoming message arrived in my inbox with the following score: x-spam-status: No, score=2.1 required=5.0 tests=BAYES_50,RDNS_NONE,URIBL_BLACK autolearn=no version=3.2.5 x-spam-checker-version: SpamAssassin 3.2.5 (2008-06-10) on cadmzmx01.lereta.com x-spam-level: ** Out of curiosity I copied the original message body and sent it to myself from a test address. The headers this time looked like: x-spam-status: No, score=4.4 required=5.0 tests=AWL,BAYES_00, FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,URIBL_AB_SURBL,URIBL_JP_SURBL, URIBL_OB_SURBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=no version=3.2.5 x-spam-checker-version: SpamAssassin 3.2.5 (2008-06-10) on cadmzmx01.lereta.com x-spam-level: The second message invoked a larger number of body check rules than the first but I don't understand why. Is that normal or do I have something configured incorrectly? (I tried sending the complete headers but that message was bounced as spam!) -- Stephen Carville
SpamAssassin Milter Plugin Input Validation Flaw patch
Hi, an untested patch was written see http://savannah.nongnu.org/bugs/?29136 http://savannah.nongnu.org/support/download.php?file_id=19901 for urgent might try, other should wait until harder tested i think -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Inconsistent Application of Rules?
On Wed, 10 Mar 2010, Stephen Carville wrote: --- Enter shop here [URL deleted because it causes my message to be rejected] Please publish the entire message including all headers to someplace like pastebin, and send us the link. tests=BAYES_50,RDNS_NONE,URIBL_BLACK Out of curiosity I copied the original message body and sent it to myself from a test address. The headers this time looked like: x-spam-status: No, score=4.4 required=5.0 tests=AWL,BAYES_00, FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,URIBL_AB_SURBL,URIBL_JP_SURBL, URIBL_OB_SURBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=no version=3.2.5 x-spam-checker-version: SpamAssassin 3.2.5 (2008-06-10) on cadmzmx01.lereta.com x-spam-level: The second message invoked a larger number of body check rules than the first but I don't understand why. Is that normal or do I have something configured incorrectly? The RCVD_IN checks being different aren't surprising as the test message came from a different source. The URIBL hits may be due to timing - i.e. the URI was added sometime between the original receipt of the message and your later test. Whether the original sender should have hit DNSBLs we can't tell until you post the original headers. It looks like a simple matter of a very short spam with a URI that wasn't broadly recognized as bad the first time you saw it. Train your bayes with it, and consider adding greylisting to give the URIBLs a chance to get updated with new spam domains. -- 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 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- 4 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: [sa] Inconsistent Application of Rules?
On Wed, 10 Mar 2010, Stephen Carville wrote: I've been seeing several emails lately that are being scored low that, from what I know of the SA rules should be scored higher. A recent example was a typical spam message: FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,URIBL_AB_SURBL,URIBL_JP_SURBL, URIBL_OB_SURBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=no The second message invoked a larger number of body check rules than the first but I don't understand why. Is that normal or do I have something configured incorrectly? The extra rules are all 'SURBL' blocklist tests which check the embedded URI against internet blocklists. It is not uncommon for the first few spams using a new URI to get through before the blocklists are updated. By the time you reran your tests, they had been updated, and so it scored higher - C
Body only checking through spamc
Hi Is there anyway to use spamc to only check the body section of an email? This is necessary when checking for emails that haven't been sent yet. Please help. -- View this message in context: http://old.nabble.com/Body-only-checking-through-spamc-tp27853336p27853336.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Inconsistent Application of Rules?
On Wed, Mar 10, 2010 at 9:14 AM, John Hardin jhar...@impsec.org wrote: On Wed, 10 Mar 2010, Stephen Carville wrote: --- Enter shop here [URL deleted because it causes my message to be rejected] Please publish the entire message including all headers to someplace like pastebin, and send us the link. http://www.heronforge.net/files/spam.message.01.txt http://www.heronforge.net/files/spam.message.02.txt The RCVD_IN checks being different aren't surprising as the test message came from a different source. The URIBL hits may be due to timing - i.e. the URI was added sometime between the original receipt of the message and your later test. Whether the original sender should have hit DNSBLs we can't tell until you post the original headers. That would explain the apparent anomaly. It looks like a simple matter of a very short spam with a URI that wasn't broadly recognized as bad the first time you saw it. Train your bayes with it, and consider adding greylisting to give the URIBLs a chance to get updated with new spam domains. I am haven't turned on Baysean filtering yet. I still need to test for the false positive rate. Until a week ago my employer used Forefront for spam filtering and about 10% of the messages it caught were legitimate and users were still getting an estimated 72 undetected spam messages per user per day. That made management nervous about filtering so I'm taking baby steps at turning on some tests. So far the UCE controls in Postfix combined with Spamassassin's default settings have reduced the undetected spam to an estimated 2 - 3 per user per day. -- Stephen Carville
Re: Body only checking through spamc
On Wed, 2010-03-10 at 09:45 -0800, yongke wrote: Is there anyway to use spamc to only check the body section of an email? This is necessary when checking for emails that haven't been sent yet. This is possible provided that all your users send mail through an MTA that's under your control and that you have controls in place to prevent them sending mail by other routes. Under these conditions messages will contain a few headers which it may be worthwhile to scan, e.g.: From:has the sender been forged? To: are there addresses which mail should not be sent to? Subject: should a subject line always be present? Date:is it within, say, 5 minutes of the server's time? If your users can send messages via other routes forget it. Its not possible to scan messages that are sent directly to external MTAs. Since you haven't described your mail set-up its not possible to say more than this. Martin
Re: Body only checking through spamc
Hi Martin Thanks a lot for the reply, the emails our clients sends are under our control and under our MTA. How exactly would I do this though? What I have is just the email body in HTML from our clients, subject, to, etc, and some account information. Do I need to actually get the created final email outgoing before running spamc on it? Or can I just run spamc on the HTML body... What I have is something like this: html text text text.. /html -- View this message in context: http://old.nabble.com/Body-only-checking-through-spamc-tp27853336p27854454.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Bogus mails from hijacked accounts
We seem to be having a problem where clients that we interact with regularly are having their hotmail/gmail/yahoo accounts hijacked. We are receiving e-mails from their accounts that legitimately go through the correct servers (hotmail,yahoo, etc.) and so they get passed through our spam filters. The messages have different bodies but basically say the same thing that they were on vacation and had all their money stolen so they need to have money wire transferred to them. Obviously we just have to tell the clients that they need to deal with the various e-mail providers, but is there an effective way that I can filter these messages out before my users see them without blacklisting the address? In one case I had probably 15 users that received the same message and naturally they freaked out. I have put a sample at: http://pastebin.com/9BDXrxmm Note I did change the real e-mail address in this message but the hotmail address used is valid just masked. The message doesn't hit any rules of significance on my system. BAYES_00=-1.9,FREEMAIL_FROM=0.001,HTML_MESSAGE=0.001,RCVD_IN_DNSWL_NONE=-0.0001,SPF_PASS=-0.001,T_RP_MATCHES_RCVD=-0.01,T_TO_NO_BRKTS_FREEMAIL=0.01 Thanks --Dennis
Re: Body only checking through spamc
On Wed, 2010-03-10 at 11:13 -0800, yongke wrote: Thanks a lot for the reply, the emails our clients sends are under our control and under our MTA. How exactly would I do this though? What I have is just the email body in HTML from our clients, subject, to, etc, and some account information. Do I need to actually get the created final email outgoing before running spamc on it? Or can I just run spamc on the HTML body... What I have is something like this: html text text text.. /html What, no plain text? That's guaranteed to add some spam points to the message when its passed to SA. You'll need to configure your MTA so mail from your users is passed to spamc before being passed to a post-processing program. This should let it be sent if its ham and re-address it to the sender if its spam, possibly as an attachment to a covering message. If you don't want to send out mail containing SA headers, the post-processing program can simply remove all headers that start with X-spam. I don't know of a program that can post-process spamc output, but if one exists I'm certain somebody else will tell you about it. Martin
Re: Bogus mails from hijacked accounts
On Wed, 2010-03-10 at 13:37 -0600, Dennis B. Hopp wrote: Obviously we just have to tell the clients that they need to deal with the various e-mail providers, but is there an effective way that I can filter these messages out before my users see them without blacklisting the address? There's nothing in SA that can blacklist a sending MTA, so blacklisting can't happen unless you've added something to your MTA set-up that does auto-blacklisting. The question then comes down to marking the message as spam and dealing with it however you normally deal with spam. You'll probably need custom rule(s) to handle that. You say the message bodies are quite variable, but I notice that the Reply-to: header doesn't remotely match the From: header. Is this a common factor? If it is, and the body texts have no common features that could also be used, the only obvious approach would be a rule for each forged sending domain that fires if the sending domain doesn't match the Reply-to domain. Only you can know if these rules would cause false positives: I can't possibly tell from a single sample message. Martin
Re: Bogus mails from hijacked accounts
On Wed, 2010-03-10 at 20:22 +, Martin Gregorie wrote: On Wed, 2010-03-10 at 13:37 -0600, Dennis B. Hopp wrote: Obviously we just have to tell the clients that they need to deal with the various e-mail providers, but is there an effective way that I can filter these messages out before my users see them without blacklisting the address? There's nothing in SA that can blacklist a sending MTA, so blacklisting can't happen unless you've added something to your MTA set-up that does auto-blacklisting. I meant blacklisting the sender address, not the MTA. The question then comes down to marking the message as spam and dealing with it however you normally deal with spam. You'll probably need custom rule(s) to handle that. You say the message bodies are quite variable, but I notice that the Reply-to: header doesn't remotely match the From: header. Is this a common factor? The ones that I have seen the reply-to doesn't match the from and I think the reply-to have all been something.jp If it is, and the body texts have no common features that could also be used, the only obvious approach would be a rule for each forged sending domain that fires if the sending domain doesn't match the Reply-to domain. There isn't anything in common that I can see that wouldn't be susceptible to false positives. One even left the clients signature intact. I've written fairly simple custom rules before but I'm not sure how to do conditional rules. I'll have to dig into the docs a little more. Only you can know if these rules would cause false positives: I can't possibly tell from a single sample message. I wasn't expecting anybody to give me a magic rule that would fix it, just suggestions since I would only be able to blacklist the sender address after the e-mail had been received and I was notified of the problem. And obviously blacklisting all of gmail/hotmail/yahoo isn't an option. Thanks, --Dennis
Re: Bogus mails from hijacked accounts
On Wed, 2010-03-10 at 15:08 -0600, Dennis B. Hopp wrote: I meant blacklisting the sender address, not the MTA. From what you're describing the senders are all forged by somebody who bought or stole a list of valid hotmail etc. addresses and the corresponding addresses in your domain, so blacklisting anything is probably a bad idea because it wouldn't do anything except annoy the actual owner of the address. There isn't anything in common that I can see that wouldn't be susceptible to false positives. One even left the clients signature intact. I've written fairly simple custom rules before but I'm not sure how to do conditional rules. I'll have to dig into the docs a little more. Its not conditional, just using a meta rule and negating the Reply-to test in the meta: describe FORGED_HOTMAIL Hotmail with non-Hotmail Reply-to address header __FORGED_HM1 From ~= /\...@hotmail\.com/i header __FORGED_HM2 Reply-to ~= /\...@hotmail\.com/i meta FORGED_HOTMAIL (__FORGED_HM1 !__FORGED_HM2) scoreFORGED_HOTMAIL 5.0 and write cookie cutter rules for Yahoo and Gmail. OTOH if you're happy that a Japanese test won't generate FPs you can cover all three ISPs with one rule: describe FORGED_FROM Hotmail,Yahoo or Google with Japanese Reply-to header __FF1 From ~= /\@(hotmail|yahoo|gmail)\.com/i header __FF2 Reply-to ~= /\.jp/i meta FORGED_FROM (__FF1 __FF2) scoreFORGED_FROM 5.0 Of course, if its just a few Japanese ISPs being used you can easily make _FF2 more specific. Martin
My First Spam Mail Today
OK so today I got my 1st spam email from someone at a yahoo.com email address. Basically SA didn't score it at all and 'Postgray' did it's job. Below are the headers from SA: X-spam-checker-version: SpamAssassin 3.3.0 (2010-01-18) on mail.iamghost.com X-spam-level: X-spam-status: No, score=0.0 required=6.3 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,TVD_SPACE_RATIO,T_DKIM_INVALID autolearn=ham version=3.3.0 Received: from web51707.mail.re2.yahoo.com (web51707.mail.re2.yahoo.com [206.190.38.225]) by mail.iamghost.com (Postfix) with SMTP id 094744059 for car...@iamghost.com; Wed, 10 Mar 2010 11:04:04 -0500 (EST) Received: (qmail 55813 invoked by uid 60001); 10 Mar 2010 12:04:03 - Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1268222643; bh=40eDTxXUsGn0fMF8GraXJhuKKlHlm9is5R5TfWxrsTY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=AB7PjrgviIl6G8eoxtXEYsRV0r/L744GYWgtL8pwpEOkKQPQPIarPNrd7csXfXc5Xl1AZyABQy8cx26ljNyrhAz90LdRHzFIZ+4cXTwqfiGz4ep/fGOyTjIeYW642wtUbtGCskCF5x0ffoTaBDD5Zk0WTARijt/0sGXnoFAb/6w= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Tyd/oHsBFk0RvLYTw+I5/poGilD24lzOF6hzQ0wPGB2dGz1yn/HruU+3Rb69gzKVSiW3RXuBNn4XdBB5t2mrPXq67Ji2p0+pUAirHbnCun3csbsVQBRnsrmylQdZon8im+yZPT9OEGZrd3mBoPaedYsDteMW82yXCnSnxx64cQk=; Message-id: 903238.54368...@web51707.mail.re2.yahoo.com My question is what do you recommend I do to avoid this? I don't know how this person (spammer) got my email address but regardless its out there and I can't block all Yahoo servers because some of my friends do have legit Yahoo accounts and send me email. Is there something I should tweak / change on my server? I added my Postfix mail log for anyone who cares to see it but I am just asking for advice on what to do since this is a new email server and I don't want to start getting spam. I hope someone can please point me in the right direction... Mar 10 11:04:04 mail postfix/smtpd[4563]: connect from web51707.mail.re2.yahoo.com[206.190.38.225] Mar 10 11:04:05 mail postgrey[1146]: action=pass, reason=client whitelist, client_name=web51707.mail.re2.yahoo.com, client_address=206.190.38.225, sender=marathoner...@yahoo.com, recipient=car...@iamghost.com Mar 10 11:04:05 mail postgrey[1146]: cleaning up old logs... Mar 10 11:04:05 mail postfix/smtpd[4563]: 094744059: client=web51707.mail.re2.yahoo.com[206.190.38.225] Mar 10 11:04:05 mail postfix/cleanup[4567]: 094744059: message-id=903238.54368...@web51707.mail.re2.yahoo.com Mar 10 11:04:05 mail postfix/qmgr[1143]: 094744059: from=marathoner...@yahoo.com, size=2372, nrcpt=1 (queue active) Mar 10 11:04:05 mail postfix/smtpd[4563]: disconnect from web51707.mail.re2.yahoo.com[206.190.38.225] Mar 10 11:04:10 mail postfix/pickup[4556]: 8DA03405C: uid=5001 from=marathoner...@yahoo.com Mar 10 11:04:10 mail postfix/cleanup[4567]: 8DA03405C: message-id=903238.54368...@web51707.mail.re2.yahoo.com Mar 10 11:04:10 mail postfix/pipe[4568]: 094744059: to=car...@iamghost.com, relay=spamassassin, delay=5.9, delays=0.66/0.01/0/5.3, dsn=2.0.0, status=sent (delivered via spamassassin service) Mar 10 11:04:10 mail postfix/qmgr[1143]: 094744059: removed Mar 10 11:04:10 mail postfix/qmgr[1143]: 8DA03405C: from=marathoner...@yahoo.com, size=2722, nrcpt=1 (queue active) Mar 10 11:04:10 mail postfix/local[4572]: 8DA03405C: to=car...@iamghost.com, relay=local, delay=0.12, delays=0.07/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to maildir) Mar 10 11:04:10 mail postfix/qmgr[1143]: 8DA03405C: removed
Re: Bogus mails from hijacked accounts
Dennis B. Hopp wrote: On Wed, 2010-03-10 at 20:22 +, Martin Gregorie wrote: On Wed, 2010-03-10 at 13:37 -0600, Dennis B. Hopp wrote: Obviously we just have to tell the clients that they need to deal with the various e-mail providers, but is there an effective way that I can filter these messages out before my users see them without blacklisting the address? There's nothing in SA that can blacklist a sending MTA, so blacklisting can't happen unless you've added something to your MTA set-up that does auto-blacklisting. I meant blacklisting the sender address, not the MTA. Welcome to Whack-A-Spammer! Here's your pea-shooter; the targets are behind 3 feet of concrete on the other side of this mile-wide canyon. Sarcasm aside, there are two problems with blacklisting the sender to block spam: 1) Spammers rotate sender addresses and hijacked account info more often than most of us change our underwear. An account *may* get reused; chances are it'll be months before it does, and the spammers will have rotated through hundreds or thousands of others - both phish-cracked and those set up just to send their junk. Blacklisting a sender is reduced to blocking the persistent friend-of-a-friend who refuses to remove you from the endless stream of chain-forwards, and legitimate-but-totally-clueless mailing list operators who can't figure out how to unsubscribe you from their list. :( 2) You noted originally that these appear to be fully legitimate freemail accounts, legitimately used in the past to correspond with your customers/clients, that have been compromised and then used to send spam. How do you propose to still allow the legitimate account holders to email your clients if you blacklist the sender? The question then comes down to marking the message as spam and dealing with it however you normally deal with spam. You'll probably need custom rule(s) to handle that. You say the message bodies are quite variable, but I notice that the Reply-to: header doesn't remotely match the From: header. Is this a common factor? The ones that I have seen the reply-to doesn't match the from and I think the reply-to have all been something.jp If it is, and the body texts have no common features that could also be used, the only obvious approach would be a rule for each forged sending domain that fires if the sending domain doesn't match the Reply-to domain. There isn't anything in common that I can see that wouldn't be susceptible to false positives. One even left the clients signature intact. I've written fairly simple custom rules before but I'm not sure how to do conditional rules. I'll have to dig into the docs a little more. Martin's suggestion followup should point you in the right direction. Sets of phrase rules (how similar are these messages? do you have ten or fifteen you can compare sentence-by-sentence?) with low scores will likely help some too. Meta rules that bump the score up depending on how many phrases hit, or phrase+mismatched-sender/reply also work tolerably well on this class of spam... if you can get enough samples to build a complete enough set of phrase rules. You'll have to decide how to balance aggressiveness on the content vs still allowing legitimate messages through. Feeding these to Bayes should also help some. -kgd
Re: My First Spam Mail Today
On Wed, 2010-03-10 at 22:17 +, Carlos Mennens wrote: OK so today I got my 1st spam email from someone at a yahoo.com email address. Basically SA didn't score it at all and 'Postgray' did it's job. Below are the headers from SA: Thats not a lot to go on: only a few headers and no message body. If postgray did its job, why have you got any headers to show? Post the entire message to pastebin or a similar site and send the URL here together with your explanation of what happened so we have something to work with. Martin
Re: Bogus mails from hijacked accounts
On Wed, 10 Mar 2010, Dennis B. Hopp wrote:
We seem to be having a problem where clients that we interact with
regularly are having their hotmail/gmail/yahoo accounts hijacked. We
are receiving e-mails from their accounts that legitimately go through
the correct servers (hotmail,yahoo, etc.) and so they get passed through
our spam filters. The messages have different bodies but basically say
the same thing that they were on vacation and had all their money stolen
so they need to have money wire transferred to them.
Obviously we just have to tell the clients that they need to deal with
the various e-mail providers, but is there an effective way that I can
filter these messages out before my users see them without blacklisting
the address? In one case I had probably 15 users that received the same
message and naturally they freaked out.
I have put a sample at:
http://pastebin.com/9BDXrxmm
Note I did change the real e-mail address in this message but the
hotmail address used is valid just masked.
Look at that X-Originating-IP: [41.155.87.236] header, its a dial-up
pool in Lagos Nigeria.
It may seem stereotyped, but it's amazing the percentage of this kind
of spam that -does- come out of that part of the world.
Does anybody have an SA plugin that will grab those X-Originating-IP
headers and throw the address at an RBL? Points for hits by CBL
or a ip-geolocation table for Central Africa.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
