Spam filtering levels

First a question...  I have detected spam being quarantined,
however 
when I try to set the quarantine_spam score, it is always
reset to the 
same level as the consider_spam score.  Is this the
programmed behavior, 
or is this another problem?  If it IS the expected behavior,
why not 
gray-out the quarantine score since anything I enter will be
ignored anyway?

Second, a request.  In this same area, I believe it would be
useful to 
also include a discard_spam score to allow users to not even
worry about 
high-scoring items.  For instance, I believe anything that
scores over 
20 could be safely discarded, and even safely automatically
added to the 
bayes filter as a spam.  Are there any plans to add another
field for 
this?  If not, would anyone be opposed to me writing up the
appropriate 
changes for submission?
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

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

Jeff Taylor wrote:
> First a question...  I have detected spam being
quarantined, however 
> when I try to set the quarantine_spam score, it is
always reset to the 
> same level as the consider_spam score.  Is this the
programmed behavior, 
> or is this another problem?  If it IS the expected
behavior, why not 
> gray-out the quarantine score since anything I enter
will be ignored anyway?

Yes, it's the intended behaviour, a safety feature to
prevent you from
creating inconsistent score thresholds.  If you select
"Quarantined" or
"Discarded" as your spam destiny, then the second
two scores get locked
together.  If you select "Labeled", the quarantine
level gets forced to
999 to prevent quarantining from occurring.  And yes, one of
the changes
upcoming in 1.0.3 will be to hide that third field
altogether, since in
the 1.0.x series only one destiny can be applied to spam.


> Second, a request.  In this same area, I believe it
would be useful to 
> also include a discard_spam score to allow users to not
even worry about 
> high-scoring items.  For instance, I believe anything
that scores over 
> 20 could be safely discarded, and even safely
automatically added to the 
> bayes filter as a spam.  Are there any plans to add
another field for 
> this?  If not, would anyone be opposed to me writing up
the appropriate 
> changes for submission?

You might find it instructive to check the issue tracking
system
(<http:/
/www.maiamailguard.com/maia/report/3>) so you can see
what
issues have been reported already and what feature requests
other people
have already made.  This one, for instance, has been on the
list for
ages, and is slated for implementation in the 1.1.x series
later this
fall (see <http://www.maiamailguard.com/maia/wiki/NewThresholds>
).

You might also take a look at the archives of this list
<ht
tp://www.renaissoft.com/pipermail/maia-users> (or a
searchable
version at <http://news.gmane.org/gmane.mail.virus.maiamailguard>
) for
the past month or so, where you'll find a "hack"
discussed for using an
external SQL script to purge the database of high-scoring
items at
regular intervals, which should satisfy your needs until the
1.1.x
series arrives with the proper solution.  See
<http://www.renaissoft.com/pipermail/mai
a-users/2007-July/010211.html>.

- --
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

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

iD8DBQFGv+ChGmqOER2NHewRAvIrAKCgjNYC/aWhW934PBZIc/D0cjl06ACd
Hg0D
iI/Qo911Ke54Ln3vV4R+n2k=
=dJRZ
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Can someone help on this one ?

We have concluded our pilot, and decided to go to
production, but I've encountered a problem with rejecting
unverified recipients.

I have read everything I can on PostFix (& Maia's
Archived List) on how to reject Unknown user, but I'm a bit
confused.

1) If my settings go into main.cf, how does that apply to
the MTA-RX ? 
	Doesn't it have to be applied in Master.cf to determine
with MTA will reject ?


2) Is this the command I use if I want to reference my
Aliases file ?

 	/etc/postfix/main.cf
   	 local_recipient_maps = proxy:unix:passwd.byname,
$alias_maps,


3) We always use the aliases file to determine final
destination. It's always been in the format below - is this
ok for a reference file ?
The documents say it will ignore anything on the right, but
will it ignore the : ?

student1:		student1server1
student2:		student2server2


Thanks everyone.

Mike Abraham
Conestoga College of Applied Arts & Technology



_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

We are testing atm with a similar situation in wich maia is
in front of
our exchange server. I use ldap to lookup if a email address
exists on
our exchange server:

/usr/local/etc/postfix/main.cf:

relay_recipient_maps =
    ldap:/usr/local/etc/postfix/ldap_relay_recipient_maps.cf


Is added to the main.cf file. I didn't had to change the
master.cf file
to make this work. So maybe that's an answer to your first
question 
Postfix denies the mail when it connects, if the email
address isn't
matched through ldap . 

Jeffrey Schilperoord

-----Oorspronkelijk bericht-----
Van: maia-users-bouncesrenaissoft.com
[mailto:maia-users-bouncesrenaissoft.com] Namens Mike
Abraham
Verzonden: maandag 13 augustus 2007 18:15
Aan: Maia-usersrenaissoft.com
Onderwerp: [Maia-users] How to filter unknown user using
Aliases file ?

Can someone help on this one ?

We have concluded our pilot, and decided to go to
production, but I've
encountered a problem with rejecting unverified recipients.

I have read everything I can on PostFix (& Maia's
Archived List) on how
to reject Unknown user, but I'm a bit confused.

1) If my settings go into main.cf, how does that apply to
the MTA-RX ? 
	Doesn't it have to be applied in Master.cf to determine
with MTA
will reject ?


2) Is this the command I use if I want to reference my
Aliases file ?

 	/etc/postfix/main.cf
   	 local_recipient_maps = proxy:unix:passwd.byname,
$alias_maps,


3) We always use the aliases file to determine final
destination. It's
always been in the format below - is this ok for a reference
file ?
The documents say it will ignore anything on the right, but
will it
ignore the : ?

student1:		student1server1
student2:		student2server2


Thanks everyone.

Mike Abraham
Conestoga College of Applied Arts & Technology



_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

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

Mike Abraham wrote:

> I have read everything I can on PostFix (& Maia's
Archived List) on how to reject Unknown user, but I'm a bit
confused.
> 
> 1) If my settings go into main.cf, how does that apply
to the MTA-RX ? 
> 	Doesn't it have to be applied in Master.cf to
determine with MTA will reject ?

The stuff you put in main.cf technically applies to both
MTA-RX and
MTA-TX, but the trick is to explicitly disable certain
checks in your
master.cf file for the MTA-TX instance.  Essentially you
want the MTA-RX
to do almost all the sender/recipient checking, and then
disable those
checks for the MTA-TX instance (since they've already been
done upstream).


> 2) Is this the command I use if I want to reference my
Aliases file ?
> 
>  	/etc/postfix/main.cf
>    	 local_recipient_maps = proxy:unix:passwd.byname,
$alias_maps,

I don't believe the commas are necessary there:

  local_recipient_maps = proxy:unix:passwd.byname
$alias_maps

You'll also want to set:

  unknown_local_recipient_reject_code = 550

- From there, it's just a matter of adding
"reject_unauth_destination" to
your "smtpd_recipient_restrictions" setting,
remembering that the order
of these tests is important, e.g.

  smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination,
check_policy_service
unix:private/policy

Then in your master.cf file, in the section where you've
defined the
MTA-TX instance, you disable many of the checks you defined
in main.cf,
and override the "smtpd_recipient_restrictions"
setting by redefining it
to include only the most basic tests, e.g.

  127.0.0.1:10025 inet n  - n  -  -  smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o
smtpd_recipient_restrictions=permit_mynetworks,reject
    ...


> 3) We always use the aliases file to determine final
destination. It's always been in the format below - is this
ok for a reference file ?
> The documents say it will ignore anything on the right,
but will it ignore the : ?
> 
> student1:		student1server1
> student2:		student2server2

Yes, it will ignore the ':', just like Sendmail does (it
reads
Sendmail-compatible aliases files).

- --
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

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

iD8DBQFGwLW5GmqOER2NHewRAtv8AJ404Vt5S/K2/hVce728inYablBYgwCf
VfGL
k5I8JY1S0DGaIcyy11wF1NY=
=gl9e
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

I just wanted to thank you Robert for your devotion to this
project. 

After spending two days getting frustrated at not being able
to get local_recipient working, it turned out to be a
$relay_domain setting (was disabled by default).

Thanks for all your help.

Mike Abraham
Conestoga College.

>>> On 8/13/2007 at 5:59 PM, Robert LeBlanc
<rjlrenaissoft.com> wrote:
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  Mike Abraham wrote:
 > Thanks for the quick reply Robert.
 > 
 > Question: Does the mynetworks check override the
Recipient maps check ???
 > 
 > I have all your suggestions implemented, yet it still
accepts bogus 
  recipients (even restarted server).
 > 
 > The SMTPD -v output log indicates all "CHECKING
RECIPIENT MAPS" checks return 
  "not found", so I would assume it would fail
delivery, yet it gets delivered 
  to our website - which seems to be because mydomain
resolves there.
  
  No, remember that it's looking for recipient
/restrictions/, so if it
  doesn't find any it has no reason to prevent the mail from
being
  delivered.  In other words, Postfix starts with the
premise that
  everything gets delivered, unless you give it reasons why
the mail
  should /not/ be delivered.  That's what the
smtpd_recipient_restrictions
  clause is about.
  
  The problem you're describing sounds like it's unable to
find or read
  your aliases database.  Did you run the postalias command
after creating
  your aliases file?  You need to do this in order to
convert your
  text-based aliases file into a hashed database that
Postfix can use
  directly.
  
  - --
  Robert LeBlanc <rjlrenaissoft.com>
  Renaissoft, Inc.
  Maia Mailguard <http://www.maiamail
guard.com/>
  
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.7 (GNU/Linux)
  
 
iD8DBQFGwNQ4GmqOER2NHewRAufXAJ9uKrpJy3SFR+Pug2/ITrZY7eEEWQCe
MRhn
  M0yTl29ezfjne6jUaVevNtw=
  =RtPs
  -----END PGP SIGNATURE-----

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users