sqlgrey-users — Users of SQLgrey

Re: [Sqlgrey-users] submit for client_fqdn_whitelist

[Lionel B. <lio...@bo...>]

On 03/06/12 19:58, Troy Ayers wrote:
> Is there was a way to submit a domain to have it included in the 
> fqdn_whitelist?  So if someone updates they get this domain included?
>
> If not, I'll just mention it here.
>
> No retry
> fastenal.com

If someone else can confirm this behaviour here, I'll add it to the
whitelist.

Lionel

[Sqlgrey-users] submit for client_fqdn_whitelist

[Troy A. <dsp...@wc...>]

Is there was a way to submit a domain to have it included in the 
fqdn_whitelist?  So if someone updates they get this domain included?

If not, I'll just mention it here.

No retry
fastenal.com

-Troy

Re: [Sqlgrey-users] early reconnect issue

[Marko W. <we...@za...>]

Maybe you also have a look on POSTFIX POSTSCREEN.

http://www.postfix.org/POSTSCREEN_README.html


marko



Am 06.12.2011 20:18, schrieb Robert Schetterer:
> Am 06.12.2011 17:44, schrieb Lionel Bouton:
>> Le 06/12/2011 12:29, Kevin Wincott a écrit :
>>> we currently run sqlgrey across a number of mail cluster servers, 
>>> what
>>> we are seeing on some occasions are servers reconnecting many times 
>>> in
>>> the space of a few seconds, then giving up. has anyone come across 
>>> this
>>> before and how did you get round it?
>
> look at your logs, are these bots, where do they come from ?
> there are bots simply dont care about greylist or any other smtp
> feature, they simple fire
>
> if using postfix ,use postscreen, anyway you dont need to greylist 
> all
> in general, do it only for reverse dns ips looking like dyn ips
> these means selective, you wont see much more spam passing by this 
> way
> and fast legal clients
>
> anotherway is fail2ban, and/or iptables recent
>
> for extrem fast bots i use iptables recent from rsyslog pipe and a 
> shell
> script, i had 5 smtp cons per second in max
> which leads to 0,25 million bot ips during a half day on one server
> mostly from india and brasil
>
>>
>> This isn't standard compliant behaviour (to workaround temporary
>> glitches, mail delivery should be retried for 5 days IIRC).
>>
>> Anyway, there are provisions to support this kind of behaviour in
>> SQLgrey. Most of the time this doesn't require any tuning, but if
>> SQLgrey doesn't manage to recognize these servers, you can whitelist
>> them: see the distributed whitelists for examples.
>> Don't touch the distributedd whitelists (they are overwritten when
>> updating SQLgrey) but place your whitelist entries in the 
>> corresponding
>> *.local files, SQLgrey loads their content on the fly (no need to 
>> restart).
>>
>> You should report the servers with such problem here and the 
>> whitelist
>> entry you used to workaround your problem : if several people report 
>> the
>> same problem, I'll add the whitelist entries to the ones 
>> distributed.
>>
>> Best regards,
>>
>> Lionel
>>
>> 
>> ------------------------------------------------------------------------------
>> Cloud Services Checklist: Pricing and Packaging Optimization
>> This white paper is intended to serve as a reference, checklist and 
>> point of
>> discussion for anyone considering optimizing the pricing and 
>> packaging model
>> of a cloud services business. Read Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>> _______________________________________________
>> Sqlgrey-users mailing list
>> Sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>
>
> --
> Best Regards
>
> MfG Robert Schetterer
>
> Germany/Munich/Bavaria
>
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and 
> point of
> discussion for anyone considering optimizing the pricing and 
> packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

Re: [Sqlgrey-users] early reconnect issue

[Robert S. <ro...@sc...>]

Am 07.12.2011 09:31, schrieb Kevin Wincott:
> thank you for the suggestions, the problem is that these are legitimate
> connections, one thats causing an issue is a certain Yorkshire based ISP
> in the UK. They only way we have of knowing there is an issue is when
> some raises a support ticket to say they havent received an email

thats not unusual
as i said ,if this is legitim mail, and they penetrate your mailserver ,
problem must dealed at the source first
ask them to slow down their deliver rate to you, at last
dont let them running into greylist if you allready know that they are
legitim mail

> 
> 
> On 06/12/11 19:18, Robert Schetterer wrote:
>> Am 06.12.2011 17:44, schrieb Lionel Bouton:
>>> Le 06/12/2011 12:29, Kevin Wincott a écrit :
>>>> we currently run sqlgrey across a number of mail cluster servers, what
>>>> we are seeing on some occasions are servers reconnecting many times in
>>>> the space of a few seconds, then giving up. has anyone come across this
>>>> before and how did you get round it?
>> look at your logs, are these bots, where do they come from ?
>> there are bots simply dont care about greylist or any other smtp
>> feature, they simple fire
>>
>> if using postfix ,use postscreen, anyway you dont need to greylist all
>> in general, do it only for reverse dns ips looking like dyn ips
>> these means selective, you wont see much more spam passing by this way
>> and fast legal clients
>>
>> anotherway is fail2ban, and/or iptables recent
>>
>> for extrem fast bots i use iptables recent from rsyslog pipe and a shell
>> script, i had 5 smtp cons per second in max
>> which leads to 0,25 million bot ips during a half day on one server
>> mostly from india and brasil
>>
>>> This isn't standard compliant behaviour (to workaround temporary
>>> glitches, mail delivery should be retried for 5 days IIRC).
>>>
>>> Anyway, there are provisions to support this kind of behaviour in
>>> SQLgrey. Most of the time this doesn't require any tuning, but if
>>> SQLgrey doesn't manage to recognize these servers, you can whitelist
>>> them: see the distributed whitelists for examples.
>>> Don't touch the distributedd whitelists (they are overwritten when
>>> updating SQLgrey) but place your whitelist entries in the corresponding
>>> *.local files, SQLgrey loads their content on the fly (no need to restart).
>>>
>>> You should report the servers with such problem here and the whitelist
>>> entry you used to workaround your problem : if several people report the
>>> same problem, I'll add the whitelist entries to the ones distributed.
>>>
>>> Best regards,
>>>
>>> Lionel
>>>
>>> ------------------------------------------------------------------------------
>>> Cloud Services Checklist: Pricing and Packaging Optimization
>>> This white paper is intended to serve as a reference, checklist and point of 
>>> discussion for anyone considering optimizing the pricing and packaging model 
>>> of a cloud services business. Read Now!
>>> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>>>
> Kind regards,
> 
> Kevin Wincott (ISP Administrator) CCENT, CCNA
> 
> This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Midland Computers Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please contact the sender.
> 
> Please note: Prices are based upon the prices given at the quotation stage and are valid for 7 days. All prices exclude VAT, delivery and installation unless stated otherwise. Quotes are accepted in accordance with our Terms and Conditions which are available upon request. Any 3rd Party hardware and software we supply (i.e. Microsoft, HP etc) is in good faith, if for any reason faults or bugs are found we cannot be held responsible. Goods under warranty will be replaced by the manufacturer, however data transfer, re-loading of software, configuration etc. is chargeable. Any dispute/warranty is direct with the manufacturer, not Midland Computers unless warranty states otherwise. E&OE.
> 
> _______________________________________________
>>> Sqlgrey-users mailing list
>>> Sql...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>>
> 
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Sqlgrey-users] early reconnect issue

[Kevin W. <kev...@mi...>]

thank you for the suggestions, the problem is that these are legitimate
connections, one thats causing an issue is a certain Yorkshire based ISP
in the UK. They only way we have of knowing there is an issue is when
some raises a support ticket to say they havent received an email


On 06/12/11 19:18, Robert Schetterer wrote:
> Am 06.12.2011 17:44, schrieb Lionel Bouton:
>> Le 06/12/2011 12:29, Kevin Wincott a écrit :
>>> we currently run sqlgrey across a number of mail cluster servers, what
>>> we are seeing on some occasions are servers reconnecting many times in
>>> the space of a few seconds, then giving up. has anyone come across this
>>> before and how did you get round it?
> look at your logs, are these bots, where do they come from ?
> there are bots simply dont care about greylist or any other smtp
> feature, they simple fire
>
> if using postfix ,use postscreen, anyway you dont need to greylist all
> in general, do it only for reverse dns ips looking like dyn ips
> these means selective, you wont see much more spam passing by this way
> and fast legal clients
>
> anotherway is fail2ban, and/or iptables recent
>
> for extrem fast bots i use iptables recent from rsyslog pipe and a shell
> script, i had 5 smtp cons per second in max
> which leads to 0,25 million bot ips during a half day on one server
> mostly from india and brasil
>
>> This isn't standard compliant behaviour (to workaround temporary
>> glitches, mail delivery should be retried for 5 days IIRC).
>>
>> Anyway, there are provisions to support this kind of behaviour in
>> SQLgrey. Most of the time this doesn't require any tuning, but if
>> SQLgrey doesn't manage to recognize these servers, you can whitelist
>> them: see the distributed whitelists for examples.
>> Don't touch the distributedd whitelists (they are overwritten when
>> updating SQLgrey) but place your whitelist entries in the corresponding
>> *.local files, SQLgrey loads their content on the fly (no need to restart).
>>
>> You should report the servers with such problem here and the whitelist
>> entry you used to workaround your problem : if several people report the
>> same problem, I'll add the whitelist entries to the ones distributed.
>>
>> Best regards,
>>
>> Lionel
>>
>> ------------------------------------------------------------------------------
>> Cloud Services Checklist: Pricing and Packaging Optimization
>> This white paper is intended to serve as a reference, checklist and point of 
>> discussion for anyone considering optimizing the pricing and packaging model 
>> of a cloud services business. Read Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>> 
Kind regards,

Kevin Wincott (ISP Administrator) CCENT, CCNA

This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Midland Computers Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please contact the sender.

Please note: Prices are based upon the prices given at the quotation stage and are valid for 7 days. All prices exclude VAT, delivery and installation unless stated otherwise. Quotes are accepted in accordance with our Terms and Conditions which are available upon request. Any 3rd Party hardware and software we supply (i.e. Microsoft, HP etc) is in good faith, if for any reason faults or bugs are found we cannot be held responsible. Goods under warranty will be replaced by the manufacturer, however data transfer, re-loading of software, configuration etc. is chargeable. Any dispute/warranty is direct with the manufacturer, not Midland Computers unless warranty states otherwise. E&OE.

_______________________________________________
>> Sqlgrey-users mailing list
>> Sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>

Re: [Sqlgrey-users] early reconnect issue

[Robert S. <ro...@sc...>]

Am 06.12.2011 17:44, schrieb Lionel Bouton:
> Le 06/12/2011 12:29, Kevin Wincott a écrit :
>> we currently run sqlgrey across a number of mail cluster servers, what
>> we are seeing on some occasions are servers reconnecting many times in
>> the space of a few seconds, then giving up. has anyone come across this
>> before and how did you get round it?

look at your logs, are these bots, where do they come from ?
there are bots simply dont care about greylist or any other smtp
feature, they simple fire

if using postfix ,use postscreen, anyway you dont need to greylist all
in general, do it only for reverse dns ips looking like dyn ips
these means selective, you wont see much more spam passing by this way
and fast legal clients

anotherway is fail2ban, and/or iptables recent

for extrem fast bots i use iptables recent from rsyslog pipe and a shell
script, i had 5 smtp cons per second in max
which leads to 0,25 million bot ips during a half day on one server
mostly from india and brasil

> 
> This isn't standard compliant behaviour (to workaround temporary
> glitches, mail delivery should be retried for 5 days IIRC).
> 
> Anyway, there are provisions to support this kind of behaviour in
> SQLgrey. Most of the time this doesn't require any tuning, but if
> SQLgrey doesn't manage to recognize these servers, you can whitelist
> them: see the distributed whitelists for examples.
> Don't touch the distributedd whitelists (they are overwritten when
> updating SQLgrey) but place your whitelist entries in the corresponding
> *.local files, SQLgrey loads their content on the fly (no need to restart).
> 
> You should report the servers with such problem here and the whitelist
> entry you used to workaround your problem : if several people report the
> same problem, I'll add the whitelist entries to the ones distributed.
> 
> Best regards,
> 
> Lionel
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Sqlgrey-users] early reconnect issue

[Lionel B. <lio...@bo...>]

Le 06/12/2011 12:29, Kevin Wincott a écrit :
> we currently run sqlgrey across a number of mail cluster servers, what
> we are seeing on some occasions are servers reconnecting many times in
> the space of a few seconds, then giving up. has anyone come across this
> before and how did you get round it?

This isn't standard compliant behaviour (to workaround temporary
glitches, mail delivery should be retried for 5 days IIRC).

Anyway, there are provisions to support this kind of behaviour in
SQLgrey. Most of the time this doesn't require any tuning, but if
SQLgrey doesn't manage to recognize these servers, you can whitelist
them: see the distributed whitelists for examples.
Don't touch the distributedd whitelists (they are overwritten when
updating SQLgrey) but place your whitelist entries in the corresponding
*.local files, SQLgrey loads their content on the fly (no need to restart).

You should report the servers with such problem here and the whitelist
entry you used to workaround your problem : if several people report the
same problem, I'll add the whitelist entries to the ones distributed.

Best regards,

Lionel

[Sqlgrey-users] early reconnect issue

[Kevin W. <kev...@mi...>]

we currently run sqlgrey across a number of mail cluster servers, what
we are seeing on some occasions are servers reconnecting many times in
the space of a few seconds, then giving up. has anyone come across this
before and how did you get round it?

Kind regards,

Kevin Wincott (ISP Administrator) CCENT, CCNA

This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Midland Computers Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please contact the sender.

Please note: Prices are based upon the prices given at the quotation stage and are valid for 7 days. All prices exclude VAT, delivery and installation unless stated otherwise. Quotes are accepted in accordance with our Terms and Conditions which are available upon request. Any 3rd Party hardware and software we supply (i.e. Microsoft, HP etc) is in good faith, if for any reason faults or bugs are found we cannot be held responsible. Goods under warranty will be replaced by the manufacturer, however data transfer, re-loading of software, configuration etc. is chargeable. Any dispute/warranty is direct with the manufacturer, not Midland Computers unless warranty states otherwise. E&OE.

[Sqlgrey-users] prepend config option

[Jernej P. <jer...@ar...>]

Heya,

I am trying to set prepend config option to 0 to be able to hide the sqlgrey service from emails.

If I set the prepend in sqlgrey.conf to 0, it has no effect on sqlgrey. If I set it up in sqlgrey perl script by setting $dflt{prepend} = 0, it has no effect either. I always get X-Greylist: in the headers of emails.

Is anyone else experiencing the same issues?

thank you in advance, 

cheers, J.

[Sqlgrey-users] for those needing graphical statistics based on the rrdtool

[Markus <sq...@em...>]

Hello *,

for those needing a graphical statistics overview on your sqlgrey 
daemon, i've modified the mailgraph tool from David Schweikert to show 
the sqlgrey stats.
If you need it, you may download the sqlgreygraph tool (under GPL) from 
www.std-soft.com/bfaq/46-k-faq-server/117-sqlgreygraph-mail-statistik.html

greets
Markus

[Sqlgrey-users] Installing in /usr/local

[Richard V. <in...@ri...>]

I've just got sqlgrey-1.8.0-rc2 working on a Mac mini running Lion, but during the process I ran into issues which I think solved successfully but I had to make some alterations to the Makefile. I'm not sure I've done it correctly and would like to share my adjustments.

Too install sqlgrey in /usr/local/ which would be good practice (but that is a different discussion) I tried to changing the ROOTDIR var by using: 

make -e ROOTDIR=/usr/local install

but then I found out that the bin and sbin stuff ended up wrongly. So I had too make the following changes to the directory structure in Makefile:

ETCDIR = $(ROOTDIR)/etc
CONFDIR = $(ETCDIR)/sqlgrey
SBINDIR = $(ROOTDIR)/sbin
BINDIR = $(ROOTDIR)/bin
INITDIR = $(ETCDIR)/init.d
MANDIR = $(ROOTDIR)/share/man/man1

I'm not an expert in these matters therefore looking for validation or second opinion on my changes. If I should have done it another way please tell me.

For the rest it is running great on my machine and solved a lot of my spam issues.

For people curious on how to install it on a Mac with Lion here are the instructions: http://diymacserver.com/mail/lion/setting-up-greylisting-with-sqlgrey/

Regards,

Richard

[Sqlgrey-users] Clients_ip_whitelist

[Daniel M. <dan...@au...>]

I¹ve collected a fair number of boxes that don¹t react well to sqlgrey.
Most recently, AOL started trying to hit me on 64.12.207.  I¹ve added it to
my clients_ip_whitelist.local, but thought other sqlgrey users might be
interested.


Here are my .local exceptions:
209.112.4.11    #kubra.com
137.236.45      #xpedite.com pool
137.236.4       #xpedite.com pool
198.214.232.126 #MPP portal
162.89.0.112    #ci.austin.tx.us
70.249.75.249   #austingraphics.com
67.95.8.179    #mepengineering.com
32.97.182    #us.ibm.com
32.97.110    #us.ibm.com
208.45.243.161    #statesman.com
198.102.112.27    # autodesk.com pool
198.102.112.47    # autodesk.com pool
198.102.112.48    # autodesk.com pool
24.227.160.2    # chilesarchitects.com
12.132.163.25    # mccoys.com
208.86.156.238    # redwindconsulting.com
64.12.207    # AOL (new pool)



-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281

Re: [Sqlgrey-users] sqlgrey in optout not working for me

[Daniel M. <dan...@au...>]

On 5/4/11 6:19 AM, "we...@za..." <we...@za...>
wrote:

>  It should not be greylisted or?
>  I set optmethod = optout,
>  so my thought is, if the senderdomain is in optout_domains, it wont be
>  greylisted.

Optout_domains is used for recipients.  To eliminate greylisting for a
sender, use clients_fqdn_whitelist.local


-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281

[Sqlgrey-users] sqlgrey in optout not working for me

[<we...@za...>]

 Hi there to all in the list,
 i am new here and its my first post.

 i use on ubuntu 10.x Server "sqlgrey Version: 1.6.8-4"

 the active settings in /etc/sqlgrey/sqlgrey.conf are:

 loglevel = 0
 inet = 2501
 awl_age = 60
 group_domain_level = 10
 db_type = mysql
 db_name = sqlgrey
 db_host = localhost
 db_port = default
 db_user = root
 db_pass = <password>
 db_cleandelay = 1800 # in seconds, how much time between database 
 cleanups
 clean_method = sync
 prepend = 1

 greymethod = smart

 optmethod = optout

 wihitelists_host = sqlgrey.bouton.name
 admin_mail = support@<mail>

 Now, when i put a domain like zackbummende.de withe webgui into 
 "optout_domains"
 and send an mail from zackbummende.de to this server, the mail get 
 greylisted.
 It should not be greylisted or?
 I set optmethod = optout,
 so my thought is, if the senderdomain is in optout_domains, it wont be 
 greylisted.

 am i wrong?

 thanks for any help from cloudy hamburg

 marko

Re: [Sqlgrey-users] fallback mysql server

[Robert S. <ro...@sc...>]

Am 14.03.2011 09:02, schrieb Urban, Frank (GS-ITR):
> Im only a user of Sqlgrey not a developer.

ok was just a question

> But how should it work if you will send the data to several write hosts?

that shouldnt care sqlgrey in first case

> Make no sense. Or are you using a master-master replication on the sql database servers?
> Its possibel that this works in Version 1.8. Didn't checked this.

replication is mysql stuff , there is no direct logical connect to
applications, they should work by its own
i.e.
the application should give some failure if it cant write/read to a db
host whatever if you use 1 or hundred of them, in failure case sqlgrey
should use then the working one automatic

but ok for now i will look in the newest sqlgrey code

read on 2 db hosts maybe enough for me

> 
> -----Original Message-----
> From: Robert Schetterer [mailto:ro...@sc...] 
> Sent: Monday, March 14, 2011 8:53 AM
> To: sql...@li...
> Subject: Re: [Sqlgrey-users] fallback mysql server
> 
> Am 14.03.2011 07:27, schrieb Urban, Frank (GS-ITR):
>> Hi,
>> as far as I know only for a reading in Version 1.7.
>>
>> read_hosts = 192.168.125.1,192.168.125.2
> 
> sorry does this mean there is only one db host for write but an option
> to have 2 hosts for reading?
> 
> and if so what does sqlgrey do if the write host dissapear?
> is there enough logic coded that there is no desaster output in that
> case ...?
>>
>> Greetings
>>
>> Frank
>>
>> -----Original Message-----
>> From: Robert Schetterer [mailto:ro...@sc...] 
>> Sent: Sunday, March 13, 2011 8:52 AM
>> To: sql...@li...
>> Subject: [Sqlgrey-users] fallback mysql server
>>
>> Hi,
>> is there the option to use a fallback
>> database server
>>
>> i.e like
>>
>> db_host = 192.168.125.1  192.168.125.2
>>
>>
> 
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Sqlgrey-users] fallback mysql server

[Urban, F. (GS-ITR) <Fra...@co...>]

Im only a user of Sqlgrey not a developer.
But how should it work if you will send the data to several write hosts?
Make no sense. Or are you using a master-master replication on the sql database servers?
Its possibel that this works in Version 1.8. Didn't checked this.

-----Original Message-----
From: Robert Schetterer [mailto:ro...@sc...] 
Sent: Monday, March 14, 2011 8:53 AM
To: sql...@li...
Subject: Re: [Sqlgrey-users] fallback mysql server

Am 14.03.2011 07:27, schrieb Urban, Frank (GS-ITR):
> Hi,
> as far as I know only for a reading in Version 1.7.
> 
> read_hosts = 192.168.125.1,192.168.125.2

sorry does this mean there is only one db host for write but an option
to have 2 hosts for reading?

and if so what does sqlgrey do if the write host dissapear?
is there enough logic coded that there is no desaster output in that
case ...?
> 
> Greetings
> 
> Frank
> 
> -----Original Message-----
> From: Robert Schetterer [mailto:ro...@sc...] 
> Sent: Sunday, March 13, 2011 8:52 AM
> To: sql...@li...
> Subject: [Sqlgrey-users] fallback mysql server
> 
> Hi,
> is there the option to use a fallback
> database server
> 
> i.e like
> 
> db_host = 192.168.125.1  192.168.125.2
> 
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

Re: [Sqlgrey-users] fallback mysql server

[Robert S. <ro...@sc...>]

Am 14.03.2011 07:27, schrieb Urban, Frank (GS-ITR):
> Hi,
> as far as I know only for a reading in Version 1.7.
> 
> read_hosts = 192.168.125.1,192.168.125.2

sorry does this mean there is only one db host for write but an option
to have 2 hosts for reading?

and if so what does sqlgrey do if the write host dissapear?
is there enough logic coded that there is no desaster output in that
case ...?
> 
> Greetings
> 
> Frank
> 
> -----Original Message-----
> From: Robert Schetterer [mailto:ro...@sc...] 
> Sent: Sunday, March 13, 2011 8:52 AM
> To: sql...@li...
> Subject: [Sqlgrey-users] fallback mysql server
> 
> Hi,
> is there the option to use a fallback
> database server
> 
> i.e like
> 
> db_host = 192.168.125.1  192.168.125.2
> 
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Sqlgrey-users] fallback mysql server

[Urban, F. (GS-ITR) <Fra...@co...>]

Hi,
as far as I know only for a reading in Version 1.7.

read_hosts = 192.168.125.1,192.168.125.2

Greetings

Frank

-----Original Message-----
From: Robert Schetterer [mailto:ro...@sc...] 
Sent: Sunday, March 13, 2011 8:52 AM
To: sql...@li...
Subject: [Sqlgrey-users] fallback mysql server

Hi,
is there the option to use a fallback
database server

i.e like

db_host = 192.168.125.1  192.168.125.2


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

[Sqlgrey-users] fallback mysql server

[Robert S. <ro...@sc...>]

Hi,
is there the option to use a fallback
database server

i.e like

db_host = 192.168.125.1  192.168.125.2


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Sqlgrey-users] sqlgrey v.s. postscreen

[Karl O. P. <ko...@me...>]

Hello,

I see that postfix 2.8.0 has a postscreen(8) daemon that
does a number of tests on inbound smtp connections,
including greylisting.  Has anyone had a chance to
come up with a feature comparison -- does sqlgrey
have any advantages over postscreen(8)?

http://www.postfix.org/postscreen.8.html

It looks as though postscreen(8) has a number of potentially useful
test related to smtp protocol violations, but it's also
impossible to turn off its greylisting so it would
be annoying to use in conjunction with sqlgrey.

Sqlgrey has worked exceedingly well for me over the years
and I've not had to think about it's operation.
The greylisting in postscreen(8) seems to be,
perhaps, more of a side effect of it's implementation;
although that may be a mistaken impression I've picked
up from a quick skim of the documentation.  There must
be some real pluses and minuses to both but I'm
too lazy to want to figure it out given that I've something
that works.  I'd love to hear an analysis.

Regards,

Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [Sqlgrey-users] Odd characters causing db crash

[Kenneth M. <kt...@ri...>]

On Thu, Jan 20, 2011 at 07:06:43AM +0000, Steve Heaven wrote:
> Early this morning our Postgres db crashed and restarted several times.
> In the logs I found this:
> 
> Jan 20 03:43:53 frigga sqlgrey: grey: from awl match: updating
> 71.81.141.83(71.81.141.83),
> s???nc...@18...(s???nc...@18...) 
> Jan 20 03:43:53 frigga sqlgrey: dbaccess: warning: couldn't do query:
> UPDATE from_awl SET last_seen = NOW(), first_seen = first_seen WHERE
> sender_name = 's???nchez85' AND sender_domain = '1800hurt911.com' AND src
> = '71.81.141.83': ERROR:  invalid byte sequence for encoding "UTF8":
> 0xe16e63 HINT:  This error can also happen if the byte sequence does not
> match the encoding expected by the server, which is controlled by
> "client_encoding". , reconnecting to DB 
> Jan 20 03:43:53 frigga sqlgrey: warning: Use of uninitialized value in
> concatenation (.) or string at /usr/sbin/sqlgrey line 1154. 
> Jan 20 03:43:53 frigga sqlgrey: dbaccess: error: couldn't access
> from_awl table:  
> 
> It looks like it crashed because the email address had a non UTF8
> character. What should the 'client_encoding' be set to?
> 
> We are running  sqlgrey 1.7.6 and postgresql  8.1.11
> 
> Thanks
> 
> Steve
> 

You will need to use SQL_ASCII or C encoding for the database
in initdb. Been there, done that, have the crash dump... :)

Ken

[Sqlgrey-users] Odd characters causing db crash

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

Early this morning our Postgres db crashed and restarted several times.
In the logs I found this:

Jan 20 03:43:53 frigga sqlgrey: grey: from awl match: updating
71.81.141.83(71.81.141.83),
s�nc...@18...(s�nc...@18...) 
Jan 20 03:43:53 frigga sqlgrey: dbaccess: warning: couldn't do query:
UPDATE from_awl SET last_seen = NOW(), first_seen = first_seen WHERE
sender_name = 's�nchez85' AND sender_domain = '1800hurt911.com' AND src
= '71.81.141.83': ERROR:  invalid byte sequence for encoding "UTF8":
0xe16e63 HINT:  This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
"client_encoding". , reconnecting to DB 
Jan 20 03:43:53 frigga sqlgrey: warning: Use of uninitialized value in
concatenation (.) or string at /usr/sbin/sqlgrey line 1154. 
Jan 20 03:43:53 frigga sqlgrey: dbaccess: error: couldn't access
from_awl table:  

It looks like it crashed because the email address had a non UTF8
character. What should the 'client_encoding' be set to?

We are running  sqlgrey 1.7.6 and postgresql  8.1.11

Thanks

Steve

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

Re: [Sqlgrey-users] IRS TaxPro automated email system needs added to whitelist

[Kenneth M. <kt...@ri...>]

On Thu, Nov 18, 2010 at 08:00:08AM -0600, Karl O. Pinc wrote:
> On 11/17/2010 03:30:33 PM, Douglas Mortensen wrote:
> > The IRS has an automated email that goes out to Professional
> > Independent tax preparers when they sign up on the IRS website. It
> > does not retry after SQLGrey initial defers them.
> 
> You could complain to the government.  They are
> in violation of rfc2821 (Simple Mail Transfer Protocol), 
> section 4.5.4.1: 
> 
>    "...mail that
>    cannot be transmitted immediately MUST be queued and periodically
>    retried by the sender."
> 
> An email couldn't hurt; otherwise they'll never fix it.  Have fun.  :)
> 
> 
> Karl <ko...@me...>
> Free Software:  "You don't pay back, you pay forward."
>                  -- Robert A. Heinlein
> 

We also document that for misconfigured mail systems, trigger the
notification twice far enough apart to pass the greylist service.
They will recieve the second notification. We also have an opt-out
feature that users can enable should they wish.

Cheers,
Ken

Re: [Sqlgrey-users] IRS TaxPro automated email system needs added to whitelist

[Karl O. P. <ko...@me...>]

On 11/17/2010 03:30:33 PM, Douglas Mortensen wrote:
> The IRS has an automated email that goes out to Professional
> Independent tax preparers when they sign up on the IRS website. It
> does not retry after SQLGrey initial defers them.

You could complain to the government.  They are
in violation of rfc2821 (Simple Mail Transfer Protocol), 
section 4.5.4.1: 

   "...mail that
   cannot be transmitted immediately MUST be queued and periodically
   retried by the sender."

An email couldn't hurt; otherwise they'll never fix it.  Have fun.  :)


Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: [Sqlgrey-users] How can I tell that local whitelists are being used

[Michal L. <ml...@lo...>]

  On 11/18/2010 08:02 PM, Dan Faerch wrote:
> Its possible to test sqlgrey by talking to it like posfix does, using
> telnet or netcat
>
> Example:
> $ nc localhost 2501
> request=smtpd_access_policy
> protocol_state=RCPT
> protocol_name=SMTP
> client_address=66.102.13.104
> client_name=unknown
> reverse_client_name=ez-in-f104.1e100.net
> helo_name=ez-in-f104.1e100.net
> sender=te...@ez...
> recipient=te...@ez...
> <  hit return to add a blank line>
>
> And the server will respond with its verdict:
> action=451 Greylisted for 1 minutes (10)
>
Actually there is a "tester.pl" script in the GIT repo for doing exactly 
this :)

~/src/sqlgrey-work.git> ./tester.pl --help
Test tool for SQLgrey daemon.
Author: Michal Ludvig <ml...@lo...> (c) 2009
         http://www.logix.net.nz
Usage: tester.pl --client-ip <address> [--options]
         --host          address to talk to (default: 127.0.0.1)
         --port          TCP port SQLgrey daemon listens on (2501)
         --client-ip     IP or IPv6 address of the 'client' (Required).
         --client-fqdn   Domain name corresponding to --ip
         --sender / --from
                         Envelop MAIL FROM value
         --recipient / --to
                         Envelop RCPT TO value

Michal