sqlgrey-users — Users of SQLgrey

[Sqlgrey-users] multiple admin_mail possible?

[Internet H. <hel...@wc...>]

If I want more than one email address for admin_mail in sqlgrey.conf how 
is this done properly?

Can I comma separate them like:
adm...@do..., ad...@do... ?

-- 

Thanks,
Kelly or Troy
WCTA Internet helpdesk
8:00 am to 8:00 pm Mon thru Fri
9:00 am to Noon Sat

Re: [Sqlgrey-users] sqlgrey-1.7.4 (dev)

[Dan F. <da...@ha...>]

Steve Pellegrin wrote:
> Name "DBIx::DBCluster::DEBUG" used only once: possible typo at /usr/ 
> sbin/sqlgrey line 2413.
> Name "DBIx::DBCluster::WRITE_HOSTS_NEVER_READ" used only once:  
> possible typo at /usr/sbin/sqlgrey line 827.
> Name "DBIx::DBCluster::CLUSTERS" used only once: possible typo at / 
> usr/sbin/sqlgrey line 818.
>   
Right.. Thank you for reporting..

Sqlgrey should function perfectly regardless off theese warning. The 
warnings appear because sqlgrey is running normal DBI mode and thus 
these cluster-specific settings are never used.

Ill see if i can find a way to disable those warnings.

- Dan

Re: [Sqlgrey-users] sqlgrey-1.7.4 (dev)

[Steve P. <st...@co...>]

Thanks for the update, Dan.

When I run 1.7.4 *without* clustering, I get the following messages  
on start-up:

Name "DBIx::DBCluster::DEBUG" used only once: possible typo at /usr/ 
sbin/sqlgrey line 2413.
Name "DBIx::DBCluster::WRITE_HOSTS_NEVER_READ" used only once:  
possible typo at /usr/sbin/sqlgrey line 827.
Name "DBIx::DBCluster::CLUSTERS" used only once: possible typo at / 
usr/sbin/sqlgrey line 818.

sqlgrey seems to run OK after this, but I imagine you will want to  
investigate.

-Steve


On Aug 2, 2006, at 8:48 PM, Dan Faerch wrote:

> sqlgrey 1.7.4 has just been released.

[Sqlgrey-users] sqlgrey-1.7.4 (dev)

[Dan F. <da...@ha...>]

sqlgrey 1.7.4 has just been released.

The best greylisting software available, just got better ;)
Download from:
http://sourceforge.net/project/showfiles.php?group_id=113566

This version includes the 3 new features:
-Database clustering support. (read INSTALL)
-RegEx based Discrimination (ie. selective greylisting based on regular 
expressions)
-reject_code config option.

Also it includes Karl O. Pinc's debian-init script + "make 
debian-install" option :)

This version is has been running in a live environment for several 
months, consisting of a cluster of 4 servers, handling some 3.5 million 
greylistings a day.
Cluster is running LVS (Linux virtual server), mysql with 
mysql-replication, sqlgrey with db-clustering and 11 
discrimination-regex's.


For regular sqlgrey users: Check the docs for a good descriptions of new 
features and advice.


For non-sqlgrey users, this release will make it so much easier to get 
started.
-------------------------------------
1) You do not use greylisting at all:
Getting started with greylisting on an existing setup can be a tough 
decision, since you dont know how your users will be affected or how 
theyll react.
Using the new Discrimination feature you can selectively pick whom gets 
greylisted, thus only a fraction will be greylisted depending on your 
Discrimination config.. A good starting point would be greylisting 
anyone that doesnt have reverse-dns and then expanding from there. 
(check docs for more info and help).


2) You already run another greylisting software for postfix (migrating 
to sqlgrey):
You dont use sqlgrey simply because you dont want to start building the 
auto-whitelist from scratch? (since you probably cant export your old 
greylist database and import into sqlgrey)

Heres a trick to make the transition very smooth:
Run BOTH greylist software's. Crazy i know, but hear me out.
Setting the new reject_code option like this: "reject_code=dunno" will 
make sqlgrey NOT reject anything and simply pass the mail on to your 
other greylisting software. But sqlgrey is still doing everything as 
usual in the background and so auto-whitelists will slowly be populated. 
Keep this setup running for a month or two and then disable your old 
software. Then the transition should be absolutely transparent.

In main.cf you probably have a line like this:
smtpd_sender_restrictions = check_policy_service 
unix:private/my_current_greylist

Add sqlgrey IN FRONT of this line (with reject_code=dunno) like so:
smtpd_sender_restrictions =
                check_policy_service inet:127.0.0.1:2501 #If 
127.0.0.1:2501 is where sqlgrey is of course :)
                check_policy_service unix:private/my_current_greylist

Then simply lean back and watch the databases get populated.
(remember to read documentation on how to setup sqlgrey first and try it 
out in a test setup)


- Dan

Re: [Sqlgrey-users] prepare_cached

[<ni...@he...>]

On 25 jul 2006, at 16.35, ni...@he... wrote:

> Dan Faerch wrote:
>> Hi Niclas.
>>
>> I'm am unsure why you get this as I've never seen these myself.
>> I googled a bit and i found this posting:
>> "DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch"
>> http://www.nntp.perl.org/group/perl.dbi.users/29547
>>
>> He says:
>> "After some digging it seems that the new version of the  
>> DBD::mysql is
>> failing to reset the Active attribute on the sth after fetching  
>> all the
>> rows."
>>
>> So its likely this is a bug in the DBD::mysql version you're  
>> running.. I
>> suggest trying downgrade DBD::mysql.
>>
>> - Dan
>
>
> Hi,
>
> i have tried to downgrade to DBD-mysql-3.0003
>
> still got the same error.
>
> / niclas


Sorry, my bad.

I works after i restarted sqlgrey

/ niclas

Re: [Sqlgrey-users] prepare_cached

[<ni...@he...>]

Dan Faerch wrote:
> Hi Niclas.
> 
> I'm am unsure why you get this as I've never seen these myself.
> I googled a bit and i found this posting:
> "DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch"
> http://www.nntp.perl.org/group/perl.dbi.users/29547
> 
> He says:
> "After some digging it seems that the new version of the DBD::mysql is 
> failing to reset the Active attribute on the sth after fetching all the 
> rows."
> 
> So its likely this is a bug in the DBD::mysql version you're running.. I 
> suggest trying downgrade DBD::mysql.
> 
> - Dan


Hi,

i have tried to downgrade to DBD-mysql-3.0003

still got the same error.

/ niclas

[Sqlgrey-users] **Message you sent blocked by our bulk email filter**

[MAILER-DAEMON <>]

WW91ciBtZXNzYWdlIHRvOiBzcWltYnlAY2FyZWVycXVlc3QxLmNvbQ0Kd2Fz
IGJsb2NrZWQgYnkgb3VyIFNwYW0gRmlyZXdhbGwuIFRoZSBlbWFpbCB5b3Ug
c2VudCB3aXRoIHRoZSBmb2xsb3dpbmcgc3ViamVjdCBoYXMgTk9UIEJFRU4g
REVMSVZFUkVEOg0KDQpTdWJqZWN0OiBZb3UgZG9uknQga25vdyB3aGF0IGlz
IHRoZSBiZXN0IHJldmVuZ2UgZm9yIHlvdXIgZXggZ2lybGZyaWVuZC4NCg0K
SWYgeW91IGJlbGlldmUgdGhpcyBtZXNzYWdlIGhhcyBiZWVuIGJsb2NrZWQg
aW4gZXJyb3IuLi4uUGxlYXNlIGZlZWwgZnJlZSB0byBjb250YWN0IHVzIGF0
IFBvc3RtYXN0ZXJASVRSaWdodC5jb20NCg0KCg==

[Sqlgrey-users] Bachelors, Masters, MBA, PhD can be yours in 4 weeks if you qualify.

[<sq...@te...>]

<div align="left"><b><font size="5"> Want the degree but can’t find the time?</font></b><BR>
  <BR>
  WHAT A GREAT IDEA!<BR>
  We provide a concept that will allow anyone with sufficient work experience 
  to obtain a fully verifiable University Degree.<BR>
  Bachelors, Masters or even a Doctorate.<BR>
  Think of it, within four to six weeks, you too could be a college graduate.<BR>
  Many people share the same frustration, they are all doing the work of the person 
  that has the degree and the person that has the degree is getting all the money.<BR>
  Don’t you think that it is time you were paid fair compensation for the level 
  of work you are already doing?<BR>
  This is your chance to finally make the right move and receive your due benefits.<BR>
  If you are like most people, you are more than qualified with your experience, 
  but are lacking that prestigious piece of paper known as a diploma that is often 
  the pas
sport to success.<BR>
  <b>CALL US TODAY AND GIVE YOUR WORK<BR>
  EXPERIENCE THE CHANCE TO EARN YOU<BR>
  THE HIGHER COMPENSATION YOU DESERVE!</b><BR>
  <font color="#FF0033" size="5">CALL NOW:</font><font color="#FF0033" size="7"><BR>
  <b>1-815-828-2222</b></font><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
   Harry had not bothered 
tidying up after himself.</div>

Re: [Sqlgrey-users] prepare_cached

[Dan F. <da...@ha...>]

Hi Niclas.

I'm am unsure why you get this as I've never seen these myself.
I googled a bit and i found this posting:
"DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch"
http://www.nntp.perl.org/group/perl.dbi.users/29547

He says:
"After some digging it seems that the new version of the DBD::mysql is=20
failing to reset the Active attribute on the sth after fetching all the=20
rows."

So its likely this is a bug in the DBD::mysql version you're running.. I=20
suggest trying downgrade DBD::mysql.

- Dan


Niclas =D6hman wrote:
> Hi,
> I have installed sqlgrey on my server and i get this in my logs;
>
> Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT 1 FROM =20
> optout_domain WHERE domain =3D ?) statement handle DBI::st=3DHASH=20
> (0x8532bdc) still Active at /usr/local/sbin/sqlgrey line 246
> Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT 1 FROM =20
> optout_email WHERE email =3D ?) statement handle DBI::st=3DHASH=20
> (0x856ab5c) still Active at /usr/local/sbin/sqlgrey line 246
> Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT now()) =20
> statement handle DBI::st=3DHASH(0x853287c) still Active at /usr/local/=20
> sbin/sqlgrey line 246
>
> Everything is installed via ports.
>
> FreeBSD 4.11
> postfix 2.2.10
> sqlgrey 1.7.3
> mysql 4.0.27
> p5-DBD-mysql40-3.0006
>
>
> Is it a bug, or have i done something wrong ?
>
> / niclas
>
>
>
>
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>
>  =20

[Sqlgrey-users] prepare_cached

[<ni...@he...>]

Hi,
I have installed sqlgrey on my server and i get this in my logs;

Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT 1 FROM  
optout_domain WHERE domain = ?) statement handle DBI::st=HASH 
(0x8532bdc) still Active at /usr/local/sbin/sqlgrey line 246
Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT 1 FROM  
optout_email WHERE email = ?) statement handle DBI::st=HASH 
(0x856ab5c) still Active at /usr/local/sbin/sqlgrey line 246
Jul 15 10:42:06 felix sqlgrey: warning: prepare_cached(SELECT now())  
statement handle DBI::st=HASH(0x853287c) still Active at /usr/local/ 
sbin/sqlgrey line 246

Everything is installed via ports.

FreeBSD 4.11
postfix 2.2.10
sqlgrey 1.7.3
mysql 4.0.27
p5-DBD-mysql40-3.0006


Is it a bug, or have i done something wrong ?

/ niclas

Re: [Sqlgrey-users] A debian init script

[Dan F. <da...@ha...>]

Karl O. Pinc wrote:
> # sqlgrey:        Init script for sqlgrey postfix policy service
>   
Ill check it out when we prepare for the next release, and include it if 
all goes well..
Thanks for sharing :)

- Dan

[Sqlgrey-users] A debian init script

[<ko...@sm...>]

Hello,

I just put sqlgrey on my Debian Sarge box and whipped up this
/etc/init.d/ script.  I am not the Debian initscript guru,
but it works for me.  Please include it in sqlgrey if you like.
I hearby distribute my mods under the GPL used by the rest of
sqlgrey.

Regards,

Karl O. Pinc <ko...@me...>

----------<snip>-------------
#!/bin/sh
#
# sqlgrey:        Init script for sqlgrey postfix policy service
#
# chkconfig: 345 90 10
# description: SQLgrey is a postfix grey-listing policy service.
# pidfile: /var/run/sqlgrey.pid
#
# Hacked from the RH version  Karl O. Pinc <ko...@me...>

# Source function library.
#. /etc/init.d/functions

SQLGREY=/usr/local/sbin/sqlgrey

# See how we were called.
case "$1" in
  start)
	echo -n " sqlgrey"
	# SQLite put files in the working directory
        ERRMSG=$(/sbin/start-stop-daemon --chdir ~sqlgrey --pidfile /var/run/sqlgrey.pid --oknodo --startas $SQLGREY --start -- -d 2>&1)

	if [ $? != 0 ]; then
	    echo "(FAILED)"
	    [ "$ERRMSG" ] && echo "ERROR: $ERRMSG" >&2 || true
	    exit 1
	fi

        [ "$ERRMSG" ] && echo -n " ($ERRMSG)" >&2 || true
	;;

  stop)
	echo -n " sqlgrey"
	sqlgrey -k
	echo_success
	echo
        start-stop-daemon --start --exec $SQLGREY -- -k
	;;

  restart)
	$0 stop
	sleep 1 # hack: missing REUSEADDR from Net::Server?
	$0 start
	;;

  *)
	echo "Usage: sqlgrey {start|stop|restart}"
	exit 1
esac

exit 0

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dan F. <da...@ha...>]

> Can I ask for spam/antivirus system you are using that uses MySQL?
>
Its only the quarantine system and its developed inhouse at work and is 
not available to the public, im afraid.

A wee-bit off-topic though ;). I dont mind off-topic discussions, but 
lets try to keep them off the sqlgrey list.
Anyone should feel free to email me directly with off-topic stuff, so we 
dont bother everyone else on the list :)

- Dan

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Ray B. <rj_...@rj...>]

Dan Faerch wrote:
> Dave Strickler wrote:
>> Two followup questions:
>> 1. What table format do you use? MyISAM or InnoDB ?
>>   
> We use MyISAM and i believe it has become a pretty good table format.. 
> Eg. our logservers each handle just below 2 gigs of data a day in one 
> table and we never get messed up tables or other problems.
>
>> 2. Do you run any sort of maintenance on the SQLGrey tables?
>>
>>   
>
> Nope.. The only maintenance done, is the build-in cleanup routines in 
> SQLGrey (cleaning of old entries and such).
> We also run postfix-transports and userlists, and a 
> spam/virus-quarantine system for all accounts on the same MySQL that 
> runs SQLGrey on each box and MySQL has never let me down.
>
Hi Dan

Can I ask for spam/antivirus system you are using that uses MySQL?

Regards
Ray


> Its lovely to have a system that just hums away in the corner ;)
>
> The only bad experience i have with MySQL is related to things like 
> poweroutages or eg. a kernel-panic or the likes. That can mess up the 
> table a bit, but MySQL comes with a nice little tool called myisamchk 
> that usually repairs that without problems. And in my case, we started 
> clustering our SQL's for the mailsystem using MySQL replication, after 
> i added SQL-clustering support to SQLGrey. So should 1 database or 
> table be lost, i can simply replicate it from another server without 
> loosing 1 single record.
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat 
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users


-- 
Ray Booysen
rj_...@rj...

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dave S. <dst...@ma...>]

Running v8.1 currently, but do not have auto-vac enabled as we are wary of =
anything that could do a vac "at the wrong time".
=20
Dave Strickler
MailWise LLC
617-933-5810 (direct)
www.mailwise.com ( http://www.mailwise.com/ )
"Intelligent E-mail Protection"





>>> "Andrew Diederich" <and...@gm...> 3:01 PM Tuesday, May 30, =
2006 >>>
On 5/30/06, Dave Strickler <dst...@ma...> wrote:
>
> Has anyone had experience in a large email volume shop, going from one =
DB format to the other? I find the connect table needs to be vacuumed =
daily under PostgreSQL. Are there such maintenance "problems" under MySQL =
?


What version of postgres are you using?  I believe 8.0 and 8.1 are
much better about auto-vacuuming, or not needing it in the first
place, than the 7.x versions.

--=20
Andrew Diederich


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as ( http://sel.as/ )-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&b=
id=3D248729&dat=3D121642
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...=20
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

----------------------------
This message has been certified virus-free by MailWise Filter - The real-time, intelligent, e-mail firewall used to scan inbound and outbound messages for SPAM, Viruses and Content.  For more info visit: http://www.mailwise.com 

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dan F. <da...@ha...>]

Dave Strickler wrote:
> Very slick. We will definitely test this out on our end.
>  
> Are you using MyISAM or InnoDB for your table format? MyISAM seems too limited...
>   
We use MyISAM in practically all systems.

If i remember correctly the differences are that InnoDB does real 
transactions and row locking, and MyISAM runs faster.
However this is just as i recall and i didnt doublecheck. 
Also i seem to remember something about the license for InnoDB being 
commercial.
I dont think MyISAM is limited unless you need transactions.

- Dan Faerch




>  
> Dave Strickler
> MailWise LLC
> 617-933-5810 (direct)
> www.mailwise.com ( http://www.mailwise.com/ )
> "Intelligent E-mail Protection"
>
>
>
>
>
>   
>>>> Dan Faerch <da...@ha...> 3:23 PM Tuesday, May 30, 2006 >>>
>>>>         
> Dave Strickler wrote:
>   
>> Two followup questions:
>> 1. What table format do you use? MyISAM or InnoDB ?
>>   
>>     
> We use MyISAM and i believe it has become a pretty good table format.. 
> Eg. our logservers each handle just below 2 gigs of data a day in one 
> table and we never get messed up tables or other problems.
>   

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dave S. <dst...@ma...>]

Very slick. We will definitely test this out on our end.
=20
Are you using MyISAM or InnoDB for your table format? MyISAM seems too =
limited...
=20
Dave Strickler
MailWise LLC
617-933-5810 (direct)
www.mailwise.com ( http://www.mailwise.com/ )
"Intelligent E-mail Protection"





>>> Dan Faerch <da...@ha...> 3:23 PM Tuesday, May 30, 2006 >>>
Dave Strickler wrote:
> Two followup questions:
> 1. What table format do you use? MyISAM or InnoDB ?
>  =20
We use MyISAM and i believe it has become a pretty good table format..=20
Eg. our logservers each handle just below 2 gigs of data a day in one=20
table and we never get messed up tables or other problems.

> 2. Do you run any sort of maintenance on the SQLGrey tables?
>
>  =20

Nope.. The only maintenance done, is the build-in cleanup routines in=20
SQLGrey (cleaning of old entries and such).
We also run postfix-transports and userlists, and a=20
spam/virus-quarantine system for all accounts on the same MySQL that=20
runs SQLGrey on each box and MySQL has never let me down.

Its lovely to have a system that just hums away in the corner ;)

The only bad experience i have with MySQL is related to things like=20
poweroutages or eg. a kernel-panic or the likes. That can mess up the=20
table a bit, but MySQL comes with a nice little tool called myisamchk=20
that usually repairs that without problems. And in my case, we started=20
clustering our SQL's for the mailsystem using MySQL replication, after =
i=20
added SQL-clustering support to SQLGrey. So should 1 database or table=20
be lost, i can simply replicate it from another server without loosing =
1=20
single record.



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as ( http://sel.as/ )-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&b=
id=3D248729&dat=3D121642
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...=20
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

----------------------------
This message has been certified virus-free by MailWise Filter - The real-time, intelligent, e-mail firewall used to scan inbound and outbound messages for SPAM, Viruses and Content.  For more info visit: http://www.mailwise.com 

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dan F. <da...@ha...>]

Dave Strickler wrote:
> Two followup questions:
> 1. What table format do you use? MyISAM or InnoDB ?
>   
We use MyISAM and i believe it has become a pretty good table format.. 
Eg. our logservers each handle just below 2 gigs of data a day in one 
table and we never get messed up tables or other problems.

> 2. Do you run any sort of maintenance on the SQLGrey tables?
>
>   

Nope.. The only maintenance done, is the build-in cleanup routines in 
SQLGrey (cleaning of old entries and such).
We also run postfix-transports and userlists, and a 
spam/virus-quarantine system for all accounts on the same MySQL that 
runs SQLGrey on each box and MySQL has never let me down.

Its lovely to have a system that just hums away in the corner ;)

The only bad experience i have with MySQL is related to things like 
poweroutages or eg. a kernel-panic or the likes. That can mess up the 
table a bit, but MySQL comes with a nice little tool called myisamchk 
that usually repairs that without problems. And in my case, we started 
clustering our SQL's for the mailsystem using MySQL replication, after i 
added SQL-clustering support to SQLGrey. So should 1 database or table 
be lost, i can simply replicate it from another server without loosing 1 
single record.

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Marc G. F. <sc...@hu...>]

On Tue, 30 May 2006, Andrew Diederich wrote:

> On 5/30/06, Dave Strickler <dst...@ma...> wrote:
>> 
>> Has anyone had experience in a large email volume shop, going from one DB 
>> format to the other? I find the connect table needs to be vacuumed daily 
>> under PostgreSQL. Are there such maintenance "problems" under MySQL ?
>
>
> What version of postgres are you using?  I believe 8.0 and 8.1 are
> much better about auto-vacuuming, or not needing it in the first
> place, than the 7.x versions.

8.1 has a built-in autovacuum daemon, but its disabled by default ... the 
8.x series are better are reusing space, but the space still needs to be 
freed up by a vacuum at some point ... what 8.x have reduced (but not 
eliminated) the need for is VACUUM FULL ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . sc...@hu...                              MSN . sc...@hu...
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Andrew D. <and...@gm...>]

On 5/30/06, Dave Strickler <dst...@ma...> wrote:
>
> Has anyone had experience in a large email volume shop, going from one DB format to the other? I find the connect table needs to be vacuumed daily under PostgreSQL. Are there such maintenance "problems" under MySQL ?


What version of postgres are you using?  I believe 8.0 and 8.1 are
much better about auto-vacuuming, or not needing it in the first
place, than the 7.x versions.

-- 
Andrew Diederich

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dave S. <dst...@ma...>]

Good to know the stats - thanks. We run about 2.5 million records in our =
connect table here. Sounds like MySQL is working well for you, and that's =
a good tip. It may be better at handing large amount of 'change' data than =
Postgres.
=20
Postgres has a maintenance routine called a 'Vacuum' that needs to be run =
on all DBs as its not good at maintaining itself. These can be automated, =
but only in the latest versions.
=20
Two followup questions:
1. What table format do you use? MyISAM or InnoDB ?
2. Do you run any sort of maintenance on the SQLGrey tables?
=20
Thanks,
=20
Dave Strickler
MailWise LLC
617-933-5810 (direct)
www.mailwise.com ( http://www.mailwise.com/ )
"Intelligent E-mail Protection"





>>> Dan Faerch <da...@ha...> 12:41 PM Tuesday, May 30, 2006 >>>
I dont know what "vacuumed" is, since i've never used Postgres.

But i do run MySQL, and on my setup we have around 20 INSERT's a second=20
during daytime on each server, and i dont have to do any maintenance at=20
all..
The connect table on a random server at this very moment contains=20
131.081 records. It has 42mb of data and an "overhead" of 31mb.
One could run "Optimize" to remove the overhead, but it doesnt matter=20
since its just unused, pre-alloceted diskspace for the table. (the=20
table-files dont auto-shrink on "delete" operations)
The space will be mostly re-used tomorrow at time-prime as new records=20
are added faster, so basically MySQL seems to find a good size for you=20
table-file and works within that, saving the server for at lot of=20
resizing operations.

- Dan Faerch



Dave Strickler wrote:
> Has anyone had experience in a large email volume shop, going from one =
DB format to the other? I find the connect table needs to be vacuumed =
daily under PostgreSQL. Are there such maintenance "problems" under MySQL =
?
> =20
> =20
> =20
> Dave Strickler
> MailWise LLC
> 617-933-5810 (direct)
> www.mailwise.com ( http://www.mailwise.com/ )
> "Intelligent E-mail Protection"
>
>
>
>
> ----------------------------
> This message has been certified virus-free by MailWise Filter - The =
real-time, intelligent, e-mail firewall used to scan inbound and outbound =
messages for SPAM, Viruses and Content.  For more info visit: http://www.ma=
ilwise.com ( http://www.mailwise.com/ )=20
>  =20



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as ( http://sel.as/ )-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&b=
id=3D248729&dat=3D121642
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...=20
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

----------------------------
This message has been certified virus-free by MailWise Filter - The real-time, intelligent, e-mail firewall used to scan inbound and outbound messages for SPAM, Viruses and Content.  For more info visit: http://www.mailwise.com 

Re: [Sqlgrey-users] Using PostgreSQL vs MySQL

[Dan F. <da...@ha...>]

I dont know what "vacuumed" is, since i've never used Postgres.

But i do run MySQL, and on my setup we have around 20 INSERT's a second 
during daytime on each server, and i dont have to do any maintenance at 
all..
The connect table on a random server at this very moment contains 
131.081 records. It has 42mb of data and an "overhead" of 31mb.
One could run "Optimize" to remove the overhead, but it doesnt matter 
since its just unused, pre-alloceted diskspace for the table. (the 
table-files dont auto-shrink on "delete" operations)
The space will be mostly re-used tomorrow at time-prime as new records 
are added faster, so basically MySQL seems to find a good size for you 
table-file and works within that, saving the server for at lot of 
resizing operations.

- Dan Faerch



Dave Strickler wrote:
> Has anyone had experience in a large email volume shop, going from one DB format to the other? I find the connect table needs to be vacuumed daily under PostgreSQL. Are there such maintenance "problems" under MySQL ?
>  
>  
>  
> Dave Strickler
> MailWise LLC
> 617-933-5810 (direct)
> www.mailwise.com ( http://www.mailwise.com/ )
> "Intelligent E-mail Protection"
>
>
>
>
> ----------------------------
> This message has been certified virus-free by MailWise Filter - The real-time, intelligent, e-mail firewall used to scan inbound and outbound messages for SPAM, Viruses and Content.  For more info visit: http://www.mailwise.com 
>   

[Sqlgrey-users] Using PostgreSQL vs MySQL

[Dave S. <dst...@ma...>]

Has anyone had experience in a large email volume shop, going from one DB =
format to the other? I find the connect table needs to be vacuumed daily =
under PostgreSQL. Are there such maintenance "problems" under MySQL ?
=20
=20
=20
Dave Strickler
MailWise LLC
617-933-5810 (direct)
www.mailwise.com ( http://www.mailwise.com/ )
"Intelligent E-mail Protection"




----------------------------
This message has been certified virus-free by MailWise Filter - The real-time, intelligent, e-mail firewall used to scan inbound and outbound messages for SPAM, Viruses and Content.  For more info visit: http://www.mailwise.com 

[Sqlgrey-users] Major updates to sqlgrey in CVS.

[Dan F. <da...@ha...>]

Allright..

Ive been putting this update off for a while, but its finally committed 
to CVS.
It adds 3 new features. 1 small and 2 big ones.

Ive tried to make the patch as un-intrusive as possible. Everything 
should work as it always has if you do not enabled theese features.
My production environment is  is running with all theese features 
enabled and has for several months without problems, but id still like 
it if someone would test this version to confirm that. Id like 
confirmation that it runs like it always has for ppl who dont use the 
new features. If someone tries the new features id love to get feedback 
on that as well.
(Again, it HAS been thoroughly tested in my setup).

New features:
1. reject_code option.
By setting this in sqlgrey.conf you can change the default "450" 
response to eg. 451.

2. DBClustering
Allows for use of several sql-servers for reading, while still writing 
to just 1 master server.
See README.DBCLUSTER
Tested and running in production on MySQL's. If anyone tries this on 
other SQL brands let me know how it works out.

3. Discrimination (aka. Selective Greylisting)
Alternative approach to greylisting. Allows you to specify a set of 
rules (as regular expressions) that decides whom can bypass greylisting 
entirely, based on characteristics in eg. reverse-dns name, HELO string, 
sender address ect.
See READ.DISCRIMINATION

(Remember; you have to checkout CVS version, not download the packaged 
1.7.3)

Any feedback is greatly appreciated. :)

- Dan Faerch

Re: [Sqlgrey-users] sqlgrey dies - MORE

[Steve H. <st...@th...>]

On Fri, 2006-05-12 at 17:02, Dan Faerch wrote:


> > If not, then ive made a quick fix for you against 1.7.1:
> Did either of these solutions solve your problem?
> 


I must confess that I havent had time to do either. I solved the
immediate problem by blocking the offending email in postfix.

Steve
 

-- 
thorNET
Internet Services, Consultancy & Training
www.thornet.co.uk