RE: Joe-job blowback
Karsten Bräckelmann wrote: > Please keep list-posts on the list. Yeah, sorry about that. Most lists I'm on I just have to hit reply. Some I have to hit Reply-All. This one seems to vary with each user. I prefer to hit reply and have it go back to the list but not everybody does. I'm sure those wars were fought here long ago. I'll try to remember to check my To: field before sending. > On Mon, 2009-08-31 at 16:23 -0800, Kevin Miller wrote: >> Karsten Bräckelmann wrote: >>> VBounce plugin. >> >> Yup, got it enabled. Pretty minimal scoring though. Followed the >> instructions at http://wiki.apache.org/spamassassin/VBounceRuleset >> to set it up. >> >>> Use it to filter / deliver hits into a dedicated folder, rather than >>> attempting to raise the score into oblivion. See 20_vbounce.cf and >>> its docs. > > Sic. Use the hits for filtering. NOT scoring bounces high. They are > not spam, and they are likely to bias your Bayes database, if you > treat them as such. > > $ grep -A 2 procmail 20_vbounce.cf > > # If you use this, set up procmail or your mail app to spot the # > "ANY_BOUNCE_MESSAGE" rule hits in the X-Spam-Status line, and move # > messages that match that to a 'vbounce' folder. > > >>> Also see quite a lot of related posts in the past by me, how to >>> handle VBounce hits. >> >> Thanks, I'll check the archives... > > Pretty much the above. :) Don't raise the score. Treat the > backscatter hitting that rule differently. Hmmm. I see the point about the Bayes issue. Not sure if I can use procmail in this case though, as my mx servers are just gateways. The mail comes in, and is then processed by MailScanner (which calls spamassassin, among other things) and sent to an internal Exchange server. No local mailboxes on the gateways. But I may be able to set up some appropriate rules in MailScanner to accomplish the same thing. I'll ask over on that list... ...Kevin -- Kevin MillerRegistered Linux User No: 307357 CBJ MIS Dept. Network Systems Admin., Mail Admin. 155 South Seward Street ph: (907) 586-0242 Juneau, Alaska 99801fax: (907 586-4500
RE: Joe-job blowback
Benny Pedersen wrote: > On man 31 aug 2009 23:11:14 CEST, Kevin Miller wrote > >> to a bunch of Russian recipients on servers that don't bother to >> check SPF, with my users address in the from field. The Russian >> servers then send NDRs for non-existant users on their servers. >> Rather than reject at the handshake, they're apparently accepting the >> spam then bouncing it. > > block sender ip in mta for this mails, there is no point in spam > scanning bounces anyway when the remote server did a very fine job of > spam scanning and bounce spam, you are not alone on this problem, if > more mta setups checks spf in mta, there would be less bounces to > forged senders Well, the remote servers didn't do a good job of spam scanning. If they did they woudn't be bouncing it! :-) > what mta is used on the remote ?, and is there sign of something > going bad with qoutas ? It's not one remote server. That would be too easy. It's dozens. Or more. Botted hosts are sending spam to dozens of Russian ISPs/mail servers. Naturaly there are invalid addresses in there which are bounced to my domain. I use SPF. If the remote servers did as well I'd never see any of this but they don't. > its should really be made a howto run a mta for dummies :) Too many dummies running mail servers already. If there wasn't, there wouldn't be a need for spamassassin. :-) ...Kevin -- Kevin MillerRegistered Linux User No: 307357 CBJ MIS Dept. Network Systems Admin., Mail Admin. 155 South Seward Street ph: (907) 586-0242 Juneau, Alaska 99801fax: (907 586-4500
RE: Joe-job blowback
On man 31 aug 2009 23:11:14 CEST, Kevin Miller wrote to a bunch of Russian recipients on servers that don't bother to check SPF, with my users address in the from field. The Russian servers then send NDRs for non-existant users on their servers. Rather than reject at the handshake, they're apparently accepting the spam then bouncing it. block sender ip in mta for this mails, there is no point in spam scanning bounces anyway when the remote server did a very fine job of spam scanning and bounce spam, you are not alone on this problem, if more mta setups checks spf in mta, there would be less bounces to forged senders what mta is used on the remote ?, and is there sign of something going bad with qoutas ? its should really be made a howto run a mta for dummies :) -- xpoint
RE: Joe-job blowback
Please keep list-posts on the list.
On Mon, 2009-08-31 at 16:23 -0800, Kevin Miller wrote:
> Karsten Bräckelmann wrote:
> > VBounce plugin.
>
> Yup, got it enabled. Pretty minimal scoring though. Followed the
> instructions at http://wiki.apache.org/spamassassin/VBounceRuleset to
> set it up.
>
> > Use it to filter / deliver hits into a dedicated folder, rather than
> > attempting to raise the score into oblivion. See 20_vbounce.cf and
> > its docs.
Sic. Use the hits for filtering. NOT scoring bounces high. They are not
spam, and they are likely to bias your Bayes database, if you treat them
as such.
$ grep -A 2 procmail 20_vbounce.cf
# If you use this, set up procmail or your mail app to spot the
# "ANY_BOUNCE_MESSAGE" rule hits in the X-Spam-Status line, and move
# messages that match that to a 'vbounce' folder.
> > Also see quite a lot of related posts in the past by me, how to
> > handle VBounce hits.
>
> Thanks, I'll check the archives...
Pretty much the above. :) Don't raise the score. Treat the backscatter
hitting that rule differently.
--
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;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Joe-job blowback
On Mon, 2009-08-31 at 12:13 -0800, Kevin Miller wrote:
> I'm seeing a lot of blowback from Russian servers due to my domain
> users being joe-jobbed. [...]
VBounce plugin.
Use it to filter / deliver hits into a dedicated folder, rather than
attempting to raise the score into oblivion. See 20_vbounce.cf and its
docs.
Also see quite a lot of related posts in the past by me, how to handle
VBounce hits.
--
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;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
RE: Joe-job blowback
Martin Gregorie wrote: > On Mon, 2009-08-31 at 12:13 -0800, Kevin Miller wrote: >> I'm seeing a lot of blowback from Russian servers due to my domain >> users being joe-jobbed. >> > If you're not scanning outgoing mail or mail that doesn't cross the > domain boundary, then its reasonable to simply bin anything that > claims to be from your domain. Since it didn't originate in your > domain the sender must be forged. Problem isn't mail coming from one of my servers - problem is some server overseas is joe-jobbing my users. The foreign spammers send to a bunch of Russian recipients on servers that don't bother to check SPF, with my users address in the from field. The Russian servers then send NDRs for non-existant users on their servers. Rather than reject at the handshake, they're apparently accepting the spam then bouncing it. >> I'm writing a rule to check (among other things) the From: address. >> > Your MTA can probably deal with that without involving SA, but if you > want to involve SA, then > > describe LOC_FORGED Message with a forged sender > header LOC_FORGED From ~= /\.example\.com/m > scoreLOC_FORGED 10.0 > > should do the trick. Of course, if you also scan outbound and/or > intra-domain mail then things get a little trickier... Poking around in SA I found a similar rule to what I was trying to do and used it's setting: header__CBJ_PESKY_RUSKIES2Return-Path =~ /<>/ > I access my mail archive via a plugin and whitelisting rule that > whitelists mail from all senders who: > - have previously been sent mail from my domain > - are not recorded in the archive as users within my domain > > Any sender who passes this check is assigned a score of -50.0 by the > whitelisting rule. > > As a result I can be quite vicious with spam detection rules without > impacting mail from such correspondents. > > I hope this gives you ideas about similar approaches. Its working > well here. Thanks for the reply. Is the plugin publically accessible? ...Kevin -- Kevin MillerRegistered Linux User No: 307357 CBJ MIS Dept. Network Systems Admin., Mail Admin. 155 South Seward Street ph: (907) 586-0242 Juneau, Alaska 99801fax: (907 586-4500
Re: Joe-job blowback
On Mon, 2009-08-31 at 12:13 -0800, Kevin Miller wrote: > I'm seeing a lot of blowback from Russian servers due to my domain > users being joe-jobbed. > If you're not scanning outgoing mail or mail that doesn't cross the domain boundary, then its reasonable to simply bin anything that claims to be from your domain. Since it didn't originate in your domain the sender must be forged. > I'm writing a rule to check (among other things) the From: address. > Your MTA can probably deal with that without involving SA, but if you want to involve SA, then describe LOC_FORGED Message with a forged sender header LOC_FORGED From ~= /\.example\.com/m scoreLOC_FORGED 10.0 should do the trick. Of course, if you also scan outbound and/or intra-domain mail then things get a little trickier... I access my mail archive via a plugin and whitelisting rule that whitelists mail from all senders who: - have previously been sent mail from my domain - are not recorded in the archive as users within my domain Any sender who passes this check is assigned a score of -50.0 by the whitelisting rule. As a result I can be quite vicious with spam detection rules without impacting mail from such correspondents. I hope this gives you ideas about similar approaches. Its working well here. Martin
