Greetings, and apologies is thisn't the right forum for this post. I've
already asked on postfix-users with no luck there.
We run postfix and SpamAssassin. Postfix's use of RBL is pre-empting SA's
ability to whitelist specific senders. I'm wondering if there is some way
to override that.
We ru
Michael,
I understood the dangers behing the theory - I'll get into the
analysis of all the bayes databases later on.
I guess the only way to do it cleanly is to feed the same HAM+SPAM
messages to all the bayes's learning mechanisms...
Thanks for your time,
Ricardo
On Sat, 4 Dec 2004, Matt Kettler wrote:
> At 08:04 PM 12/3/2004 -0600, Thomas Cameron wrote:
> >
> >The thing I've noticed on all of the ones which get through is that
> >ALL_TRUSTED is one of the tests listed.
>
> If your mailserver is NATed (or otherwise uses a reserved IP), you MUST
> define
I am getting more and more confused :)
If the sender is a NATed box in 192.168/16 space, and the receiver also is a
NATed box
in 192.168/16, rhe received message will have a by 192.168.xx.yy, and seemingly
never
left the trusted network.
If you change trusted networks to 127. or your public ip,
> trusted! That seems too permissive to me. Am I still not understanding
> trusted_networks correctly?
Yup. Those are on the other side of an *un*trusted network, so they don't
count.
Trusted networks determine where the trust stops. It doesn't (so far as I
know) restart after that.
>>From the Mail::SpamAssassin::Conf man page:
trusted_networks ip.add.re.ss[/mask] ... (default: none)
* if the âfromâ IP address is on the same /16 network as the top
Received lineâs âbyâ host, itâs trusted
* if the address of the âfromâ host is in a reserved network range,
then itâs tr
OK, after more R'ing TFM and some kind advice from a list member, I
think I understand now what has been happening.
>>From the Mail::SpamAssassin::Conf man page:
* if the âfromâ IP address is on the same /16 network as the top
Received lineâs âbyâ host, itâs trusted
* if the address of the â
> (We use SA (currently 2.64) called from procmail-delivered sendmail on
> Solaris systems. We get something over 100K msgs/day. Most of our mail
> is addressed using @ our local domain.)
>
> Three suggested rules:
>1) Detect mail allegedly from a local address that is invalid
> (should get
> > Three suggested rules:
> >2) Detect mail that has multiple invalid local addresses in the To:
> > and CC: fields (should get a medium score for 2 or more)
This one can be made to work at a large ISP, at least in many cases. It is
highly questionable at a business where many people may b
1. This can be done really effectively using SPF. I believe spamassassin
can use spf, and most MTA's can too. I highly recommend it. You would
not believe the number of viruses that get turned away by using SPF. It
seems that many of the recent ones send mails to a target domain with a
from add
On Sun, 2004-12-05 at 13:50, Greg - Cirelle Enterprises wrote:
> or is my email messed up again
May be or singature is too much long :-)
--
ASPO Infogérance http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc http://faq.fcolc.eu.org/
LUG sur Orléans et alentours.
Tél : 02 38
or is my email messed up again
Regards
Greg Cirino
___
Cirelle Enterprises Inc.
603-425-2221
www.cirelle.com Web Application Development & Design
www.cirelle.net ProSpeed High Speed Dial-up - 6 Times Faster
www.cedata.com Web, FTP, Email Hosting Services
www.mlsbot.c
> >>
BAYES_99(1.886),RCVD_IN_BL_SPAMCOP_NET(1.216),RISK_FREE(0.230),NO_REAL_NAME(
0.007)
Your Bayes_99 score seems very low. I know the default for bayes-99 is less
than bayes-90, but I thought it was still a fairly significant score.
Either I'm misremembering the release value for bayes-99, or i
On Sat, Dec 04, 2004 at 06:41:34PM -0500, [EMAIL PROTECTED] wrote:
> Google found me a solution that required changing a line of code,
> but it must have been referring to an old version of SA because I
> couldn't find it in the current code.
RTFM :)
_STARS(*)_one * (use any character)
14 matches
Mail list logo
