Re: spamd fails to restart on SIGHUP?

[Per Jessen]

Justin Mason wrote:
> Per Jessen writes:
>> Per Jessen wrote:
>>
>>> I have seen this once or twice, but still very rarely - spamd will
>>> fail to restart after receiving a SIGHUP.  It stops, but does not
>>> restart. There's nothing in the log to indicate why.  Has anyone seen
>>> the same? 
>> OK, this happened yesterday and now just again.  Any suggestions on how
>> to debug it?  
> 
> "strace -f -p $pid" may help.

Hmm, I could add that to the reload procedure.  I think.


thanks
Per

Re: Blacklist problems!

[John D. Hardin]

On Wed, 22 Aug 2007, maillist wrote:

*PLEASE* prune your replies.

> You may want to try to turn off bayes_auto_learn or just turn off
> bayes all together.  Maybe your bayes have become corrupt.

How would bayes cause the USER_IN_BLACKLIST rule to fire?

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  End users want eye candy and the "ooo's and hhh's" experience
  when reading mail. To them email isn't a tool, but an entertainment
  form. -- Steve Lake
---
 3 days until The 1928th anniversary of the destruction of Pompeii

Re: Blacklist problems!

[maillist]

Michael Chapman wrote:
Well, nothing has worked so far ... every message that I have coming 
in (except for the specifically white-listed messages from this 
mailing list) have USER_IN_BLACKLIST flagged.  Where on earth is it 
getting this?  You've seen my local.cf, I don't have a user_prefs 
anymore (blew it away in hopes of resolving this.)


My head hurts.

Thanks!

Michael

Michael Chapman wrote:
Thanks ... I can certainly take care of the whitelist items.  The 
country codes are all remarked out, as I used the the ok_languages as 
you indicated.


How will changing the whitelist entries prevent my incoming mail as 
being blacklisted?


Thanks again!

Michael

I would set the following

whitelist_from_rcvd *.musiciansfriend.com  musiciansfriend.com
whitelist_from_rcvd *.apache.org  apache.org

LOOK HERE FOR MORE INFO ON THIS OPTION
http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html 



blacklist_from [EMAIL PROTECTED]
required_hits 8 rewrite_header Subject [SPAM] report_safe 1
use_bayes   1
bayes_auto_learn  0
skip_rbl_checks 0
use_razor2  1
use_pyzor   1 ok_languagesen
# Blacklist for foreign countries we don't care about getting mail from
#
#blacklist_from  *.ar
#blacklist_from  *.tr
#blacklist_from  *.cn
#blacklist_from  *.hr
#blacklist_from  *.ru
#blacklist_from  *.tw

No need for these settings if you have the above "ok_languages  en"

-=Aubrey=-

Michael Chapman wrote:
OK ... after diving back into my spam to get responses to this 
message, I turned off AWL in v310.pre and removed all blacklist 
items from local.cf and user_prefs.  Still no joy.  Everything is 
still getting flagged as before!  What is going on?


Thanks for all of your help so far, gang!

Michael

Michael Chapman wrote:
 

Hi there:

This should be a fairly simple question for the experts out there 
... everything I'm receiving is being blacklisted, and the reports 
indicate that all these messages are flagged as 
"USER_IN_BLACKLIST."  Where?  I don't have a user_prefs, and my 
global is really simple:


# These values can be overridden by editing 
~/.spamassassin/user_prefs.


cf
 

# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.
whitelist_from *.musiciansfriend.com
whitelist_from *.apache.org
blacklist_from [EMAIL PROTECTED]
required_hits 8
#report_safe 0
rewrite_header Subject [SPAM]
# SpamAssassin config file for version 3.x
# # NOTE: NOT COMPATIBLE WITH VERSIONS 2.5 or 2.6
# # See http://www.yrex.com/spam/spamconfig25.php for earlier versions
# # Generated by http://www.yrex.com/spam/spamconfig.php (version 
1.50)

#
# # How many hits before a message is considered spam.
# required_score   5.0
#
# # Encapsulate spam in an attachment (0=no, 1=yes, 2=safe)
report_safe 1
#
# # Enable the Bayes system
use_bayes   1
#
# # Enable Bayes auto-learning
bayes_auto_learn  1
#
# # Enable or disable network checks
# skip_rbl_checks 0
use_razor2  1
#use_dcc 1
use_pyzor   1
#
# # Mail using languages used in these country codes will not be 
marked

# # as being possibly spam in a foreign language.
#ok_languagesen
#
# # Mail using locales used in these country codes will not be marked
# # as being possibly spam in a foreign language.
ok_locales  en

# Blacklist for foreign countries we don't care about getting mail 
from

#
blacklist_from  *.ar
blacklist_from  *.tr
blacklist_from  *.cn
blacklist_from  *.hr
blacklist_from  *.ru
blacklist_from  *.tw
#
#


This all worked just fine when I was using RH9/SA 2.6.  This is on 
Fedora 7 with SA 3.2.2.  I am using procmail to process incoming 
mail, and using ClamAV for virus stuff.


Is there a way I can reset the blacklist?  This is driving me 
nuts.  I don't want to use all_spam_to just to get my mail!


Help!  Please?

Thanks!

Michael




  






You may want to try to turn off bayes_auto_learn or just turn off bayes 
all together.  Maybe your bayes have become corrupt.


-=Aubrey=-

Re: is it possible to setup SA in a different machine?

[Linooks]

Cool!! i will try this one,, a very big thanks!! muah! I think this will
work!


Rick Macdougall-2 wrote:
> 
> Linooks wrote:
>> I have no idea, but I think the server uses simscan to call clam and SA.
>> I
>> hope that helps..
>> 
>> 
> 
> If you are using simscan you can add
> 
> [EMAIL PROTECTED]:spam=no,clam=yes
> 
> to the /var/qmail/control/simcontrol file and then run 
> /var/qmail/bin/simscanmk.
> 
> [EMAIL PROTECTED] is the email address of the account used to send out the 
> newsletters.
> 
> Regards,
> 
> Rick
> 
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/is-it-possible-to-setup-SA-in-a-different-machine--tf4313291.html#a12282292
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: is it possible to setup SA in a different machine?

[Rick Macdougall]

Linooks wrote:

I have no idea, but I think the server uses simscan to call clam and SA. I
hope that helps..




If you are using simscan you can add

[EMAIL PROTECTED]:spam=no,clam=yes

to the /var/qmail/control/simcontrol file and then run 
/var/qmail/bin/simscanmk.


[EMAIL PROTECTED] is the email address of the account used to send out the 
newsletters.


Regards,

Rick

Re: Question - How many of you run ALL your email through SA?

[Jon Trulson]

On Mon, 20 Aug 2007, David B Funk wrote:


On Mon, 20 Aug 2007, Duane Hill wrote:


On Mon, 20 Aug 2007 at 16:24 -0600, [EMAIL PROTECTED] confabulated:


[snip..]

 I have to second that... In the early days when spammers were just
 getting started, we started using some RBL's at the MTA level.  ORBS
 was one I believe.  Then they went away and started tagging
 everything as spam, and of course we started rejecting everything.

 Lesson learned - we will not depend on any external RBL as an
 absolute pass/fail test ever again :)  We use greylisting on the
 secondary MX's, but everything goes through SA eventually before
 entering our internal mail system.  Works great.


Most blacklists I know of that have gone away in the past set DNS to
return 127.0.0.2 to ALL requests that came in. Most of the email lists I'm
on received posts by other list members with reguards to the list going
away. I would speculate that was the reason your messages started tagging
as spam.

One such list I remember was ordb.org.


ordb.orgRIP 12/31/2006
dorkslayers.com RIP  9/15/2003
osirusoft.com   RIP  8/20/2003
orbz.orgRIP  3/25/2002
orbs.orgRIP  6/3/2001

And that's just from this millenium. ;)

Returning FP to ALL requests is the fastest way to wake up brain-damaged
sites that don't get the clue.


  ordb.org, osirusoft.com, orbs.org - those were ones we used IIRC.
  Guess we didn't have a clue then.  As mentioned earlier, for our
  setup anyway, it is unwise to pin pass/fail on RBL's.  They can be
  wrong, or go away.


--
Jon Trulson
mailto:[EMAIL PROTECTED] 
#include 

"No Kill I" -Horta

Re: Question - How many of you run ALL your email through SA?

[Jon Trulson]

On Mon, 20 Aug 2007, Duane Hill wrote:


On Mon, 20 Aug 2007 at 16:24 -0600, [EMAIL PROTECTED] confabulated:


On Fri, 17 Aug 2007, Eric A. Hall wrote:



On 8/16/2007 12:39 PM, Marc Perkel wrote:

OK - it's interesting that of all of you who responded this is the only
person who is doing it right. I have to say that I'm somewhat surprised

[...]


Most blacklists I know of that have gone away in the past set DNS to return 
127.0.0.2 to ALL requests that came in. Most of the email lists I'm on 
received posts by other list members with reguards to the list going away. I 
would speculate that was the reason your messages started tagging as spam.


One such list I remember was ordb.org.



  Yes, ordb.  Knew it was something like that.  It may be true that
  they posted something to a list - unfortunately, I was not
  subscribed.

  Nonetheless, we won't do that again.

--
Jon Trulson
mailto:[EMAIL PROTECTED] 
#include 

"No Kill I" -Horta

Re: is it possible to setup SA in a different machine?

[Linooks]

I have no idea, but I think the server uses simscan to call clam and SA. I
hope that helps..


John D. Hardin wrote:
> 
> On Wed, 22 Aug 2007, Linooks wrote:
> 
>> Thats also my problem, I did not set this email server..
>> 
>> How would I do what you recommend?
> 
> First question: how is SA being called? Then we can offer advice.
> 
> --
>  John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
>  [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
>  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
> ---
>   Of the twenty-two civilizations that have appeared in history,
>   nineteen of them collapsed when they reached the moral state the
>   United States is in now.  -- Arnold Toynbee
> ---
>  3 days until The 1928th anniversary of the destruction of Pompeii
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/is-it-possible-to-setup-SA-in-a-different-machine--tf4313291.html#a12281399
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: is it possible to setup SA in a different machine?

[John D. Hardin]

On Wed, 22 Aug 2007, Linooks wrote:

> Thats also my problem, I did not set this email server..
> 
> How would I do what you recommend?

First question: how is SA being called? Then we can offer advice.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Of the twenty-two civilizations that have appeared in history,
  nineteen of them collapsed when they reached the moral state the
  United States is in now.  -- Arnold Toynbee
---
 3 days until The 1928th anniversary of the destruction of Pompeii

Re: is it possible to setup SA in a different machine?

[Linooks]

Thats also my problem, I did not set this email server..

How would I do what you recommend?

Thanks,


Ralf Hildebrandt wrote:
> 
> * Linooks <[EMAIL PROTECTED]>:
>> 
>> Hi,
>> 
>> Im using qmail,vpopmail,clamav,and SA 3.0.1 under RHEL4
>> 
>> We send newsletters frequently so I really understand that it will cost a
>> lot of cpu usage.
> 
> Why would it? Can't you inject the newsletter in such a way that it
> circumvents SA & clamav?
> 
> -- 
> Ralf Hildebrandt (i.A. des IT-Zentrums)
> [EMAIL PROTECTED]
> Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450
> 570-155
> Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450
> 570-962
> IT-Zentrum Standort CBFsend no mail to
> [EMAIL PROTECTED]
> 
> 

-- 
View this message in context: 
http://www.nabble.com/is-it-possible-to-setup-SA-in-a-different-machine--tf4313291.html#a12281136
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: is it possible to setup SA in a different machine?

[Ralf Hildebrandt]

* Linooks <[EMAIL PROTECTED]>:
> 
> Hi,
> 
> Im using qmail,vpopmail,clamav,and SA 3.0.1 under RHEL4
> 
> We send newsletters frequently so I really understand that it will cost a
> lot of cpu usage.

Why would it? Can't you inject the newsletter in such a way that it
circumvents SA & clamav?

-- 
Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBFsend no mail to [EMAIL PROTECTED]

Re: is it possible to setup SA in a different machine?

[Linooks]

So sir, I can just setup an updated verision of SA in a different server and
configure it to scan remote servers? can u please send a link how to that..
Im not that good yet..:working:

Linooks wrote:
> 
> Hi,
> 
> Im using qmail,vpopmail,clamav,and SA 3.0.1 under RHEL4
> 
> We send newsletters frequently so I really understand that it will cost a
> lot of cpu usage. I was thinking if I can setup the SA into a different
> machine, not with the email server. So I can gain more cpu usage. when it
> goes to 99 to 100 I can send and receive emails! can SA be setup like
> that? SA will scan remote email servers?:-(
> 

-- 
View this message in context: 
http://www.nabble.com/is-it-possible-to-setup-SA-in-a-different-machine--tf4313291.html#a12280664
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: is it possible to setup SA in a different machine?

[Jari Fredriksson]

> Hi,
> 
> Im using qmail,vpopmail,clamav,and SA 3.0.1 under RHEL4
> 
> We send newsletters frequently so I really understand
> that it will cost a lot of cpu usage. I was thinking if I
> can setup the SA into a different machine, not with the
> email server. So I can gain more cpu usage. when it goes
> to 99 to 100 I can send and receive emails! can SA be
> setup like that? SA will scan remote email servers?:-( 

If you use spamc to invoke SA, you can tell a spamd server to it using -d 
option.

You can even have several spamd servers, as long as the server name assingned 
with -d option resolves to those several servers.

Re: Email forwarding and RBL trouble

[John D. Hardin]

On Wed, 22 Aug 2007, Rense Buijen wrote:

> I didn't know that a backup MX can lead to more trouble then
> having just one, gee, I thought it was a good thing but it turned
> out to be a quite bad one :)

It *is* a good idea. You just can't cheap out on configuring it. 

Ideally, your backup MXs should be configured with all the same
capabilities as your primary MX - username authentication, SA,
antivirus, RBLs, etc. - or they become an exploitable back door and a
nuisance to the rest of the world.

Spammers routinely target backup MXs first to try to take advantage of
this.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  People seem to have this obsession with objects and tools as being
  dangerous in and of themselves, as though a weapon will act of its
  own accord to cause harm. A weapon is just a force multiplier. It's
  *humans* that are (or are not) dangerous.
---
 3 days until The 1928th anniversary of the destruction of Pompeii

is it possible to setup SA in a different machine?

[Linooks]

Hi,

Im using qmail,vpopmail,clamav,and SA 3.0.1 under RHEL4

We send newsletters frequently so I really understand that it will cost a
lot of cpu usage. I was thinking if I can setup the SA into a different
machine, not with the email server. So I can gain more cpu usage. when it
goes to 99 to 100 I can send and receive emails! can SA be setup like that?
SA will scan remote email servers?:-(
-- 
View this message in context: 
http://www.nabble.com/is-it-possible-to-setup-SA-in-a-different-machine--tf4313291.html#a12280335
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Suggested botnet rule scores

[Nix]

On 22 Aug 2007, John Rudd spake thusly:

> Nix wrote:
>> My ISP doesn't give me that option (well, OK, it probably gives *me*
>> that option because I can bug the ISP's technical director, but not
>> people who've posted bonds). I'd venture to guess that the vast majority of
>> small business UK ISPs, even those that do not provide useful outbound 
>> relaying
>> MTAs, do not delegate rDNS to individual users.
>
> And they can't set one of the MX records, or A records, for their mail domain 
> to be the same as that of the static IP address their
> static IP address?
>
> Because EITHER one of those things will trigger an exception for Botnet.

Oh, right, so botnot only triggers if you're sending from something
that isn't an MX *and* satisfies one of the other criteria?

That's sensible, and I hadn't thought of it, and I'd also brilliantly
managed to overlook it repeatedly when wandering through the botnet
code. (God knows how. Insufficient coffee, probably.)


There are sometimes reasons for a host without an MX to send mail, but
it's bloody rare outside of big clusters (i.e. not boxes fronting for
little networks), and I can see no reason why anyone can't get a low-
priority MX pointing at them even if they can't run an MTA on it (no
harm will be done in that case, of course).

Re: Email forwarding and RBL trouble

[Aaron Wolfe]

On 8/22/07, Rense Buijen <[EMAIL PROTECTED]> wrote:
>
> Thanks a lot all, it's all clear to me now!
> I though that the trusted networks mean that the message will just be
> passed it it came from that source.
> I didnt know it will skip to the next "Received" IP. Thanks a lot.
>
> One question about the "backscatter" problem though, if I understand
> correctly it is always my Exchange server (the machine inline with SA)
> who will send out "user does not exist" messages, right? The backup MX
> will merely try to forward it and the Exchange server decides if that
> mail address exists or not. I think Exchange is configured the right way
> in such a way that it knows what users it has on the system..


Older Exchange servers will accept any message to a domain they are
responsible for, and then generate a new NDR message to the "sender" if the
user does not exist.  This is pretty retarded and leads to tons of
undeliverable NDRs clogging up your outbound queues, innocent people
gettings NDRs from spam they didn't send, etc.  At some point (I don't
remember the exact Exchange version, but definately 2003 and 2007, probably
2000) MS started allowing you to make Exchange reject mail for unknown users
during the SMTP transaction, which is a much better way to go about
things.   In your situation, that would just make your SA machine have to
send NDRs instead of your Exchange box, since it accepted the message.  This
is where you need to add recipient verification to your SA servers.  When
Exchange is in the "reject unknown" mode, that works fine and you can reject
unknowns before they enter your network at all.  This way you do not need to
mess with LDAP or expose any active directory to dmz/outside servers, and
you never have any NDR responsibility for spam.


> I would really like to drop the second mx altogether but policy forbids
> it :)



Backup MXs are a good thing, just have to configure them correctly and they
are don't require much maintenance after that.

Thanks for all the help guys!
>
> Rense
>
> Bowie Bailey wrote:
> > Rense Buijen wrote:
> >
> >> Mathhias,
> >>
> >> The problem is that when the mail enters the backup MX, we dont know
> >> if that mail is blacklisted at for instance spamcop.
> >> So if the backup mx accepts the mail (because it's dumb and it will
> >> accept it), and my primary mx (SA) has set the backup mx as trusted
> >> network/source, the mail will be delivered while it should not have
> >> been. You see the problem? SA cannot see if the mail that has been
> >> forwarded by my backup MX is valid (black/whitelisted) or not because
> >> it cannot check the IP against the RBL, it will lookup the wrong IP.
> >> And it should do this because there is NO rbl checking on the backup
> >> MX itself...
> >>
> >
> > You are making assumptions about what trusted_networks implies.  Just
> > because mail comes from a machine in your trusted_networks doesn't mean
> > that it will not be scanned.  The ONLY thing that trusted_networks means
> > is that you trust those machines to put valid header information in the
> > message.  It does NOT mean that you trust them not to forward spam.
> >
> > For your configuration, you need to put your backup MX into
> > trusted_networks in order for the RBLs to work properly.
> >
> > The real problem with this setup is that once your backup MX starts
> > forwarding messages to the primary and spam is rejected, then your
> > backup is in the bad position of having to issue a delivery notification
> > to the sender.  This is bad because most spam and viruses fake the
> > sender information.  So most of your bounces will be going to the wrong
> > person.  This is called "backscatter" and is another form of spam.  A
> > mailserver should not accept mail that it will not be able to deliver.
> >
> > I would suggest that you either configure your backup the same as your
> > primary, or just drop the backup altogether.  Without the backup, the
> > sending MTAs will still retry the message (usually for at least a couple
> > of days), so you don't lose anything unless your MX is down for an
> > extended period of time.
> >
> >
>
>
> --
> Met vriendelijke groeten,
>
> Rense Buijen
> Chess Service Management
> Tel.: 023-5149250
> Email: [EMAIL PROTECTED]
>
>

RDNS_DYNAMIC doesn't detect some hostnames

[Matus UHLAR - fantomas]

Hello,

I hoticed that even if much of dynamic ranges are detected, but there are
still some undetected.

chello.sk uses hostnames with full IP's and without delimiters, for example
chello085216200090.chello.sk, which do not match dynamic IP tests.

I wonder if someone could push such check into distribution, pure \d{12}
could be enough. Or should it be chello\d{12}\.chello\.sk ?

Any idea what do to with this? should I fill up wishlist bugreport?

-- 
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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.
Enter any 12-digit prime number to continue.

Re: Scanning mailer-daemon bounces generated by localhost

[sacoo sacoo]

On 8/22/07, Noel Jones <[EMAIL PROTECTED]> wrote:
>
> On 8/22/07, Kai Schaetzl <[EMAIL PROTECTED]> wrote:
> > It's still not clear (at least to me) what you actually want to do and
> > what happens that creates a problem.
> > You provide virus scanning, but not spam scanning? And they reject the
> > "spam" coming from you? Is that what happens?
> > Visit them and take a big club with you. It's obviously *completely*
> > unreasonable to reject that to you at MTA level. If they want to do
> their
> > own spam filtering then they ought not reject, but drop silently (or
> > whatever) on their side.


Yes, I should buy a big club I agree, but I'm afraid my boss won't let me go
there  :P

> If there is a way to stop your mailer to produce those DSNs then it is
> > Postfix-specific and has nothing to do with SA.
>
> Postfix does not subject internally generated mail to content filters.
> That would be a nice way to create loops.


Yes, maybe you are right I was thinging only to apply filtering to the mails
MAILER_DAEMON but even thought of that i can become problematic.

The best solution is administrative - tell the client they must not
> reject mail coming from your server as a condition of your service.
> Any other solution is just too messy to consider.


Ok, if I'll ask to postfix list to see if there is any way to add
filter_content the mailer_daemon messages and if it would become into a
bounce hell

Thanks anyway

--
> Noel Jones
>

RE: White list based on host Received From

[Bowie Bailey]

Dean Clapper wrote:
> Is there a way to white list based on the IP using the Received from.
> We have whitelisted our local domain but have noticed some that spoof
> our domain.  However the Received from tag is usually a different IP.
> 
> Is it good practice to whitelist using IP?

whitelist_from is a bad idea for exactly the reason you found.  Use
whitelist_from_rcvd or whitelist_from_spf instead.

-- 
Bowie

White list based on host Received From

[Dean Clapper]

Is there a way to white list based on the IP using the Received from.  We 
have whitelisted our local domain but have noticed some that spoof our 
domain.  However the Received from tag is usually a different IP.

Is it good practice to whitelist using IP?

thanks
Dean

Re: Scanning mailer-daemon bounces generated by localhost

[Noel Jones]

On 8/22/07, Kai Schaetzl <[EMAIL PROTECTED]> wrote:
> It's still not clear (at least to me) what you actually want to do and
> what happens that creates a problem.
> You provide virus scanning, but not spam scanning? And they reject the
> "spam" coming from you? Is that what happens?
> Visit them and take a big club with you. It's obviously *completely*
> unreasonable to reject that to you at MTA level. If they want to do their
> own spam filtering then they ought not reject, but drop silently (or
> whatever) on their side.
> If there is a way to stop your mailer to produce those DSNs then it is
> Postfix-specific and has nothing to do with SA.

Postfix does not subject internally generated mail to content filters.
 That would be a nice way to create loops.

The best solution is administrative - tell the client they must not
reject mail coming from your server as a condition of your service.
Any other solution is just too messy to consider.

-- 
Noel Jones

Re: Scanning mailer-daemon bounces generated by localhost

[Kai Schaetzl]

It's still not clear (at least to me) what you actually want to do and 
what happens that creates a problem.
You provide virus scanning, but not spam scanning? And they reject the 
"spam" coming from you? Is that what happens?
Visit them and take a big club with you. It's obviously *completely* 
unreasonable to reject that to you at MTA level. If they want to do their 
own spam filtering then they ought not reject, but drop silently (or 
whatever) on their side.
If there is a way to stop your mailer to produce those DSNs then it is 
Postfix-specific and has nothing to do with SA.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Re: Email forwarding and RBL trouble

[Kai Schaetzl]

Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:

> I didn't know that a backup MX can lead to more trouble then having just 
> one

Unfortunately, backup MXes attract spammers :-(. You could at least add 
some more backup MXs (that don't exist) on top of that, that may help to 
reduce the influx on the real one. And all MXes should normally behave the 
same, that is, do the same virus scanning etc.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Re: spamd fails to restart on SIGHUP?

[Justin Mason]

Per Jessen writes:
> Per Jessen wrote:
> 
> > I have seen this once or twice, but still very rarely - spamd will
> > fail to restart after receiving a SIGHUP.  It stops, but does not
> > restart. There's nothing in the log to indicate why.  Has anyone seen
> > the same? 
> 
> OK, this happened yesterday and now just again.  Any suggestions on how
> to debug it?  

"strace -f -p $pid" may help.

--j.

Re: Scanning mailer-daemon bounces generated by localhost

[sacoo sacoo]

On 8/22/07, Kevin Parris <[EMAIL PROTECTED]> wrote:
> I think it might be easier if you would simply have a conversation with
> the techy folks at your customers- invite them to configure THEIR system
> so that either everything from YOUR system is OK no matter what spam
> status it has (they can route it to bit-bucket or whatever) or turn off
> the reject-notice function on such messages, and then you won't have to
> worry about the problem.
Of course that would be the most clean approach for both, but for them
is easier to just keep rejecting the mail.
Also the mail is being rejected by and appliance called fortiguard not
the mail server directly. For that my interest in a our-side solution.

>
> Alternatively, just as a point of goofy curiosity, if they don't want
> your system doing spam filtering for them, why do they even bother
> having your system in the path for the traffic anyway?  Why not just
> point their MX record straight to their machine?

Because they are paying for the Virus scanning feature ...
>
>
> >>> "sacoo sacoo" <[EMAIL PROTECTED]> 8/22/2007 8:10:58 AM >>>
> Well, maybe I didn't explain it properly we are not providing relay for
> the outgoing mail, we are only filtering for viruses/spam the incoming
> mails and the part that are junk of them are the ones bouncing to us and
> giving problems.
>
>
>

Re: spamd fails to restart on SIGHUP?

[Per Jessen]

Per Jessen wrote:

> I have seen this once or twice, but still very rarely - spamd will
> fail to restart after receiving a SIGHUP.  It stops, but does not
> restart. There's nothing in the log to indicate why.  Has anyone seen
> the same? 

OK, this happened yesterday and now just again.  Any suggestions on how
to debug it?  


/Per Jessen, Zürich

Re: Scanning mailer-daemon bounces generated by localhost

[Kevin Parris]

I think it might be easier if you would simply have a conversation with
the techy folks at your customers- invite them to configure THEIR system
so that either everything from YOUR system is OK no matter what spam
status it has (they can route it to bit-bucket or whatever) or turn off
the reject-notice function on such messages, and then you won't have to
worry about the problem.

Alternatively, just as a point of goofy curiosity, if they don't want
your system doing spam filtering for them, why do they even bother
having your system in the path for the traffic anyway?  Why not just
point their MX record straight to their machine?


>>> "sacoo sacoo" <[EMAIL PROTECTED]> 8/22/2007 8:10:58 AM >>>
Well, maybe I didn't explain it properly we are not providing relay for
the outgoing mail, we are only filtering for viruses/spam the incoming
mails and the part that are junk of them are the ones bouncing to us and
giving problems.

Re: plugin won't load

[Mark Wendt (Contractor)]

At 10:35 AM 8/22/2007, Duane Hill wrote:

On Wed, 22 Aug 2007 at 10:21 -0400, [EMAIL PROTECTED] confabulated:


Hi all,

Having problems getting PDFInfo to load.

Basic machine info:

Sun Solaris 5.9
perl v5.8.9
spamassassin v3.2.2
PDFInfo v0.8

init.pre entry: loadplugin 
Mail::SpamAssassin::Plugin::PDFInfo /etc/mail/spamassassin/plugins 
(which is where I have the PDFInfo.pm located)


Should be:

loadplugin Mail::SpamAssassin::Plugin::PDFInfo 
/etc/mail/spamassassin/plugins/PDFInfo.pm


Okay, youse guys can dope slap me.  That worked.  I saw the line in 
PDFInfo.pm that said: loadplugin Mail::SpamAssassin::Plugin::PDFInfo 
/path/to/plugin and assumed it just required the "path" and not the 
file name to go with it.  Doh!  Thanks!




location of pdfinfo.cf: /etc/mail/spamassassin

spamassassin -D --lint goes along fine until this point:

[2845] dbg: plugin: loading 
Mail::SpamAssassin::Plugin::PDFInfo from /etc/mail/spamassassin/plugins
[2845] warn: plugin: failed to parse plugin 
/etc/mail/spamassassin/plugins: Directory 
/etc/mail/spamassassin/plugins not allowed in require at / 
usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PluginHandler.pm line 97.


All other plugins defined seem to load correctly when the 
--lint is run.


Thanks,
Mark


---
  _|_
 (_| |



Mark

Re: Scanning mailer-daemon bounces generated by localhost

[sacoo sacoo]

On 8/22/07, Justin Mason <[EMAIL PROTECTED]> wrote:
>
>
> hi --
>
> What you want is the VBounce ruleset, including in SpamAssassin 3.2.x or
> downloadable for 3.1.x here:
> http://wiki.apache.org/spamassassin/VBounceRuleset .  It's designed
> to deal with exactly what you're describing.


Yeah I saw the VBounce rules before posting, but those rules are to stop the
bounces reaching any of my servers , what I want to do is to use the default
filter set with the bounces my own server is generating cause of the spam
filters of my customers.
The mails generated by [EMAIL PROTECTED] contain the typical
string like
"I'm sorry to have to inform you that your message could not bebe delivered
to one or more recipients. It's attached below "
And then it contains the content of the rejected mail (might be spam or
not). In a sample case after doing the spamassassin -t spam.txt I get this
(21,7points) and I would drop the mail and avoid the overhead of my server
trying to deliver it to a non-existant source:

Content analysis details:   (21.7 points, 5.0 required)
I cannot post the whole result because the message gets rejected as spam :P


--j.
>
> sacoo sacoo writes:
> > Well, maybe I didn't explain it properly we are not providing relay for
> the
> > outgoing mail, we are only filtering for viruses/spam the incoming mails
> and
> > the part that are junk of them are the ones bouncing to us and giving
> > problems.
> >
> >   Relay service is a non-op in the current spam war.  If you
> > > do what you are trying to do here, then legitimate bounce messages
> > > will also be dropped and thus you'll be decreasing the quality of
> > > their service.  (and if you don't, you'll be creating backscatter)
> >
> >
> > If I achieved what I'm trying there should been that much of problem:
> > .- Only bounces generated by spammy mails would be marked as spam
> (exactly
> > the same that would have been marked using the usual antispam)
> minimalizing
> > the legitimate bounces discarded.
> > .- And these way we will minimize the backskatter we are providing
> >
> >
> > On 8/21/07, Jo Rhett <[EMAIL PROTECTED]> wrote:
> > >
> > > Really the only way to solve this properly is to stop providing relay
> > > service.  Relay service is a non-op in the current spam war.  If you
> > > do what you are trying to do here, then legitimate bounce messages
> > > will also be dropped and thus you'll be decreasing the quality of
> > > their service.  (and if you don't, you'll be creating backscatter)
> > >
> > > It's a no-win scenario.  If they do their own spam scanning, they
> > > should accept the mail directly.
> > >
> > > On Aug 21, 2007, at 8:49 AM, sacoo sacoo wrote:
> > > > It must been asked before, but I couldn't find any suitable, will
> > > > be glad if
> > > > you point me somewhere...
> > > > In our company we have the (mailer-exchange -> spam-scanner ->
> > > > customers
> > > > with their own mail servers) topology.
> > > > We relay mail to them but some of them don't have the spam service
> > > > with us
> > > > and prefer to have it on their side, then we are all the time
> > > > getting the
> > > > spam we forward rejected, our spam server generates a bounce (From:
> > > > [EMAIL PROTECTED] (Mail Delivery System)).
> > > > This bounce keeps bouncing there until expires increasing the load
> > > > of our
> > > > server.
> > > > We would like to know if there is any way to force the filtering
> > > > the mails
> > > > from [EMAIL PROTECTED]
> > > >
> > > > As far, the only guess i found was to modify the master.cf somehow
> > > > from
> > > > this:
> > > > smtp  inet  n   -   -   -   -   smtpd -o
> > > > content_filter=smtp:[127.0.0.1]:10024
> > > > localhost:10025 inet   n   -   n   -   -
> > > > smtpd -o
> > > > content_filter=
> > > >
> > > > To something like this
> > > > smtp  inet  n   -   -   -   -   smtpd -o
> > > > content_filter=smtp:[127.0.0.1]:10024
> > > > localhost:25  inet  n   -   -   -   -
> > > > smtpd -o
> > > > content_filter=smtp:[127.0.0.1]:10024
> > > > localhost:10025 inet   n   -   -   -   -
> > > > smtpd -o
> > > > content_filter=smtp:[127.0.0.1]:10024
> > > >
> > > > Filtering the localhost generated mails.
> > > > But I donno if it's the right approach.
> > > >
> > > > Any help appreciated
> > > >
> > > > Cheers
> > >
> > > --
> > > Jo Rhett
> > > Net Consonance : consonant endings by net philanthropy, open source
> > > and other randomness
> > >
> > >
> > >
>

RE: Email forwarding and RBL trouble

[Bowie Bailey]

Rense Buijen wrote:
> Thanks a lot all, it's all clear to me now!
> I though that the trusted networks mean that the message will just be
> passed it it came from that source.
> I didnt know it will skip to the next "Received" IP. Thanks a lot.
> 
> One question about the "backscatter" problem though, if I understand
> correctly it is always my Exchange server (the machine inline with SA)
> who will send out "user does not exist" messages, right? The backup MX
> will merely try to forward it and the Exchange server decides if that
> mail address exists or not. I think Exchange is configured the right
> way in such a way that it knows what users it has on the system..
> 
> I would really like to drop the second mx altogether but policy
> forbids it :)

Here is an example of the backscatter problem:

1) Mail is accepted at your backup MX
2) Backup MX forwards to primary MX
3) Primary MX refuses mail (spam, virus, bad user, whatever)
4) Backup MX sends delivery notification to "From" address
5) Innocent user whose address was in the "From" field of the message
   gets the delivery notification and has to deal with it.

Imagine 500 spams with the same forged From address going to various
non-existent users on your domain.  If you accept these messages, then
your server will be responsible for sending 500 delivery notification
messages to the poor guy whose email was forged in the spam.  (and
speaking as someone who has had their email address forged in a spam
run, this is REALLY annoying)

This is what should happen:

1) Mail arrives at backup MX
2) Mail is refused (spam, virus, bad user, etc)
3) It is now the responsibility of the sending server to send a delivery
   notification.

Depending on where the mail originated from, it is still possible that
the sending server is generating backscatter, but at least you are no
longer contributing to the problem.

To avoid contributing to the backscatter problem (which can get you on
some blacklists), you must ensure that all of your frontline MX servers
are capable of rejecting mail for unknown users and that they all do the
same virus/spam filtering.  The basic idea is that your frontline
servers should never accept an email that will be rejected later on.

-- 
Bowie

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Kai,

I didn't know that a backup MX can lead to more trouble then having just 
one, gee, I thought it was a good thing but it turned out to be a quite 
bad one :)
I'll go and use LDAP on the second MX to make sure the remote user 
exists, otherwise drop it silently.
It's indeed getting a bit off-topic so I'll thank everyone for their 
input, it made me a lot wiser on this issue.

And as for spamassassin... keep up the good work, I love it!

Rense

Kai Schaetzl wrote:

Rense Buijen wrote on Wed, 22 Aug 2007 16:01:09 +0200:

  
I think Exchange is configured the right way 
in such a way that it knows what users it has on the system..



But your backup MX doesn't. As you say you are taking in all mail, forward 
it to primary and then bounce it back to the sender. But your primary MX 
doesn't know the sender! Basically *all* viruses and spam come with forged 
senders. So, what you do is bounce back spam and viruses to innocent 
bystanders. This is bad, really bad!
What you should do is check on the secondary MX if a user exists and don't 
accept it if a user doesn't exist. This depends on the mail server you 
use, there are several solutions for this and it's off-topic on this list. 
And until you don't have such a solution in place do *not* send out *any* 
DSNs from your primary MX if they are for messages you got in from your 
secondary!


Kai

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: plugin won't load

[Duane Hill]

On Wed, 22 Aug 2007 at 10:21 -0400, [EMAIL PROTECTED] confabulated:


Hi all,

Having problems getting PDFInfo to load.

Basic machine info:

Sun Solaris 5.9
perl v5.8.9
spamassassin v3.2.2
PDFInfo v0.8

	init.pre entry: loadplugin Mail::SpamAssassin::Plugin::PDFInfo 
/etc/mail/spamassassin/plugins (which is where I have the PDFInfo.pm located)


Should be:

loadplugin Mail::SpamAssassin::Plugin::PDFInfo 
/etc/mail/spamassassin/plugins/PDFInfo.pm


location of pdfinfo.cf: /etc/mail/spamassassin

spamassassin -D --lint goes along fine until this point:

	[2845] dbg: plugin: loading Mail::SpamAssassin::Plugin::PDFInfo from 
/etc/mail/spamassassin/plugins
	[2845] warn: plugin: failed to parse plugin 
/etc/mail/spamassassin/plugins: Directory /etc/mail/spamassassin/plugins not 
allowed in require at / 
usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PluginHandler.pm line 
97.


	All other plugins defined seem to load correctly when the --lint is 
run.


Thanks,
Mark


---
  _|_
 (_| |

Re: Email forwarding and RBL trouble

[Kai Schaetzl]

Rense Buijen wrote on Wed, 22 Aug 2007 16:01:09 +0200:

> I think Exchange is configured the right way 
> in such a way that it knows what users it has on the system..

But your backup MX doesn't. As you say you are taking in all mail, forward 
it to primary and then bounce it back to the sender. But your primary MX 
doesn't know the sender! Basically *all* viruses and spam come with forged 
senders. So, what you do is bounce back spam and viruses to innocent 
bystanders. This is bad, really bad!
What you should do is check on the secondary MX if a user exists and don't 
accept it if a user doesn't exist. This depends on the mail server you 
use, there are several solutions for this and it's off-topic on this list. 
And until you don't have such a solution in place do *not* send out *any* 
DSNs from your primary MX if they are for messages you got in from your 
secondary!

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

plugin won't load

[Mark Wendt (Contractor)]

Hi all,

Having problems getting PDFInfo to load.

Basic machine info:

Sun Solaris 5.9
perl v5.8.9
spamassassin v3.2.2
PDFInfo v0.8

	init.pre entry: loadplugin Mail::SpamAssassin::Plugin::PDFInfo 
/etc/mail/spamassassin/plugins (which is where I have the PDFInfo.pm located)


location of pdfinfo.cf: /etc/mail/spamassassin

spamassassin -D --lint goes along fine until this point:

	[2845] dbg: plugin: loading Mail::SpamAssassin::Plugin::PDFInfo from 
/etc/mail/spamassassin/plugins
	[2845] warn: plugin: failed to parse plugin 
/etc/mail/spamassassin/plugins: Directory 
/etc/mail/spamassassin/plugins not allowed in require at / 
usr/local/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PluginHandler.pm line 97.


All other plugins defined seem to load correctly when the --lint is run.

Thanks,
Mark

RE: How do I temporarily disable SpamAssassin?

[peter]

Thanks again to everybody who responded, and steered me in the right direction. 
 

I'm very close to getting John Simpson's validrcptto qmail patch described at 
http://qmail.jms1.net/patches/validrcptto.cdb.shtml in place on the mailhub 
machine to prevent passing Rumpelstiltskin problem e-mail messages to the 
machine on which physical mailboxes and e-mail aliases are located.

--

At 10:23 AM 8/20/2007, Gary V wrote:
>>http://marc.info/?l=qmail&m=118749326201041
>>
>>I feel for Peter, it appears the qmail list is not much help either.
>
>But I do see as things develop that there is hope.
>
>Gary V
>
>_
>See what you’re getting into…before you go there 
>http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507
>
>

Re: Email forwarding and RBL trouble

[Rense Buijen]

Thanks a lot all, it's all clear to me now!
I though that the trusted networks mean that the message will just be 
passed it it came from that source.

I didnt know it will skip to the next "Received" IP. Thanks a lot.

One question about the "backscatter" problem though, if I understand 
correctly it is always my Exchange server (the machine inline with SA) 
who will send out "user does not exist" messages, right? The backup MX 
will merely try to forward it and the Exchange server decides if that 
mail address exists or not. I think Exchange is configured the right way 
in such a way that it knows what users it has on the system..


I would really like to drop the second mx altogether but policy forbids 
it :)


Thanks for all the help guys!

Rense

Bowie Bailey wrote:

Rense Buijen wrote:
  

Mathhias,

The problem is that when the mail enters the backup MX, we dont know
if that mail is blacklisted at for instance spamcop.
So if the backup mx accepts the mail (because it's dumb and it will
accept it), and my primary mx (SA) has set the backup mx as trusted
network/source, the mail will be delivered while it should not have
been. You see the problem? SA cannot see if the mail that has been
forwarded by my backup MX is valid (black/whitelisted) or not because
it cannot check the IP against the RBL, it will lookup the wrong IP.
And it should do this because there is NO rbl checking on the backup
MX itself... 



You are making assumptions about what trusted_networks implies.  Just
because mail comes from a machine in your trusted_networks doesn't mean
that it will not be scanned.  The ONLY thing that trusted_networks means
is that you trust those machines to put valid header information in the
message.  It does NOT mean that you trust them not to forward spam.

For your configuration, you need to put your backup MX into
trusted_networks in order for the RBLs to work properly.

The real problem with this setup is that once your backup MX starts
forwarding messages to the primary and spam is rejected, then your
backup is in the bad position of having to issue a delivery notification
to the sender.  This is bad because most spam and viruses fake the
sender information.  So most of your bounces will be going to the wrong
person.  This is called "backscatter" and is another form of spam.  A
mailserver should not accept mail that it will not be able to deliver.

I would suggest that you either configure your backup the same as your
primary, or just drop the backup altogether.  Without the backup, the
sending MTAs will still retry the message (usually for at least a couple
of days), so you don't lose anything unless your MX is down for an
extended period of time.

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: dropping spam

[John D. Hardin]

On Wed, 22 Aug 2007, Euroka wrote:

> For some users I do have to send all incoming mail for
> [EMAIL PROTECTED] to another mailserver [EMAIL PROTECTED] by using
> the /etc/postfix/virtual file.

That bypasses local delivery.

> So how can I delete all SPAM immediately before it's being
> forwarded to [EMAIL PROTECTED]

In the .procmailrc file for each user you are forwarding, end it with:

  :0
  ! [EMAIL PROTECTED]

In other words, tell procmail to forward the mail rather than telling 
postfix to forward the mail.

I'll let others discuss whether discarding spam in the first place is 
a good idea... :)

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  It's easy to be noble with other people's money.
   -- John McKay, _The Welfare State:
  No Mercy for the Middle Class_
---
 3 days until The 1928th anniversary of the destruction of Pompeii

RE: Email forwarding and RBL trouble

[Bowie Bailey]

Rense Buijen wrote:
> Mathhias,
> 
> The problem is that when the mail enters the backup MX, we dont know
> if that mail is blacklisted at for instance spamcop.
> So if the backup mx accepts the mail (because it's dumb and it will
> accept it), and my primary mx (SA) has set the backup mx as trusted
> network/source, the mail will be delivered while it should not have
> been. You see the problem? SA cannot see if the mail that has been
> forwarded by my backup MX is valid (black/whitelisted) or not because
> it cannot check the IP against the RBL, it will lookup the wrong IP.
> And it should do this because there is NO rbl checking on the backup
> MX itself... 

You are making assumptions about what trusted_networks implies.  Just
because mail comes from a machine in your trusted_networks doesn't mean
that it will not be scanned.  The ONLY thing that trusted_networks means
is that you trust those machines to put valid header information in the
message.  It does NOT mean that you trust them not to forward spam.

For your configuration, you need to put your backup MX into
trusted_networks in order for the RBLs to work properly.

The real problem with this setup is that once your backup MX starts
forwarding messages to the primary and spam is rejected, then your
backup is in the bad position of having to issue a delivery notification
to the sender.  This is bad because most spam and viruses fake the
sender information.  So most of your bounces will be going to the wrong
person.  This is called "backscatter" and is another form of spam.  A
mailserver should not accept mail that it will not be able to deliver.

I would suggest that you either configure your backup the same as your
primary, or just drop the backup altogether.  Without the backup, the
sending MTAs will still retry the message (usually for at least a couple
of days), so you don't lose anything unless your MX is down for an
extended period of time.

-- 
Bowie

Re: Email forwarding and RBL trouble

[Ben O'Hara]

Thats the one

Ben

On 8/22/07, Rense Buijen <[EMAIL PROTECTED]> wrote:
>
> ...thats it? So it will skip the IP of the second MX and do an RBL check
> against the IP who'm delivered it to the second MX? COOL! I thought it
> would just ignore everything and pass on the mail Thanks!
>
> Ben O'Hara wrote:
> > On 8/22/07, *Rense Buijen* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hi Pawel,
> >
> > I dont think I can check the recipient,  if it doesnt exist the
> > mailserver should send a normal bounce like every mailserver does,
> > right? So does the primary machine (Exchange)  I dont see a
> > problem with
> > that.
> >
> > Do you know if there is another good setup without having to sync
> > all my
> > antispam stuff to my second MX? I would really just use forwarding
> if
> > that is possible. Can I not rewrite the last "Received" header? That
> > should work maybe?
> >
> >
> >
> > You dont have to, add your secondary mx to trusted_networks on the
> > primary and it will know the fact to do the RBL lookups on the host
> > that sent the mail to  the secondary MX rather than the secondary mx
> > itself.
> >
> > Ben
> >
> > Kind regards,
> >
> > Rense
> >
> > Pawel Sasin wrote:
> > > Hi
> > >> I cannot utilize the trusted_networks settings because I cannot
> > trust
> > >> the mail that my backup MX sends to me.
> > >>
> > >> The backup MX does NO filtering at all, it just accepts ALL
> > mail that
> > >> has a certain destination domain and then forwards it to the
> > Primary
> > >> MX where SA is running, SA is doing all the filtering and
> > >> white/black/grey-listing.
> > >>
> > >> When SA is down (the Pri MX), it will just hold it until it
> > gets back
> > >> up. So basically all mail that comes from my second MX should be
> > >> checked for spam and virus, it has not capabilities of it's
> > own. It's
> > >> working like a charm were it not for my black/white/grey-lists
> and
> > >> the RBL's now all do lookups on the last known IP which is my
> > >> secondary MX.
> > >>
> > >> I don't think I am the first to utilize this method of
> > redundancy so
> > >> I figured there must be a way, I just dont know how :)
> > >> So please advice further, your (and everyones) help is greatly
> > >> appreciated.
> > >
> > > SA checks all 'Received' headers against RBLs.
> > >
> > > If you add secondary MX to trusted_networks, SA will just skip the
> > > header from your exim and continue with the rest.
> > >
> > > But there is another problem with such config:
> > > 1. see the numbers here http://nolisting.org/
> > > 2. does your dumb exim (secondary mx) check if the recipent
> address
> > > exists?
> > >
> > > If not you will end up sending tons of bounce messages to innocent
> > > people from your secondary MX. Even if it does, your primary MX
> can
> > > refuse a spammy message and then you will be generating even more
> > > bounce messages. This is not acceptable and you will end up in
> some
> > > RBLs yourself.
> > >
> >
> >
> > --
> > Met vriendelijke groeten,
> >
> > Rense Buijen
> > Chess Service Management
> > Tel.: 023-5149250
> > Email: [EMAIL PROTECTED] 
> >
> >
> >
> >
> > --
> > "A Scientist will earn a living by taking a really difficult problem
> > and spends many years solving it, an engineer earns a living by
> > finding really difficult problems and side stepping them"
>
>
> --
> Met vriendelijke groeten,
>
> Rense Buijen
> Chess Service Management
> Tel.: 023-5149250
> Email: [EMAIL PROTECTED]
>
>


-- 
"A Scientist will earn a living by taking a really difficult problem and
spends many years solving it, an engineer earns a living by finding really
difficult problems and side stepping them"

Re: Email forwarding and RBL trouble

[Rense Buijen]

Mathhias,

The problem is that when the mail enters the backup MX, we dont know if 
that mail is blacklisted at for instance spamcop.
So if the backup mx accepts the mail (because it's dumb and it will 
accept it), and my primary mx (SA) has set the backup mx as trusted 
network/source, the mail will be delivered while it should not have 
been. You see the problem? SA cannot see if the mail that has been 
forwarded by my backup MX is valid (black/whitelisted) or not because it 
cannot check the IP against the RBL, it will lookup the wrong IP. And it 
should do this because there is NO rbl checking on the backup MX itself...


Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust
the mail that my backup MX sends to me.



But your backup MX is "trusted" in the sense that it will not forge
sender addresses, Received: lines etc. -- that's what trusted_networks
basically implies.

If trusted_networks etc are set correctly, SA will recognize your backup
MX, and will not apply any RBL checks to it's IP address. The
Mail::SpamAssassin::Conf man-page has all the dirty details, including
those of internal_networks

  

The backup MX does NO filtering at all, it just accepts ALL mail that
has a certain destination domain and then forwards it to the Primary MX
where SA is running, SA is doing all the filtering and
white/black/grey-listing.



You should ensure that connections from your backup MX are not
grey/blacklisted at the MTA level (don't know whether you're already
doing it, but just to mention it...).

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzDfTxbHw2nyi/okRAq7jAKCbKv8IknFw2Nmse3l3LTszN7OyYgCfY28l
XAA+s+kES1B4mbmcvK2VE24=
=95OW
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Pawel,

I dont think I can check the recipient,  if it doesnt exist the 
mailserver should send a normal bounce like every mailserver does, 
right? So does the primary machine (Exchange)  I dont see a problem with 
that.


Do you know if there is another good setup without having to sync all my 
antispam stuff to my second MX? I would really just use forwarding if 
that is possible. Can I not rewrite the last "Received" header? That 
should work maybe?


Kind regards,

Rense

Pawel Sasin wrote:

Hi
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary 
MX where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be 
checked for spam and virus, it has not capabilities of it's own. It's 
working like a charm were it not for my black/white/grey-lists and 
the RBL's now all do lookups on the last known IP which is my 
secondary MX.


I don't think I am the first to utilize this method of redundancy so 
I figured there must be a way, I just dont know how :)
So please advice further, your (and everyones) help is greatly 
appreciated.


SA checks all 'Received' headers against RBLs.

If you add secondary MX to trusted_networks, SA will just skip the 
header from your exim and continue with the rest.


But there is another problem with such config:
1. see the numbers here http://nolisting.org/
2. does your dumb exim (secondary mx) check if the recipent address 
exists?


If not you will end up sending tons of bounce messages to innocent 
people from your secondary MX. Even if it does, your primary MX can 
refuse a spammy message and then you will be generating even more 
bounce messages. This is not acceptable and you will end up in some 
RBLs yourself.





--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

> Thank you for your (quick) reply.
> I cannot utilize the trusted_networks settings because I cannot trust
> the mail that my backup MX sends to me.

But your backup MX is "trusted" in the sense that it will not forge
sender addresses, Received: lines etc. -- that's what trusted_networks
basically implies.

If trusted_networks etc are set correctly, SA will recognize your backup
MX, and will not apply any RBL checks to it's IP address. The
Mail::SpamAssassin::Conf man-page has all the dirty details, including
those of internal_networks

> The backup MX does NO filtering at all, it just accepts ALL mail that
> has a certain destination domain and then forwards it to the Primary MX
> where SA is running, SA is doing all the filtering and
> white/black/grey-listing.

You should ensure that connections from your backup MX are not
grey/blacklisted at the MTA level (don't know whether you're already
doing it, but just to mention it...).

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzDfTxbHw2nyi/okRAq7jAKCbKv8IknFw2Nmse3l3LTszN7OyYgCfY28l
XAA+s+kES1B4mbmcvK2VE24=
=95OW
-END PGP SIGNATURE-

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Matthias,

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary MX 
where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be checked 
for spam and virus, it has not capabilities of it's own. It's working 
like a charm were it not for my black/white/grey-lists and the RBL's now 
all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)

So please advice further, your (and everyones) help is greatly appreciated.

Kind regards,

Rense

Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

The problem now lies with the RBL's, when the SA box dies, the mail will
be queued on my Exim box and when service is restored, it will forward
it again BUT the last "Received from:" path will be of course the Exim
host IP. SA will then do a lookup on the wrong IP. Basically I want my
Exim box (second mx) to be invisible or need the headers to be rewritten
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.



trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

  

I've heard about SRS, I don't know precisely if that will do the trick
for me, anyone has some more information, tips or tricks? It's rather
complex matter and I can't find any good documentation on how to solve
this problem.



SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Pawel Sasin]

Hi
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary 
MX where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be 
checked for spam and virus, it has not capabilities of it's own. It's 
working like a charm were it not for my black/white/grey-lists and the 
RBL's now all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)
So please advice further, your (and everyones) help is greatly 
appreciated.


SA checks all 'Received' headers against RBLs.

If you add secondary MX to trusted_networks, SA will just skip the 
header from your exim and continue with the rest.


But there is another problem with such config:
1. see the numbers here http://nolisting.org/
2. does your dumb exim (secondary mx) check if the recipent address exists?

If not you will end up sending tons of bounce messages to innocent 
people from your secondary MX. Even if it does, your primary MX can 
refuse a spammy message and then you will be generating even more bounce 
messages. This is not acceptable and you will end up in some RBLs yourself.


--
p.

WIRTUALNA  POLSKA  SA, ul. Traugutta 115c, 80-226 Gdansk; NIP: 957-07-51-216; 
Sad Rejonowy Gdansk-Polnoc KRS 068548, kapital zakladowy 62.880.024 zlotych (w calosci wplacony)

Re: Email forwarding and RBL trouble

[Rense Buijen]

Hi Matthias,

Thank you for your (quick) reply.
I cannot utilize the trusted_networks settings because I cannot trust 
the mail that my backup MX sends to me.


The backup MX does NO filtering at all, it just accepts ALL mail that 
has a certain destination domain and then forwards it to the Primary MX 
where SA is running, SA is doing all the filtering and 
white/black/grey-listing.


When SA is down (the Pri MX), it will just hold it until it gets back 
up. So basically all mail that comes from my second MX should be checked 
for spam and virus, it has not capabilities of it's own. It's working 
like a charm were it not for my black/white/grey-lists and the RBL's now 
all do lookups on the last known IP which is my secondary MX.


I don't think I am the first to utilize this method of redundancy so I 
figured there must be a way, I just dont know how :)

So please advice further, your (and everyones) help is greatly appreciated.

Kind regards,

Rense

Matthias Leisi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

  

The problem now lies with the RBL's, when the SA box dies, the mail will
be queued on my Exim box and when service is restored, it will forward
it again BUT the last "Received from:" path will be of course the Exim
host IP. SA will then do a lookup on the wrong IP. Basically I want my
Exim box (second mx) to be invisible or need the headers to be rewritten
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.



trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

  

I've heard about SRS, I don't know precisely if that will do the trick
for me, anyone has some more information, tips or tricks? It's rather
complex matter and I can't find any good documentation on how to solve
this problem.



SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

  



--
Met vriendelijke groeten,

Rense Buijen
Chess Service Management
Tel.: 023-5149250
Email: [EMAIL PROTECTED]

Re: Email forwarding and RBL trouble

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Rense Buijen schrieb:

> The problem now lies with the RBL's, when the SA box dies, the mail will
> be queued on my Exim box and when service is restored, it will forward
> it again BUT the last "Received from:" path will be of course the Exim
> host IP. SA will then do a lookup on the wrong IP. Basically I want my
> Exim box (second mx) to be invisible or need the headers to be rewritten
> so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.

trusted_networks, internal_networks etc. will make sure that your "main"
SA correctly recognises your backup box as trustworthy.

> I've heard about SRS, I don't know precisely if that will do the trick
> for me, anyone has some more information, tips or tricks? It's rather
> complex matter and I can't find any good documentation on how to solve
> this problem.

SRS is a completely different beast (basically it fixes forwarding which
is partially broken by SPF). As long as you only have troubles with IP
addresses, SRS would not solve any issue for you.

- -- Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFGzC5uxbHw2nyi/okRAgtsAJ9kyqrwaZ0waBswmcuV0jsO3HWbUACggovQ
7DPNJbxhSleg+Dkbvh66qd0=
=gIn9
-END PGP SIGNATURE-

Re: Scanning mailer-daemon bounces generated by localhost

[Justin Mason]

hi --

What you want is the VBounce ruleset, including in SpamAssassin 3.2.x or
downloadable for 3.1.x here:
http://wiki.apache.org/spamassassin/VBounceRuleset .  It's designed
to deal with exactly what you're describing.

--j.

sacoo sacoo writes:
> Well, maybe I didn't explain it properly we are not providing relay for the
> outgoing mail, we are only filtering for viruses/spam the incoming mails and
> the part that are junk of them are the ones bouncing to us and giving
> problems.
> 
>   Relay service is a non-op in the current spam war.  If you
> > do what you are trying to do here, then legitimate bounce messages
> > will also be dropped and thus you'll be decreasing the quality of
> > their service.  (and if you don't, you'll be creating backscatter)
> 
> 
> If I achieved what I'm trying there should been that much of problem:
> .- Only bounces generated by spammy mails would be marked as spam (exactly
> the same that would have been marked using the usual antispam) minimalizing
> the legitimate bounces discarded.
> .- And these way we will minimize the backskatter we are providing
> 
> 
> On 8/21/07, Jo Rhett <[EMAIL PROTECTED]> wrote:
> >
> > Really the only way to solve this properly is to stop providing relay
> > service.  Relay service is a non-op in the current spam war.  If you
> > do what you are trying to do here, then legitimate bounce messages
> > will also be dropped and thus you'll be decreasing the quality of
> > their service.  (and if you don't, you'll be creating backscatter)
> >
> > It's a no-win scenario.  If they do their own spam scanning, they
> > should accept the mail directly.
> >
> > On Aug 21, 2007, at 8:49 AM, sacoo sacoo wrote:
> > > It must been asked before, but I couldn't find any suitable, will
> > > be glad if
> > > you point me somewhere...
> > > In our company we have the (mailer-exchange -> spam-scanner ->
> > > customers
> > > with their own mail servers) topology.
> > > We relay mail to them but some of them don't have the spam service
> > > with us
> > > and prefer to have it on their side, then we are all the time
> > > getting the
> > > spam we forward rejected, our spam server generates a bounce (From:
> > > [EMAIL PROTECTED] (Mail Delivery System)).
> > > This bounce keeps bouncing there until expires increasing the load
> > > of our
> > > server.
> > > We would like to know if there is any way to force the filtering
> > > the mails
> > > from [EMAIL PROTECTED]
> > >
> > > As far, the only guess i found was to modify the master.cf somehow
> > > from
> > > this:
> > > smtp  inet  n   -   -   -   -   smtpd -o
> > > content_filter=smtp:[127.0.0.1]:10024
> > > localhost:10025 inet   n   -   n   -   -
> > > smtpd -o
> > > content_filter=
> > >
> > > To something like this
> > > smtp  inet  n   -   -   -   -   smtpd -o
> > > content_filter=smtp:[127.0.0.1]:10024
> > > localhost:25  inet  n   -   -   -   -
> > > smtpd -o
> > > content_filter=smtp:[127.0.0.1]:10024
> > > localhost:10025 inet   n   -   -   -   -
> > > smtpd -o
> > > content_filter=smtp:[127.0.0.1]:10024
> > >
> > > Filtering the localhost generated mails.
> > > But I donno if it's the right approach.
> > >
> > > Any help appreciated
> > >
> > > Cheers
> >
> > --
> > Jo Rhett
> > Net Consonance : consonant endings by net philanthropy, open source
> > and other randomness
> >
> >
> >

Email forwarding and RBL trouble

[Rense Buijen]

Hello all,

I have two mailservers, a primary and a secondary MX.
The primary MX is a spamassassin (3.2.3 on Ubuntu Linux) box that is 
placed inline of a MS Exchange machine.

Spamassassin is doing a good job, especialy with the RBL's I am using.
The backup MX is a simple EXIM which does only forwarding (to the 
spamassassin box) without any spam control.


This setup should be simple yet effective, if the Pri MX dies, the 
forwarder will hold all the mail and wait until the SA box is back up 
and then send the queued mail to it. It will then be filtered again, 
that way I dont have to sync whitelists, greylist databases and all my 
rules to the second MX.


The problem now lies with the RBL's, when the SA box dies, the mail will 
be queued on my Exim box and when service is restored, it will forward 
it again BUT the last "Received from:" path will be of course the Exim 
host IP. SA will then do a lookup on the wrong IP. Basically I want my 
Exim box (second mx) to be invisible or need the headers to be rewritten 
so Spamassassin does a correct lookup on the IP BEFORE it got to the SA.


I've heard about SRS, I don't know precisely if that will do the trick 
for me, anyone has some more information, tips or tricks? It's rather 
complex matter and I can't find any good documentation on how to solve 
this problem.


Kind regards,

Rense

Re: Scanning mailer-daemon bounces generated by localhost

[sacoo sacoo]

Well, maybe I didn't explain it properly we are not providing relay for the
outgoing mail, we are only filtering for viruses/spam the incoming mails and
the part that are junk of them are the ones bouncing to us and giving
problems.

  Relay service is a non-op in the current spam war.  If you
> do what you are trying to do here, then legitimate bounce messages
> will also be dropped and thus you'll be decreasing the quality of
> their service.  (and if you don't, you'll be creating backscatter)


If I achieved what I'm trying there should been that much of problem:
.- Only bounces generated by spammy mails would be marked as spam (exactly
the same that would have been marked using the usual antispam) minimalizing
the legitimate bounces discarded.
.- And these way we will minimize the backskatter we are providing


On 8/21/07, Jo Rhett <[EMAIL PROTECTED]> wrote:
>
> Really the only way to solve this properly is to stop providing relay
> service.  Relay service is a non-op in the current spam war.  If you
> do what you are trying to do here, then legitimate bounce messages
> will also be dropped and thus you'll be decreasing the quality of
> their service.  (and if you don't, you'll be creating backscatter)
>
> It's a no-win scenario.  If they do their own spam scanning, they
> should accept the mail directly.
>
> On Aug 21, 2007, at 8:49 AM, sacoo sacoo wrote:
> > It must been asked before, but I couldn't find any suitable, will
> > be glad if
> > you point me somewhere...
> > In our company we have the (mailer-exchange -> spam-scanner ->
> > customers
> > with their own mail servers) topology.
> > We relay mail to them but some of them don't have the spam service
> > with us
> > and prefer to have it on their side, then we are all the time
> > getting the
> > spam we forward rejected, our spam server generates a bounce (From:
> > [EMAIL PROTECTED] (Mail Delivery System)).
> > This bounce keeps bouncing there until expires increasing the load
> > of our
> > server.
> > We would like to know if there is any way to force the filtering
> > the mails
> > from [EMAIL PROTECTED]
> >
> > As far, the only guess i found was to modify the master.cf somehow
> > from
> > this:
> > smtp  inet  n   -   -   -   -   smtpd -o
> > content_filter=smtp:[127.0.0.1]:10024
> > localhost:10025 inet   n   -   n   -   -
> > smtpd -o
> > content_filter=
> >
> > To something like this
> > smtp  inet  n   -   -   -   -   smtpd -o
> > content_filter=smtp:[127.0.0.1]:10024
> > localhost:25  inet  n   -   -   -   -
> > smtpd -o
> > content_filter=smtp:[127.0.0.1]:10024
> > localhost:10025 inet   n   -   -   -   -
> > smtpd -o
> > content_filter=smtp:[127.0.0.1]:10024
> >
> > Filtering the localhost generated mails.
> > But I donno if it's the right approach.
> >
> > Any help appreciated
> >
> > Cheers
>
> --
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source
> and other randomness
>
>
>

Re: ham mail marked as spam

[Matt Kettler]

Sg wrote:
> Hi
>
> Suddenly my collegue mails are recieved as spam by 3.1.7 SA. I added
> to them on white list entry. Why it comes like this suddenly? any
> solution?
could be anything. Got an X-Spam-Status to provide us a clue?

Re: Need a plugin written relating to black/white/yellow lists

[Loren Wilton]

header __RCVD_IN_JMFILTER 
eval:check_rbl('JMFILTER','hostkarma.junkemailfilter.com.')

describe __RCVD_IN_JMFILTER Sender listed in JMFILTER
tflags __RCVD_IN_JMFILTER net

header RCVD_IN_JMFILTER_W eval:check_rbl_sub('JMFILTER', '127.0.0.1')
describe RCVD_IN_JMFILTER_W Sender listed in JMFILTER-WHITE
tflags RCVD_IN_JMFILTER_W net nice
score RCVD_IN_JMFILTER_W -5

header RCVD_IN_JMFILTER_B eval:check_rbl_sub('JMFILTER', '127.0.0.2')
describe RCVD_IN_JMFILTER_B Sender listed in JMFILTER-BLACK
tflags RCVD_IN_JMFILTER_B net
score RCVD_IN_JMFILTER_B 4.0

header RCVD_IN_JMFILTER_B eval:check_rbl_sub('JMFILTER', '127.0.0.4')
describe RCVD_IN_JMFILTER_B Sender listed in JMFILTER-BROWN
tflags RCVD_IN_JMFILTER_B net
score RCVD_IN_JMFILTER_B 1.0

What it needs is if it's white then we short circuit to call it ham and 
skip other tests.
The white list is very accurate and it's not hard to get a good whitelist. 
The yellow
list is also very good. The idea here is to stop all other blacklist tests 
after a yellow

list. I don't know how to do that in SA.


The first part is easy with the more recent SA releases.  Justin put in the 
short-circuit logic.  Give your while rule a high priority so that it runs 
first (which is actually a negative number).  The flag it as a short circuit 
rule, which I think is done in tflags; but I've never done it so I'm not 
positive on that.


Since its also a net rule I'm not positive that it will run all that 
firstly, because I think there is some strange interaction with delayed net 
results and when normal rules run.  But maybe the priority combined with a 
short circuit flag will hold off the normal rules until the results of this 
rule are in.  It would be worth doing it that way.


I can't think of a good way to make your yellow list or maybe even the brown 
list hold off all possible blacklists.  Probably don't want to anyway -- if 
someone has personally blacklisted host X, they probably want it 
blacklisted.


The not-so-good way is to build a meta test to back out the results of any 
blacklist hit if the yellow list is also hit.  Which isn't all that 
wonderful, since blacklists have different scores, so it will take a bunch 
of metas.


In theory the yellow list could be given a priority higher than all of the 
blacklists, and then it could short circuit at that point.  That woudl 
require assigning a relatively low priority to all the blacklist rules. 
Maybe that would be good, maybe not.  It would be a bunch of work though. 
OTOH, blacklist net rules don't change all that often, so it might be 
reasonably feasible to do.


It might be nice if there were a way to specify 'priority groups' for rules. 
This wouldn't affect the priority of the rule or the score of the rule under 
normal conditions, but you would be able to say "this short-circuit rule 
must run before rule group X".  In effect this would make the rule group an 
implicit meta on the short-circuit rule, pushing that rule ahead of the 
evaluation of the other rules.


But at least have the puzzle has a fix now.

   Loren

dropping spamHi

[Euroka]

Hello all!

Im using Postfix as MTA and use the procmailrc script in each $HOME dir   to
filter and delete spam immeditately before it get's into the user's mailbox.

For some users I do have to send all incoming mail  for [EMAIL PROTECTED] to
another mailserver [EMAIL PROTECTED] by using the /etc/postfix/virtual file.

Unfortuneately all spam intended for [EMAIL PROTECTED] also get's forwarded
to [EMAIL PROTECTED] wich makes my [EMAIL PROTECTED] suspecious as being
a spamserver for the [EMAIL PROTECTED]

So how can I delete all SPAM immediately before it's being forwarded to
[EMAIL PROTECTED]

Atm my .procmailrc looks like this:

MAILDIR=$HOME/mail
LOGFILE=$HOME/mail/log

:0:
* ^X-Spam-Status: Yes
/dev/null


SA version is pamAssassin 3.2.2 (2007-07-23)
with postfix-2.2.10-1.1.el4


Thanks for all info!

Re: Adding new header to SA

[Steve Freegard]

yossim wrote:

Hi Steve,

Thanks for the info.

However the version of MailScanner that i use does not support this
attribute.

Is there other place were i can add this header.



No - you'll have to upgrade MailScanner if you want to be able to do 
this (it isn't hard).


Kind regards,
Steve.

Re: ham mail marked as spam

[Raymond Dijkxhoorn]

Hi!


Suddenly my collegue mails are recieved as spam by 3.1.7 SA. I added to
them on white list entry. Why it comes like this suddenly? any solution?



maybe your colleague got onto blacklist?
Hard to say without seeing headers


Or is he using a image as footer, with the current SA rules you get 
pointed like crazy when you do.


Bye,
Raymond.

Re: ham mail marked as spam

[Matus UHLAR - fantomas]

On 22.08.07 11:47, Sg wrote:
> Suddenly my collegue mails are recieved as spam by 3.1.7 SA. I added to
> them on white list entry. Why it comes like this suddenly? any solution?

maybe your colleague got onto blacklist?
Hard to say without seeing headers
-- 
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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 box said 'Requires Windows 95 or better', so I bought a Macintosh".

RE: BOTNET Exceptions for Today

[Martin.Hepworth]

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of René Berber
> Sent: 22 August 2007 07:42
> To: users@spamassassin.apache.org
> Subject: Re: BOTNET Exceptions for Today
>
> John Rudd wrote:
>
> > René Berber wrote:
> >> Here's a good example of why Botnet's default score is too high, those
> >> guys at
> >> meridiencancun have a so called "Enterprise account" with their ISP,
> >> what they
> >> get is a fixed IP and no control over reverse DNS, that's why the
> reverse
> >> returns what the ISP configured.  Best practices and other fiction
> >> don't apply
> >> to the real world in cases like this.
> >
> > As for "best practices" being "fiction" that "doesn't apply to the real
> > world" ... it's rinky-dink mail servers run by people with half-assed
> > opinions like that that cause there to be such a huge number of
> > exploited mail servers on the planet.
>
> Exploited mail servers are badly configured mail servers, that's a whole
> different subject from what is being discussed.
>
> > People who think "best practices" are "fiction" are the scourge that
> > makes the internet such an unreliable place.
> >
> > Here kid, have a nickel.  Go buy yourself a real mail server.
>
> I'm not a kid, so I would appreciate some respect.  If you think I don't
> know
> what I'm talking about, that's your prerogative, you don't really know me.
> --
> René Berber


Ok here's my 2 pence worth.

Botnet 0.8 is a lot better than 0.7 - please upgrade if you don't already.

Personally I find the big meta-rule a big heavy (or did at 0.7 anyway). I run 
the rules separately which give me better results and also better visibility as 
to why botnet fired.

A lot of these "false positive" errors are down to 1) lack of education and the 
commercial mass mailers pretending to send out from the client but still 
resolving back to the mass emailer.

Here's an example of how MailScanner handles this with it's phishing net 
system. There's a big whitelist file that you can 1) add you own stuff to and 
2) download updates for (which doesn't overwrite your whitelist).

Perhaps people need to get together with John to produce some sort of botnet 
whitelist rbl for known 'good' commercial mass emailers like ems6.net?

I'll shut up now ;-)

--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300




**
Confidentiality : This e-mail and any attachments are intended for the 
addressee only and may be confidential. If they come to you in error 
you must take no action based on them, nor must you copy or show them 
to anyone. Please advise the sender by replying to this e-mail 
immediately and then delete the original from your computer.
Opinion : Any opinions expressed in this e-mail are entirely those of 
the author and unless specifically stated to the contrary, are not 
necessarily those of the author's employer.
Security Warning : Internet e-mail is not necessarily a secure 
communications medium and can be subject to data corruption. We advise 
that you consider this fact when e-mailing us. 
Viruses : We have taken steps to ensure that this e-mail and any 
attachments are free from known viruses but in keeping with good 
computing practice, you should ensure that they are virus free.

Red Lion 49 Ltd T/A Solid State Logic
Registered as a limited company in England and Wales 
(Company No:5362730)
Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, 
United Kingdom
**

Re: Adding new header to SA

[yossim]

Hi Steve,

Thanks for the info.

However the version of MailScanner that i use does not support this
attribute.

Is there other place were i can add this header.

Kindly regards,

Yossi

Steve Freegard-2 wrote:
> 
> Matt Kettler wrote:
>> yossim wrote:
>>> Hi forum, I am running MailScanner integrated with SA sendmail based.
>>> I would like to add a new header to SA report, so the next stage of
>>> spam filtering which is the trend micro will always forward the email
>>> the outlook junk mail. The header is as follows: X-TM-AS-Product-Ver:
>>> SMEX-7.0.0.1557-5.0.1021-15334.002. I searched in MailScanner and
>>> tried also in local.cf but with no results. Kindly regards, Yossi
> 
>> MailScanner doesn't offer any decent flexibility in header formats
> 
> How about:
> 
> Spam Actions = deliver header "X-TM-AS-Product-Ver: 
> SMEX-7.0.0.1557-5.0.1021-15334.002"
> 
> That should do what you need.
> 
> Kind regards,
> Steve.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Adding-new-header-to-SA-tf4299323.html#a12269303
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.