Mailing List Archive

ALL_SPAM_TO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm using spamassassin 3.0 cvs.
If incoming message contain few users but only one of them in
ALL_SPAM_TO all others user also receive message with spam.

all_spam_to user1@leaves.ru
But user2@leaves and user3@leaves.ru receive spam.

May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
X-Spam-Status: No, score=-87
.5 required=5.0
tests=BIZ_TLD,\n\tFORGED_RCVD_NET_HELO,RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,\
n\tRCVD_IN_DSBL,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_SBL,URIBL_SC_SURBL,
\n\tUSER_IN_ALL_SPAM_TO,X_MESS
~~~~~~~~~~~~~~~~~~~~~~~
~ AGE_INFO autolearn=no version=3.0.0-r10496
May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
X-Spam-Checker-Version: Spam
Assassin 3.0.0-r10496 (2004-05-02) on \n\tproxy.leaves.ru.
May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
to=<user1@leaves.ru>, delay=00:00:16, xdelay=00:00
:00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
to=<user2@leaves.ru>, delay=00:00:16, xdelay=0
0:00:00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
to=<user3@leaves.ru>, delay=00:00:16, xdelay=00:00
:00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent

- --
Sergey Smirnov
hkp://wwwkeys.pgp.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAmQ2sTW1qobfmhlsRAp+xAJ4iCRrxYvYaPBK2ald+57X4DetdvgCgjRSM
GU/vITpwh3Z1XyLAzwyTnh4=
=lyFK
-----END PGP SIGNATURE-----
Re: ALL_SPAM_TO [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Sergey Smirnov writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm using spamassassin 3.0 cvs.
> If incoming message contain few users but only one of them in
> ALL_SPAM_TO all others user also receive message with spam.
>
> all_spam_to user1@leaves.ru
> But user2@leaves and user3@leaves.ru receive spam.

When using a milter, it'll scan the message only once, even if that
message is being delivered to multiple recipients. The fix is to
use a system that'll scan the message once for each individual
recipient; we can't fix it inside SpamAssassin.

- --j.

> May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
> X-Spam-Status: No, score=-87
> .5 required=5.0
> tests=BIZ_TLD,\n\tFORGED_RCVD_NET_HELO,RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,\
> n\tRCVD_IN_DSBL,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_SBL,URIBL_SC_SURBL,
> \n\tUSER_IN_ALL_SPAM_TO,X_MESS
> ~~~~~~~~~~~~~~~~~~~~~~~
> ~ AGE_INFO autolearn=no version=3.0.0-r10496
> May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
> X-Spam-Checker-Version: Spam
> Assassin 3.0.0-r10496 (2004-05-02) on \n\tproxy.leaves.ru.
> May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> to=<user1@leaves.ru>, delay=00:00:16, xdelay=00:00
> :00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
> May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> to=<user2@leaves.ru>, delay=00:00:16, xdelay=0
> 0:00:00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
> May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> to=<user3@leaves.ru>, delay=00:00:16, xdelay=00:00
> :00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
>
> - --
> Sergey Smirnov
> hkp://wwwkeys.pgp.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFAmQ2sTW1qobfmhlsRAp+xAJ4iCRrxYvYaPBK2ald+57X4DetdvgCgjRSM
> GU/vITpwh3Z1XyLAzwyTnh4=
> =lyFK
> -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAmSMnQTcbUG5Y7woRAgC8AJ0VOlBESlymYJnpEKp5JAvojOea4ACgrwAW
l8AGX3WXqD0/jVq60SORYjE=
=+gfD
-----END PGP SIGNATURE-----
Re: ALL_SPAM_TO [ In reply to ]
Justin Mason wrote:
> When using a milter, it'll scan the message only once, even if that
> message is being delivered to multiple recipients. The fix is to
> use a system that'll scan the message once for each individual
> recipient; we can't fix it inside SpamAssassin.
>

MIMEDefang is a milter that will do just this.
Feature is stream_by_recipient()


From mimedefang-filter man pages:

stream_by_recipient()
Do not use this function unless you have Sendmail 8.12 and locally-
submitted e-mail is submitted using SMTP.


sub filter_begin {
if (stream_by_recipient()) {
return;
}
# Rest of filter_begin
}

If there is more than one recipient, stream_by_recipient() resends the
message once to each recipient. That way, you can customize your
filter rules on a per-recipient basis. This may increase the load on
your mail server considerably.

Also, a "recipient" is determined before alias expansion. So
"all@mydomain.com" is considered a single recipient, even if Sendmail
delivers to a list.

If you have Sendmail 8.12, then locally-submitted messages are sent via
SMTP, and MIMEDefang will be called for each resent message.
It is possible to set up Sendmail 8.12 so locally-submitted messages
are delivered directly; in this case, stream_by_recipient() will \fInot\fR
work.

stream_by_recipient() allows you to customize your filter rules for
each recipient in a manner similar to stream_by_domain().
Re: ALL_SPAM_TO [ In reply to ]
At 11:52 AM 5/5/2004, Sergey Smirnov wrote:

>I'm using spamassassin 3.0 cvs.
>If incoming message contain few users but only one of them in
>ALL_SPAM_TO all others user also receive message with spam.

Yep. That's normal, and is an inherent limitation of spamassassin's whitelists.

Fundamentally, whitelists are better done at a higher layer than SA, and
there's nothing SA can do to improve the situation because it's an inherent
limitation of being a mail filter. To improve the problem would involve
changing what SpamAssassin is, and how mail tools call it. It would also
prevent SA from being used in probmail completely.

SA never sees message envelopes. It does NOT know who will receive a given
message. All it knows is what addresses are in the message headers.

If you're at the MTA layer, you're even more out of luck, as there's NO way
to improve the situation. At the MTA layer, there's only one message,
despite multiple people.

If you're at the MDA layer (ie: procmail) you can improve things slightly.
Here there's one delivery per recipeint, and you can do things like have
procmail never call SA in the first place for the user in question. Or you
can use spamc -u and set up true per-user config options.
Re: ALL_SPAM_TO [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Kettler wrote:
| At 11:52 AM 5/5/2004, Sergey Smirnov wrote:
|
|> I'm using spamassassin 3.0 cvs.
|> If incoming message contain few users but only one of them in
|> ALL_SPAM_TO all others user also receive message with spam.
|
|
| Yep. That's normal, and is an inherent limitation of spamassassin's
| whitelists.
|
| Fundamentally, whitelists are better done at a higher layer than SA, and
| there's nothing SA can do to improve the situation because it's an
| inherent limitation of being a mail filter. To improve the problem would
| involve changing what SpamAssassin is, and how mail tools call it. It
| would also prevent SA from being used in probmail completely.
|
| SA never sees message envelopes. It does NOT know who will receive a
| given message. All it knows is what addresses are in the message headers.
|
| If you're at the MTA layer, you're even more out of luck, as there's NO
| way to improve the situation. At the MTA layer, there's only one
| message, despite multiple people.
|
| If you're at the MDA layer (ie: procmail) you can improve things
| slightly. Here there's one delivery per recipeint, and you can do things
| like have procmail never call SA in the first place for the user in
| question. Or you can use spamc -u and set up true per-user config options.
Unfortunately I'm using SA with sendmail + spamass-milter.
I can't use common procmail filter because I have to forward messages to
M$ Exchange and store copy of message locally.
It's easy for me use sendmail aliases than ~/.procmailrc files for each
users.
Only one person don't want use SA. Of cause he is M$ sysadmin.
- --
Sergey Smirnov
hkp://wwwkeys.pgp.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAme4TTW1qobfmhlsRAiVUAJ9/sKOwQDujv49M8mQRMYHw+FxLngCfbhb9
Ask6fQAI3Wp7h4WsKvKbaek=
=jGg5
-----END PGP SIGNATURE-----
Re: ALL_SPAM_TO [ In reply to ]
We have a way of doing this with exim, contact me directly if it is of
any use to you. It is too complex to put it all in here.

Ron
On Wed, 2004-05-05 at 18:23, Justin Mason wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Sergey Smirnov writes:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I'm using spamassassin 3.0 cvs.
> > If incoming message contain few users but only one of them in
> > ALL_SPAM_TO all others user also receive message with spam.
> >
> > all_spam_to user1@leaves.ru
> > But user2@leaves and user3@leaves.ru receive spam.
>
> When using a milter, it'll scan the message only once, even if that
> message is being delivered to multiple recipients. The fix is to
> use a system that'll scan the message once for each individual
> recipient; we can't fix it inside SpamAssassin.
>
> - --j.
>
> > May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
> > X-Spam-Status: No, score=-87
> > .5 required=5.0
> > tests=BIZ_TLD,\n\tFORGED_RCVD_NET_HELO,RCVD_HELO_IP_MISMATCH,RCVD_IN_BL_SPAMCOP_NET,\
> > n\tRCVD_IN_DSBL,RCVD_IN_XBL,RCVD_NUMERIC_HELO,URIBL_SBL,URIBL_SC_SURBL,
> > \n\tUSER_IN_ALL_SPAM_TO,X_MESS
> > ~~~~~~~~~~~~~~~~~~~~~~~
> > ~ AGE_INFO autolearn=no version=3.0.0-r10496
> > May 5 19:26:01 proxy sm-mta[19334]: i45FPg0h019334: Milter add: header:
> > X-Spam-Checker-Version: Spam
> > Assassin 3.0.0-r10496 (2004-05-02) on \n\tproxy.leaves.ru.
> > May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> > to=<user1@leaves.ru>, delay=00:00:16, xdelay=00:00
> > :00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
> > May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> > to=<user2@leaves.ru>, delay=00:00:16, xdelay=0
> > 0:00:00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
> > May 5 19:26:01 proxy sm-mta[19555]: i45FPg0h019334:
> > to=<user3@leaves.ru>, delay=00:00:16, xdelay=00:00
> > :00, mailer=local, pri=151646, dsn=2.0.0, stat=Sent
> >
> > - --
> > Sergey Smirnov
> > hkp://wwwkeys.pgp.net
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.4 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> > iD8DBQFAmQ2sTW1qobfmhlsRAp+xAJ4iCRrxYvYaPBK2ald+57X4DetdvgCgjRSM
> > GU/vITpwh3Z1XyLAzwyTnh4=
> > =lyFK
> > -----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Exmh CVS
>
> iD8DBQFAmSMnQTcbUG5Y7woRAgC8AJ0VOlBESlymYJnpEKp5JAvojOea4ACgrwAW
> l8AGX3WXqD0/jVq60SORYjE=
> =+gfD
> -----END PGP SIGNATURE-----
--
Ron McKeating
Senior IT Services Specialist
Internet Services and Software Solutions
Loughborough University
01509 222329
Re: ALL_SPAM_TO [ In reply to ]
At 11:49 AM 5/6/04 +0400, Sergey Smirnov wrote:
>Unfortunately I'm using SA with sendmail + spamass-milter.
>I can't use common procmail filter because I have to forward messages to
>M$ Exchange and store copy of message locally.
>It's easy for me use sendmail aliases than ~/.procmailrc files for each
>users.
>Only one person don't want use SA. Of cause he is M$ sysadmin.


With plain spamass-milter, I'm pretty sure you're not going to be able to
fix the problem, but I'll admitt I'm not all that familar with spamass-milter.

Since you need to stay at the MTA layer you might want to consider
MimeDefang, which one user suggested can be forced into splitting
multi-recipient messages up. From there you'd want to configure MimeDefang
to not call SA at all for your M$ friend. I'm not very familiar with
MimeDefang, but I'm pretty sure this is possible as I know the tool is VERY
flexible.

Another option is MailScanner. I know several people use a sendmail trick
to force it to split the messages before mailscanner gets them.
MailScanner's config can then be told to not spam scan for a given user, or
any kind of simple wildcard based rule on the envelope recipient.
MailScanner is also MTA layer, but operates by queuing mail via sendmail,
scanning it as queue files, and then passing it back to sendmail which can
relay or deliver.
Re: ALL_SPAM_TO [ In reply to ]
On Thu, 6 May 2004, Matt Kettler wrote:

> At 11:49 AM 5/6/04 +0400, Sergey Smirnov wrote:
> >Unfortunately I'm using SA with sendmail + spamass-milter.
> >I can't use common procmail filter because I have to forward messages to
> >M$ Exchange and store copy of message locally.
> >It's easy for me use sendmail aliases than ~/.procmailrc files for each
> >users.
> >Only one person don't want use SA. Of cause he is M$ sysadmin.
>
>
> With plain spamass-milter, I'm pretty sure you're not going to be able to
> fix the problem, but I'll admitt I'm not all that familar with spamass-milter.

There is one straightforward way to do this, configure your incoming
sendmail so that it will only accept -ONE- recipient per message.

Put this in your sendmail.mc file and make a new .cf file:
define(`confMAX_RCPTS_PER_MESSAGE',`1')

Or hand-edit your .cf file and add:
O MaxRecipientsPerMessage=1

This will force remote systems to send group mailings as a bunch
of seperate messages, and your sendmail + spamass-milter will
process each one seperately.

Of course, this will cost you in increased CPU/bandwidth for
multi-recipient messages but it will fix your problem.

--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
RE: all_spam_to [ In reply to ]
I had this issue as well, I ended up analyzing the allspamto
list that I had and removed a few people that got constant spam, (not
sure why they wanted to have the spam...).

Unfortunately I couldn't find anyway around it, besides just not using
it.
The bigger the allspamto list the worse it got.

Is this an addressable problem?


... Miles Mawyer -=- Webmaster . Centralva.net ...


-----Original Message-----
From: Steve Roemen [mailto:steveroemen@carlislefsp.com]
Sent: Friday, June 17, 2005 10:01 AM
To: users@spamassassin.apache.org
Subject: all_spam_to

We have an address setup that people who we reject based on spam/virus
can send a message to, to figure out why they are listed as spam. The
only problem with that is if a spammer sends a message to numerous
people, including this account, the spam is appended a score -100 and is

passed along. I am running sa version 3.0.2. Is there a way to prevent

this? Per recipient scanning when an all_spam_to is found?

Thanks,
Steve
Re: all_spam_to [ In reply to ]
Well i'm thinking about removing the all_spam_to, and having the website
that people are redirected to be a form for them to send me a message,
and analyze their email. But it would be nice if sa would check each
recipient when an all_spam_to user is detected...

Steve

on 06/17/05 09:05 Miles Mawyer wrote the following:

>I had this issue as well, I ended up analyzing the allspamto
>list that I had and removed a few people that got constant spam, (not
>sure why they wanted to have the spam...).
>
>Unfortunately I couldn't find anyway around it, besides just not using
>it.
>The bigger the allspamto list the worse it got.
>
>Is this an addressable problem?
>
>
>... Miles Mawyer -=- Webmaster . Centralva.net ...
>
>
>-----Original Message-----
>From: Steve Roemen [mailto:steveroemen@carlislefsp.com]
>Sent: Friday, June 17, 2005 10:01 AM
>To: users@spamassassin.apache.org
>Subject: all_spam_to
>
>We have an address setup that people who we reject based on spam/virus
>can send a message to, to figure out why they are listed as spam. The
>only problem with that is if a spammer sends a message to numerous
>people, including this account, the spam is appended a score -100 and is
>
>passed along. I am running sa version 3.0.2. Is there a way to prevent
>
>this? Per recipient scanning when an all_spam_to is found?
>
>Thanks,
>Steve
>
>
Re: all_spam_to [ In reply to ]
Thanks, this should do the trick.
Steve

on 06/17/05 12:37 Fred wrote the following:
One possible work around to this would be create a meta rule that fires when more than one person is listed in To or CC boxes. Using this meta rule, create another meta rule to counter the effects of having your "spam" address used to mail multiple people. Something like this: header __MYSPAM_ADD ToCc =~ /spam\@mydomain\.com/i header __MANY_RECPT ToCc =~ /(?:\@.{5,30}){4}/ meta DONT_ABUSE_SPAMTRAP (__MYSPAM_ADD && __MANY_RECPT) describe DONT_ABUSE_SPAMTRAP Please don't send e-mail to this address with multiple recpts. score DONT_ABUSE_SPAMTRAP 100 The rule __MYSPAM_ADD just checks for your spam reporting address. The rule __MANY_RECPT just checks for 4 @ signs in either To or CC. None of this is tested but it's how "I" would do it. Frederic Tarasevicius Internet Information Services, Inc. http://www.i-is.com/"]http://www.i-is.com/ 810-794-4400 Steve Roemen wrote:
We have an address setup that people who we reject based on spam/virus can send a message to, to figure out why they are listed as spam. The only problem with that is if a spammer sends a message to numerous people, including this account, the spam is appended a score -100 and is passed along. I am running sa version 3.0.2. Is there a way to prevent this? Per recipient scanning when an all_spam_to is found? Thanks, Steve
Re: all_spam_to [ In reply to ]
>On 6/3/21 6:36 AM, Benny Pedersen wrote:
>>this change score with default -100 even for spammy msgs

On 03.06.21 22:02, Grant Taylor wrote:
>This is a very critical point to me.
>
>1) it's not *all* spam. It's spam with a score of up to 100+whatever
>cut off you're using.
>2) SpamAssassin still does it's spam processing. Meaning it's not a
>way to skip spam checking for particular recipients.

however, you can shortcircuit messages matching USER_IN_ALL_SPAM_TO, so the
rest of rules is not applied:

60_shortcircuit.cf:priority USER_IN_ALL_SPAM_TO -1000

https://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_Shortcircuit.html

--
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.
Nothing is fool-proof to a talented fool.
Re: all_spam_to [ In reply to ]
On 2021-06-04 08:52, Matus UHLAR - fantomas wrote:
>> On 6/3/21 6:36 AM, Benny Pedersen wrote:
>>> this change score with default -100 even for spammy msgs
>
> On 03.06.21 22:02, Grant Taylor wrote:
>> This is a very critical point to me.
>>
>> 1) it's not *all* spam. It's spam with a score of up to 100+whatever
>> cut off you're using.
>> 2) SpamAssassin still does it's spam processing. Meaning it's not a
>> way to skip spam checking for particular recipients.
>
> however, you can shortcircuit messages matching USER_IN_ALL_SPAM_TO, so
> the
> rest of rules is not applied:

this will not solve it, to solve it it need spammy msgs not to be
quarantined, but move maybe based on procmail/sieve rules to be moved
into another mailbox via lmtp or lda/mda

it would imho just be more simple to move via imap later

https://doc.dovecot.org/configuration_manual/howto/antispam_with_sieve/

https://moi.vonos.net/linux/email-sieve-spam/
Re: all_spam_to [ In reply to ]
>>>On 6/3/21 6:36 AM, Benny Pedersen wrote:
>>>>this change score with default -100 even for spammy msgs
>>
>>On 03.06.21 22:02, Grant Taylor wrote:
>>>This is a very critical point to me.
>>>
>>>1) it's not *all* spam. It's spam with a score of up to
>>>100+whatever cut off you're using.
>>>2) SpamAssassin still does it's spam processing. Meaning it's
>>>not a way to skip spam checking for particular recipients.

>On 2021-06-04 08:52, Matus UHLAR - fantomas wrote:
>>however, you can shortcircuit messages matching USER_IN_ALL_SPAM_TO, so
>>the rest of rules is not applied:

On 04.06.21 11:50, Benny Pedersen wrote:
>this will not solve it, to solve it it need spammy msgs

if they won't to be detected as spammy, they won't be handled as spammy.

--
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.
2B|!2B, that's a question!