You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jeremy Morton <ad...@game-point.net> on 2009/04/04 11:45:08 UTC

Ways to block bouncebacks?

Hi,

I'm running Spamassassin on my server because of my cPanel installation 
and have been for ages.  It's been working GREAT for blocking spam, and 
I'm happy about that.  However, of late, I've been joe-jobbed majorly, 
and I'm receiving thousands of bounceback messages in probably 20+ 
different languages that I don't want.  :-(  I'm prepared to lose 
bounceback messages to my genuine e-mails, to avoid all these.

So, I have 2 questions.

1. Is it possible to have a Spamassassin rule that considers subjects 
that contain a character glyph not used by the English or French 
languages (obviously punctuation, numbers, and some other stuff would 
also be allowed) to be spam?

2. Is there a Spamassassin rule that tries to catch any bounceback 
message (unfortunately in any language, I am getting bounceback messages 
in most languages known to mankind) to be spam?

Best regards,
Jeremy Morton (Jez)

Re: Ways to block bouncebacks?

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2009-04-05 at 11:12 +0100, Jeremy Morton wrote:
> Karsten Bräckelmann wrote:

> > ok_locales en    # all Western char sets in general
> 
> Maybe this is just the docs being worded badly, but it looks like that 
> simply marks en charset mail as being not spam... it doesn't 
> automatically mark non-en charset mail as being spam:
> "Mail using the character sets that are allowed by this option will not 
> be marked as possibly being spam in a foreign language."

Maybe it could be explained better, but I am confident you would have
figured it out after carefully reading it a second time.

The default is *all*. Hence, no mail will hit the CHARSET rules. If you
provide a custom list, the given charsets will not hit the rules -- all
charsets left out will be scored.


> What I want is to ALWAYS mark non-en charset mail as spam.  Does it do that?

Pretty much yes, see above.

However, given your second round of replies I sense your original
wording wasn't just the usual hasty bad phrasing...

(a) SA will *not* block mail. SA scores. Any action is the duty of
further tools in your mail processing chain.

(b) In the SA philosophy, a poison-pill that "always marks spam" does
not exist. Rules hit will assign scores, where each of them is below a
single kill threshold and negative scoring rules can prevent that. The
combined total score is what renders a mail spam.

While you sure /can/ set scores above required_threshold, it is commonly
advised against. In particular, no single CHARSET rule exceeds the
threshold. Combined they do, together with other rules they do.


-- 
char *t="\10pse\0r\0dtu\0.@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<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: Ways to block bouncebacks?

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> >>1. Is it possible to have a Spamassassin rule that considers subjects
> >>that contain a character glyph not used by the English or French
> >>languages (obviously punctuation, numbers, and some other stuff would
> >>also be allowed) to be spam?

> Karsten Bräckelmann wrote:
> >ok_locales en    # all Western char sets in general

On 05.04.09 11:12, Jeremy Morton wrote:
> Maybe this is just the docs being worded badly, but it looks like that 
> simply marks en charset mail as being not spam... it doesn't 
> automatically mark non-en charset mail as being spam:
> "Mail using the character sets that are allowed by this option will not 
> be marked as possibly being spam in a foreign language."

Yes, I guess that needs re-wording. Mail in other character sets will
apparently be spam and will be scored properly.

> What I want is to ALWAYS mark non-en charset mail as spam.  Does it do that?

increase the score for CHARSET_FARAWAY* rules. But you have been warned for
using too high score for one simple rule, haven't you?

-- 
Matus UHLAR - fantomas, uhlar@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.
I don't have lysdexia. The Dog wouldn't allow that.

Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Karsten Bräckelmann wrote:
>> 1. Is it possible to have a Spamassassin rule that considers subjects
>> that contain a character glyph not used by the English or French
>> languages (obviously punctuation, numbers, and some other stuff would
>> also be allowed) to be spam?
>
> ok_locales en    # all Western char sets in general

Maybe this is just the docs being worded badly, but it looks like that 
simply marks en charset mail as being not spam... it doesn't 
automatically mark non-en charset mail as being spam:
"Mail using the character sets that are allowed by this option will not 
be marked as possibly being spam in a foreign language."

What I want is to ALWAYS mark non-en charset mail as spam.  Does it do that?

Best regards,
Jeremy Morton (Jez)

Re: Ways to block bouncebacks?

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2009-04-05 at 11:20 +0100, Jeremy Morton wrote:
> Karsten Bräckelmann wrote:

> > whitelist_bounce_relays  your.outgoing.smtp
> >
> > See the VBounce documentation [2] and 20_vbounce.cf on your machine.
> > Simply define all your outgoing SMTP servers to enable the VBounce
> > plugin and rescue legit bounce messages. One server per line, multiple
> > instances allowed.
> 
> Looking at 20_vbounce.cf, it only seems to deal with English 
> backscatter.  :-)  That's why I mentioned all the languages.  I'm 

While there are some, this rule-set is not text-based only. There are
rules that catch generic non-delivery bounces based on headers and the
message's structure.

Did you even try it?

> literally getting tons of French, German, Spanish, Italian, etc. 
> backscatter too.  I need a pretty comprehensive rule covering all 
> western languages.  :-)

Feel free to come up with a comprehensive Out-of-Office excuse list,
translated into every single language out there...


Oh, and please do have a careful look at the explanation towards the
bottom in my previous post.


-- 
char *t="\10pse\0r\0dtu\0.@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<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Karsten Bräckelmann wrote:
[...]
>> 2. Is there a Spamassassin rule that tries to catch any bounceback
>> message (unfortunately in any language, I am getting bounceback messages
>> in most languages known to mankind) to be spam?
>
> whitelist_bounce_relays  your.outgoing.smtp
>
> See the VBounce documentation [2] and 20_vbounce.cf on your machine.
> Simply define all your outgoing SMTP servers to enable the VBounce
> plugin and rescue legit bounce messages. One server per line, multiple
> instances allowed.

Looking at 20_vbounce.cf, it only seems to deal with English 
backscatter.  :-)  That's why I mentioned all the languages.  I'm 
literally getting tons of French, German, Spanish, Italian, etc. 
backscatter too.  I need a pretty comprehensive rule covering all 
western languages.  :-)

Best regards,
Jeremy Morton (Jez)

Re: Ways to block bouncebacks?

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2009-04-04 at 10:45 +0100, Jeremy Morton wrote:
> I'm running Spamassassin on my server because of my cPanel installation 
> and have been for ages.  It's been working GREAT for blocking spam, and 
> I'm happy about that.  However, of late, I've been joe-jobbed majorly, 
> and I'm receiving thousands of bounceback messages in probably 20+ 
> different languages that I don't want.  :-(  I'm prepared to lose 
> bounceback messages to my genuine e-mails, to avoid all these.
> 
> So, I have 2 questions.
> 
> 1. Is it possible to have a Spamassassin rule that considers subjects 
> that contain a character glyph not used by the English or French 
> languages (obviously punctuation, numbers, and some other stuff would 
> also be allowed) to be spam?

ok_locales en    # all Western char sets in general

Also see the Language Options [1] section in the docs. Enabling this
will score character sets used in mail which are not explicitly allowed
in the list. Despite the name, 'en' applies to *all* western charsets,
including locale specific chars like in French, German, Norway, etc. Not
limited to the Subject only, but scores on the body and MIME parts, too.


> 2. Is there a Spamassassin rule that tries to catch any bounceback 
> message (unfortunately in any language, I am getting bounceback messages 
> in most languages known to mankind) to be spam?

whitelist_bounce_relays  your.outgoing.smtp

See the VBounce documentation [2] and 20_vbounce.cf on your machine.
Simply define all your outgoing SMTP servers to enable the VBounce
plugin and rescue legit bounce messages. One server per line, multiple
instances allowed.

Please note, that the VBounce plugin is *not* intended to mark back-
scatter as spam. Instead, filter on the rule hit and deliver it into a
dedicated folder. From 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.

Naturally, it doesn't catch all bounces, but it helps a great deal. Also
it does hit some daemon auto-generated, non-backscatter.


Both these options can be set site-wide in local.cf and on a per-user
basis in user_prefs.

  guenther


[1] http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html#language_options
[2] http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_VBounce.html

-- 
char *t="\10pse\0r\0dtu\0.@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<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Mark wrote:
> -----Original Message-----
> From: Jeremy Morton [mailto:admin@game-point.net]
> Sent: zondag 5 april 2009 11:54
> To: users@spamassassin.apache.org
> Subject: Re: Ways to block bouncebacks?
>
>> Again, I ask, what does SRS do to deal with bouncebacks that don't have
>> the SRS info in the To address?  They would just then appear as regular
>> e-mail messages, no?
>
> You seem to be missing the point: in an environment where all outgoing
> envelope-from addresses are SRS-signed, there's no such thing as an
> unsigined RCPT TO addresses on a DSN (with MAIL FROM:<>). That's because
> you know, for certain, you never sent out with an unsigned envelope-from
> address: hence, it cannot possibly return unsigned as RCPT TO recipient in
> a bounce! Hence, it's fake.

Sure.  But how do you tell a bounceback from a regular e-mail message?

Best regards,
Jeremy Morton (Jez)

RE: Ways to block bouncebacks?

Posted by Mark <ad...@asarian-host.net>.
-----Original Message-----
From: Jeremy Morton [mailto:admin@game-point.net]
Sent: zondag 5 april 2009 11:54
To: users@spamassassin.apache.org
Subject: Re: Ways to block bouncebacks?

> Again, I ask, what does SRS do to deal with bouncebacks that don't have
> the SRS info in the To address?  They would just then appear as regular
> e-mail messages, no?

You seem to be missing the point: in an environment where all outgoing
envelope-from addresses are SRS-signed, there's no such thing as an
unsigined RCPT TO addresses on a DSN (with MAIL FROM: <>). That's because
you know, for certain, you never sent out with an unsigned envelope-from
address: hence, it cannot possibly return unsigned as RCPT TO recipient in
a bounce! Hence, it's fake.

- Mark


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Again, I ask, what does SRS do to deal with bouncebacks that don't have 
the SRS info in the To address?  They would just then appear as regular 
e-mail messages, no?

Best regards,
Jeremy Morton (Jez)

Mark wrote:
> -----Original Message-----
> From: LuKreme [mailto:kremels@kreme.com]
> Sent: zaterdag 4 april 2009 19:47
> To: users@spamassassin.apache.org
> Subject: Re: Ways to block bouncebacks?
>
[...]
>
> Just to be clear on this, SRS wasn't my invention: it was primarily
> developed by Shevek, to work in conjunction with SPF. It is multi-teered,
> really (my doc just covers the basics). It allows for endless chained
> (SRS0/SRS1) return-paths, BerkeleyDB support (for resolving non-local
> machine parts)  and, far as I know, has no known flaws. It can be found
> (Perl version) at:
>
> http://search.cpan.org/~shevek/Mail-SRS-0.31/lib/Mail/SRS.pm
>
> - Mark
>
>

RE: Ways to block bouncebacks?

Posted by Mark <ad...@asarian-host.net>.
-----Original Message-----
From: LuKreme [mailto:kremels@kreme.com]
Sent: zaterdag 4 april 2009 19:47
To: users@spamassassin.apache.org
Subject: Re: Ways to block bouncebacks?

On 4-Apr-2009, at 04:07, Mark wrote:

> > Consider using SRS. I wrote a (now somewhat older) doc about it, at:
> >
> > http://srs-socketmap.info/sendmailsrs.htm
> >
> > But it gives you an idea. There's good C implementations for it,
> > these days, and it will definitely stop ALL fake bounce, with
> > no FPs.
>
> I've read up on this a bit and while SRS seems like a really great
> idea at first, I can see some real problems with it. Especially if
> you have a mail cluster instead of a single server.

Just to be clear on this, SRS wasn't my invention: it was primarily
developed by Shevek, to work in conjunction with SPF. It is multi-teered,
really (my doc just covers the basics). It allows for endless chained
(SRS0/SRS1) return-paths, BerkeleyDB support (for resolving non-local
machine parts)  and, far as I know, has no known flaws. It can be found
(Perl version) at:

http://search.cpan.org/~shevek/Mail-SRS-0.31/lib/Mail/SRS.pm

- Mark


Re: Ways to block bouncebacks?

Posted by LuKreme <kr...@kreme.com>.
On 4-Apr-2009, at 04:07, Mark wrote:
> Consider using SRS. I wrote a (now somewhat older) doc about it, at:
>
> http://srs-socketmap.info/sendmailsrs.htm
>
> But it gives you an idea. There's good C implementations for it, these
> days, and it will definitely stop ALL fake bounce, with no FPs.

I've read up on this a bit and while SRS seems like a really great  
idea at first, I can see some real problems with it.  Especially if  
you have a mail cluster instead of a single server.

-- 
Rumour is information distilled so finely that it can filter
	through anything. It does not need doors and windows --
	sometimes it does not need people. It can exist free and wild,
	running from ear to ear without ever touching lips.


Re: Ways to block bouncebacks?

Posted by mouss <mo...@ml.netoyen.net>.
Matus UHLAR - fantomas a écrit :
> On 05.04.09 14:18, Jeremy Morton wrote:
>> Hmm, not sure why my Spamassassin isn't detecting it as spam then.  How 
>> do I set Spamassassin to give me a full spam analysis header even when 
>> the message isn't detected as spam?  As you can see it just gives me a 
>> 'X-Spam-Status: No, score=1.7'.
> 
> Did you set up ok_locales and ok_languages in your SA config?
> That is what mouss meant by last sentence I quoted here ...
> 
>> mouss wrote:
>>> Content analysis details:   (10.5 points, 5.0 required)
>>>
>>>  pts rule name              description
>>> ---- ----------------------
>>> --------------------------------------------------
>>>  2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
>>>                             [URIs: fm.interia.pl]
> 
> This might get to uribl _after_ you received it. You need to have URIBL
> plugin allowed for this to hit (I recommend you to do that)
> 

yes. URIBL is getting more and more effective, as viewed from here. and
this view isn't just luck, because I have a few addresses which seem to
be "first targets" (I do report the corresponding URIs to uribl, and I
encourage others to do so).

>>>  0.0 MISSING_MID            Missing Message-Id: header
>>>  1.0 COUNTRY_CN             Relayed via China
> 
> mouss: This is not standard rule.
> 

I know, which is why I "concluded" by only referring to the CHARSET
rules, which are standard and static.

(I actually don't rely on this rule).

>>>  3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
>>>  1.8 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 
>>>  chars
>>>  2.5 MIME_CHARSET_FARAWAY   MIME character set indicates foreign language
>>>  0.1 RDNS_NONE              Delivered to trusted network by a host with
>>> no rDNS
>>>
>>> if you get your lang settings ok, then the CHARSET rules above would
>>> give 5.7 points, which is enough.
> 


Re: Ways to block bouncebacks?

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 05.04.09 14:18, Jeremy Morton wrote:
> Hmm, not sure why my Spamassassin isn't detecting it as spam then.  How 
> do I set Spamassassin to give me a full spam analysis header even when 
> the message isn't detected as spam?  As you can see it just gives me a 
> 'X-Spam-Status: No, score=1.7'.

Did you set up ok_locales and ok_languages in your SA config?
That is what mouss meant by last sentence I quoted here ...

> mouss wrote:
> >Content analysis details:   (10.5 points, 5.0 required)
> >
> >  pts rule name              description
> >---- ----------------------
> >--------------------------------------------------
> >  2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
> >                             [URIs: fm.interia.pl]

This might get to uribl _after_ you received it. You need to have URIBL
plugin allowed for this to hit (I recommend you to do that)

> >  0.0 MISSING_MID            Missing Message-Id: header
> >  1.0 COUNTRY_CN             Relayed via China

mouss: This is not standard rule.

> >  3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
> >  1.8 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 
> >  chars
> >  2.5 MIME_CHARSET_FARAWAY   MIME character set indicates foreign language
> >  0.1 RDNS_NONE              Delivered to trusted network by a host with
> >no rDNS
> >
> >if you get your lang settings ok, then the CHARSET rules above would
> >give 5.7 points, which is enough.

-- 
Matus UHLAR - fantomas, uhlar@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.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95

Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Hmm, not sure why my Spamassassin isn't detecting it as spam then.  How 
do I set Spamassassin to give me a full spam analysis header even when 
the message isn't detected as spam?  As you can see it just gives me a 
'X-Spam-Status: No, score=1.7'.

Best regards,
Jeremy Morton (Jez)

mouss wrote:
> Jeremy Morton a écrit :
>> [snip]
>> Examples of a couple of the type of bouncebacks I get:
>> http://www.game-point.net/misc/bb1.txt
>
> This one is not a "conformant" bounce. but this doesn't matter. it is
> detected as spam by SA:
>
> Content analysis details:   (10.5 points, 5.0 required)
>
>   pts rule name              description
> ---- ----------------------
> --------------------------------------------------
>   2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
>                              [URIs: fm.interia.pl]
>   0.0 MISSING_MID            Missing Message-Id: header
>   1.0 COUNTRY_CN             Relayed via China
>   3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
>   1.8 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 chars
>   2.5 MIME_CHARSET_FARAWAY   MIME character set indicates foreign language
>   0.1 RDNS_NONE              Delivered to trusted network by a host with
> no rDNS
>
> if you get your lang settings ok, then the CHARSET rules above would
> give 5.7 points, which is enough.
>
>> http://www.game-point.net/misc/bb2.txt
>
> This one is a "conformant" bounce. the envelope sender is "null":
> Return-path:<>
>
> if you use BATV, then you could reject such mail since the envelope
> recipient:
>
> Envelope-to: roams@game-point.net
>
> is not tagged.
>
> the message is detected as spam here:
>
> Content analysis details:   (5.3 points, 5.0 required)
>
>   pts rule name              description
> ---- ----------------------
> --------------------------------------------------
>   2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
>                              [URIs: fm.interia.pl]
>   0.0 MIME_BOUND_MANY_HEX    Spam tool pattern in MIME boundary
>   0.5 COUNTRY_BR             Relayed via Brazil
>   0.0 HTML_MESSAGE           BODY: HTML included in message
>   2.6 INVALID_MSGID          Message-Id is not valid, according to RFC 2822
>   0.1 BOUNCE_MESSAGE         MTA bounce message
>   0.1 ANY_BOUNCE_MESSAGE     Message is some kind of bounce message
>
> although it's less "obvious" than the other message.
>
> note that here, the vbounce rules are triggered.
>
>
> maybe I should add
>
> meta BOUNCE_URI_BLACK   (URIBL_BLACK&&  ANY_BOUNCE_MESSAGE)
>
> and score it a little high?
>
>
>

Re: Ways to block bouncebacks?

Posted by mouss <mo...@ml.netoyen.net>.
Jeremy Morton a écrit :
> [snip]
> Examples of a couple of the type of bouncebacks I get:
> http://www.game-point.net/misc/bb1.txt

This one is not a "conformant" bounce. but this doesn't matter. it is
detected as spam by SA:

Content analysis details:   (10.5 points, 5.0 required)

 pts rule name              description
---- ----------------------
--------------------------------------------------
 2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: fm.interia.pl]
 0.0 MISSING_MID            Missing Message-Id: header
 1.0 COUNTRY_CN             Relayed via China
 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
 1.8 MIME_QP_LONG_LINE      RAW: Quoted-printable line longer than 76 chars
 2.5 MIME_CHARSET_FARAWAY   MIME character set indicates foreign language
 0.1 RDNS_NONE              Delivered to trusted network by a host with
no rDNS

if you get your lang settings ok, then the CHARSET rules above would
give 5.7 points, which is enough.

> http://www.game-point.net/misc/bb2.txt

This one is a "conformant" bounce. the envelope sender is "null":
Return-path: <>

if you use BATV, then you could reject such mail since the envelope
recipient:

Envelope-to: roams@game-point.net

is not tagged.

the message is detected as spam here:

Content analysis details:   (5.3 points, 5.0 required)

 pts rule name              description
---- ----------------------
--------------------------------------------------
 2.0 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: fm.interia.pl]
 0.0 MIME_BOUND_MANY_HEX    Spam tool pattern in MIME boundary
 0.5 COUNTRY_BR             Relayed via Brazil
 0.0 HTML_MESSAGE           BODY: HTML included in message
 2.6 INVALID_MSGID          Message-Id is not valid, according to RFC 2822
 0.1 BOUNCE_MESSAGE         MTA bounce message
 0.1 ANY_BOUNCE_MESSAGE     Message is some kind of bounce message

although it's less "obvious" than the other message.

note that here, the vbounce rules are triggered.


maybe I should add

meta BOUNCE_URI_BLACK   (URIBL_BLACK && ANY_BOUNCE_MESSAGE)

and score it a little high?



Re: Ways to block bouncebacks?

Posted by Duane Hill <d....@yournetplus.com>.
On Sun, 5 Apr 2009, Jeremy Morton wrote:

> mouss wrote:
>> Jeremy Morton a ?crit :
>>> mouss wrote:
>>>> the recipient of the bounce is the sender of the original message. so if
>>>> you use BATV, you could block bounces sent to a non BATV address.
>>> Again, maybe I'm missing something here, but let's go back to basics;
>>> how do I identify a 'bounce' message?  There seems to be no standard for
>>> what a bounce message is, I've received probably 1000 different forms of
>>> message telling me e-mail couldn't be delivered for whatever reason, in
>>> 1000 different languages.
>>> 
>> 
>> a "conformant" bounce uses the null sender.
>> half-borked systems will use addresses like<ma...@xxx>  or
>> <po...@xxx>.
>> completely-borked systems use arbitrary addresses.
>> 
>> if you have sample, post one or two on the web. this is so we know what
>> we are talking about.
>
> Examples of a couple of the type of bouncebacks I get:
> http://www.game-point.net/misc/bb1.txt

X-Spam-Level: xxxxxxxxxx
X-Spam-Status: Reqd:5.0 Hits:10.6 Tests:BODY_8BITS=1.5,
CHARSET_FARAWAY_HEADER=3.2,MIME_CHARSET_FARAWAY=2.45,MIME_QP_LONG_LINE=1
.819,MISSING_MID=0.001,RCVD_IN_UCEPROTECT_1=1.5,RDNS_NONE=0.1

> http://www.game-point.net/misc/bb2.txt

X-Spam-Level: xxxxxx
X-Spam-Status: Reqd:5.0 Hits:6.6 Tests:ANY_BOUNCE_MESSAGE=0.1,
     BOUNCE_MESSAGE=0.1,HTML_MESSAGE=0.001,INVALID_MSGID=2.603,
     MIME_BOUND_MANY_HEX=0.001,RCVD_IN_BACKSCATTERER=1,
     UNWANTED_LANGUAGE_BODY=2.8

Both messages would have been trapped here.

RE: Ways to block bouncebacks?

Posted by Mark <ad...@asarian-host.net>.
-----Original Message-----
From: Jeremy Morton [mailto:admin@game-point.net] 
Sent: zondag 5 april 2009 13:44
To: mouss+nobulk@netoyen.net
Cc: users@spamassassin.apache.org
Subject: Re: Ways to block bouncebacks?

> Examples of a couple of the type of bouncebacks I get:
>
> http://www.game-point.net/misc/bb1.txt
> http://www.game-point.net/misc/bb2.txt

First one:

> Return-path: <ha...@doctor-china.org>
> Envelope-to: evaluation58@game-point.net

This isn't a valid bounce message to begin with: it should have had the
null sender (MAIL FROM: <>).

Second one:

> Return-path: <>
> Envelope-to: roams@game-point.net

Had you used SRS, this convo might have looked something like:

> Return-path: <>
> Envelope-to: SRS0=+fZygoFE=5I=game-point.net=roams@game-point.net

Which, after validation at MTA level, you would then have accepted. And
soon as the MTA came in at: RCPT TO: <ro...@game-point.net>, you would
have rejected it (for being unsigned).

- Mark


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
mouss wrote:
> Jeremy Morton a écrit :
>> mouss wrote:
>>> the recipient of the bounce is the sender of the original message. so if
>>> you use BATV, you could block bounces sent to a non BATV address.
>> Again, maybe I'm missing something here, but let's go back to basics;
>> how do I identify a 'bounce' message?  There seems to be no standard for
>> what a bounce message is, I've received probably 1000 different forms of
>> message telling me e-mail couldn't be delivered for whatever reason, in
>> 1000 different languages.
>>
>
> a "conformant" bounce uses the null sender.
> half-borked systems will use addresses like<ma...@xxx>  or
> <po...@xxx>.
> completely-borked systems use arbitrary addresses.
>
> if you have sample, post one or two on the web. this is so we know what
> we are talking about.

Examples of a couple of the type of bouncebacks I get:
http://www.game-point.net/misc/bb1.txt
http://www.game-point.net/misc/bb2.txt

Best regards,
Jeremy Morton (Jez)

Re: Ways to block bouncebacks?

Posted by mouss <mo...@ml.netoyen.net>.
Jeremy Morton a écrit :
> mouss wrote:
>> the recipient of the bounce is the sender of the original message. so if
>> you use BATV, you could block bounces sent to a non BATV address.
> 
> Again, maybe I'm missing something here, but let's go back to basics;
> how do I identify a 'bounce' message?  There seems to be no standard for
> what a bounce message is, I've received probably 1000 different forms of
> message telling me e-mail couldn't be delivered for whatever reason, in
> 1000 different languages.
> 

a "conformant" bounce uses the null sender.
half-borked systems will use addresses like <ma...@xxx> or
<po...@xxx>.
completely-borked systems use arbitrary addresses.

if you have sample, post one or two on the web. this is so we know what
we are talking about.

Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
mouss wrote:
> the recipient of the bounce is the sender of the original message. so if
> you use BATV, you could block bounces sent to a non BATV address.

Again, maybe I'm missing something here, but let's go back to basics; 
how do I identify a 'bounce' message?  There seems to be no standard for 
what a bounce message is, I've received probably 1000 different forms of 
message telling me e-mail couldn't be delivered for whatever reason, in 
1000 different languages.

Best regards,
Jeremy Morton (Jez)

Re: Ways to block bouncebacks?

Posted by mouss <mo...@ml.netoyen.net>.
Jeremy Morton a écrit :
> Unless I'm missing something, this is going to be utterly useless for
> me.  Wikipedia says:
> "E-mail that is being bounced back should have an empty (null) return
> address so that bounces are never created for a bounce and therefore you
> can't get messages bouncing back and forth forever."
> 
> I'm not quite sure what they mean by 'return address'; do they mean the
> From: field?  If so, all the backscatter I'm getting has a From: address
> so none of it would be considered bounce messages by BATV; it would be
> considered regular mail.
> 


the recipient of the bounce is the sender of the original message. so if
you use BATV, you could block bounces sent to a non BATV address.

but you can only do that if all sent mail is BATV-tagged. otherwise, you
would reject legitimate bounces.

another possibility is to use BATV as a whitelist mechanism:
- accept any bounces to a BATV tagged address
- be aggressive with other bounces

anyway, the only fix for the outscatter problem is to fix the sites that
send it. maybe at some time they should be completely blacklisted. at
least, this is what stopped open relay...


Re: Ways to block bouncebacks?

Posted by Benny Pedersen <me...@junc.org>.
On Sun, April 5, 2009 12:41, Jeremy Morton wrote:
> I'm not quite sure what they mean by 'return address'; do they mean
> the From: field?

Return-Path != From

> If so, all the backscatter I'm getting has a From: address

might be the sender, but not always

> so none of it would be considered bounce messages by BATV; it would
> be considered regular mail.

i dont know how well it works, but bouncers set envelope sender to
<> and thus not equal to from

-- 
http://localhost/ 100% uptime and 100% mirrored :)


RE: Ways to block bouncebacks?

Posted by Mark <ad...@asarian-host.net>.
-----Original Message-----
From: Jeremy Morton [mailto:admin@game-point.net]
Sent: zondag 5 april 2009 12:36
To: SM
Cc: users@spamassassin.apache.org
Subject: Re: Ways to block bouncebacks?

> Unless I'm missing something, this is going to be utterly useless for
> me.  Wikipedia says: "E-mail that is being bounced back should have an
> empty (null) return address so that bounces are never created for a
> bounce and therefore you can't get messages bouncing back and forth
> forever." I'm not quite sure what they mean by 'return address'; do they
> mean the From: field?  If so, all the backscatter I'm getting has a
> From: address so none of it would be considered bounce messages by BATV;
> it would be considered regular mail.

Yes, you're missing a lot. :) Seriously.

First off all, we're talking about MTA <-> MTA communication -- the
'envelope' stage of the SMTP transmission, to be precise. With 'return
address' they mean what I usually refer to as 'envelope-from' address, for
clarity. The envelope-from address (unless purposely imported with the
mail headers) is normally outside the regular scope of the MUA (Mail User
Agent). In my case, the SRS addresses are not visible to the end-users's
MUA (or maybe only in a 'Received for:' header when there's a single
recipient, or some such). Which you can observe on this very message: the
"From:" field in headers of this message is unsigned, but the SRS-signed
envelope-from address is listed in the header's "Return-Path" field. Mind
you, headers are part of the DATA phase: you should not rely on them to
contain the Return-Path header, and such info is not required for
inter-MTA communication, either.

BATV, to oversimplify the matter for brevity, is actually akin to the way
I use SRS (there's even a link to SRS for it on Wikipedia, and they even
state: "The overall framework is vague/flexible enough that similar
systems such as Sender Rewriting Scheme can fit into this framework.").
SRS, namely, was originally not at all designed to be used in a BATV kind
manner: it was invented to rewrite existing envelope-from addresses (with
the domain of the current MTA) to avoid the SPF-forwarding problem. I, and
others at the time, just figured out that SRS can also be used, very
effectively, to detect and eliminate fake bounces. So, yes, you could
certainly have a look at BATV, too.

But honestly, if you're not quite sure what they mean by 'return adress,'
and you get it confused with a mail 'From:' header, then you probably best
bone up a bit on your RFC knowledge; especially the contextual differences
between RFC 821 and RFC 2821. Otherwise we'll keep going around in
circles.

- Mark


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Unless I'm missing something, this is going to be utterly useless for 
me.  Wikipedia says:
"E-mail that is being bounced back should have an empty (null) return 
address so that bounces are never created for a bounce and therefore you 
can't get messages bouncing back and forth forever."

I'm not quite sure what they mean by 'return address'; do they mean the 
From: field?  If so, all the backscatter I'm getting has a From: address 
so none of it would be considered bounce messages by BATV; it would be 
considered regular mail.

Best regards,
Jeremy Morton (Jez)

SM wrote:
> At 02:59 05-04-2009, Jeremy Morton wrote:
>> Well, as far as I can tell from that document, SRS is great at saying,
>> "yep, this is a legit bounce message". But, if SRS says it doesn't
>> seem to be, aren't you rather back at square 1? A message that looks
>> like a regular e-mail, doesn't really have any spam
>
> You can use BATV. You must then submit all messages for the domain
> through a mail server that supports BATV.
>
> Regards,
> -sm
>

Re: Ways to block bouncebacks?

Posted by SM <sm...@resistor.net>.
At 02:59 05-04-2009, Jeremy Morton wrote:
>Well, as far as I can tell from that document, SRS is great at 
>saying, "yep, this is a legit bounce message".  But, if SRS says it 
>doesn't seem to be, aren't you rather back at square 1?  A message 
>that looks like a regular e-mail, doesn't really have any spam

You can use BATV.  You must then submit all messages for the domain 
through a mail server that supports BATV.

Regards,
-sm 


Re: Ways to block bouncebacks?

Posted by Jeremy Morton <ad...@game-point.net>.
Well, as far as I can tell from that document, SRS is great at saying, 
"yep, this is a legit bounce message".  But, if SRS says it doesn't seem 
to be, aren't you rather back at square 1?  A message that looks like a 
regular e-mail, doesn't really have any spam characteristics (Viagra, 
etc., just 'this mail was not delivered' or other such non-spammy text), 
and yet one that I still want to block?  How would SRS help deal with that?

Best regards,
Jeremy Morton (Jez)

Mark wrote:
> Consider using SRS. I wrote a (now somewhat older) doc about it, at:
>
> http://srs-socketmap.info/sendmailsrs.htm
>
> But it gives you an idea. There's good C implementations for it, these
> days, and it will definitely stop ALL fake bounce, with no FPs.
>
> - Mark
>
>
> -----Original Message-----
> From: Jeremy Morton [mailto:admin@game-point.net]
> Sent: zaterdag 4 april 2009 11:39
> To: users@spamassassin.apache.org
> Subject: Ways to block bouncebacks?
>
> Hi,
>
> I'm running Spamassassin on my server because of my cPanel installation
> and have been for ages.  It's been working GREAT for blocking spam, and
> I'm happy about that.  However, of late, I've been joe-jobbed majorly,
> and I'm receiving thousands of bounceback messages in probably 20+
> different languages that I don't want.  :-(  I'm prepared to lose
> bounceback messages to my genuine e-mails, to avoid all these.
>
> So, I have 2 questions.
>
> 1. Is it possible to have a Spamassassin rule that considers subjects
> that contain a character glyph not used by the English or French
> languages (obviously punctuation, numbers, and some other stuff would
> also be allowed) to be spam?
>
> 2. Is there a Spamassassin rule that tries to catch any bounceback
> message (unfortunately in any language, I am getting bounceback messages
> in most languages known to mankind) to be spam?
>
> Best regards,
> Jeremy Morton (Jez)
>
>

RE: Ways to block bouncebacks?

Posted by Mark <ad...@asarian-host.net>.
Consider using SRS. I wrote a (now somewhat older) doc about it, at:

http://srs-socketmap.info/sendmailsrs.htm

But it gives you an idea. There's good C implementations for it, these
days, and it will definitely stop ALL fake bounce, with no FPs.

- Mark


-----Original Message-----
From: Jeremy Morton [mailto:admin@game-point.net] 
Sent: zaterdag 4 april 2009 11:39
To: users@spamassassin.apache.org
Subject: Ways to block bouncebacks?

Hi,

I'm running Spamassassin on my server because of my cPanel installation 
and have been for ages.  It's been working GREAT for blocking spam, and 
I'm happy about that.  However, of late, I've been joe-jobbed majorly, 
and I'm receiving thousands of bounceback messages in probably 20+ 
different languages that I don't want.  :-(  I'm prepared to lose 
bounceback messages to my genuine e-mails, to avoid all these.

So, I have 2 questions.

1. Is it possible to have a Spamassassin rule that considers subjects 
that contain a character glyph not used by the English or French 
languages (obviously punctuation, numbers, and some other stuff would 
also be allowed) to be spam?

2. Is there a Spamassassin rule that tries to catch any bounceback 
message (unfortunately in any language, I am getting bounceback messages 
in most languages known to mankind) to be spam?

Best regards,
Jeremy Morton (Jez)