Re: [Sqlgrey-users] postgery to sqlgrey

[Farkas L. <lf...@bp...>]

Lionel Bouton wrote:
> Farkas Levente wrote the following on 12/14/04 18:08 :
> 
>>> [...]Anyway, with auto-whitelisting your users shouldn't notice much 
>>> of a delay. Just make the switch on Friday's evening and let the 
>>> marginal week-end trafic populate the auto-whitelist tables.
>>
>>
>>
>> that's not so easy! most of these important emails comes a few hours 
>> before deadlines (usualy thuesday 18:00 and thursday 18:00) which 
>> makes the think a bit complicated:-(
>>
> 
> Understandable, you might want to use an opt-in policy for greylisting. 
> Greylisting is a tradeoff that auto-whitelists can only make less 
> painfull to make. You should make your users aware that either :
> - you use greylisting for all of them which means that poorly configured 
> mail servers won't deliver in a timely manner (and some rare ones never) 
> but on the other hand their SPAM level is less than half that what it 
> could be (remember that asking the sender to resend the message will 
> solve the problem in most cases).
> - you use greylisting on an opt-in basis and they have to choose what 
> they consider more important : less SPAM or "instant messaging", their 
> choice, their responsibility.

as always they would like both:-) but currently that's the situation 
since in postgery's database most of our partner's email address is 
already included so there is no delay mostof the case, but if i start 
with a fresh/clean sqlgrey that the delay happend with all emails:-(((

>>> - if needed (sqlgrey can cope with database unavailability), 
>>> configure replication to a slave database.
>>
>>
>>
>> it is currently possible?
> 
> 
> 
> It depends on the database system. Currently SQLgrey only connects to 
> one database (which would be the master) though.

so currently can't configure a slave:-(

>>> If you use a slave database, you can either : make it take over the 
>>> master's IP, update the DNS to reroute sqlgrey connections to the 
>>> slave (my personnal choice - put low TTLs in the DNS - this way you 
>>> don't have to take the master fully down if only its database system 
>>> is down), or (if it can be made quickly) put the master back online.
>>
>>
>>
>> imho it'd be better to be able to configure more (slave) sql server 
>> for sqlgrey in stead of dns manipulation.
>>
> 
> I'm not sure I understand. Do you mean that SQLgrey should directly 
> access several servers and update all of them or do you want replication 
> done at the database level (SQLgrey being unaware of the process 
> replicating the master to the slaves) ?

no. first of all my main question:
   why do i worth to switch to sqlgrey (or any other greylist server) 
from postgrey?
in normal cicumstances all mx host should have to use the same greylist 
database otherwise the basic idea fail (delay can be too long). which do 
not means that every mx should use the same greylist server, but they 
have to use greylist servers which use the same database.
currently we use one postgrey server and all other mx connect to this 
postgrey server. but this is a sinlge point of failure! so the only 
reason what is see to switch to another greylist server to avoid this 
sinlge point of failure! but there is one more thing. the failure usualy 
not in the greylist server (like postgrey never stop if configured 
well), the critical part is the machine itself which runs the greylist 
server. there can be hardware problem and there can be network problem.
what i can image when we use an sql server as the database:
all mx use his own greylist server and all greylist server connect to 
the same sql server. but in this case the same sinlge point of failure 
exist! the sql server's machine! so therefore if i can configure more 
sqlserver for each greylist server and the sql server's replicate the 
database among eachother then the sinlge point of failure disappear! so 
that can be a reason to switch.

> The former is doable but will be quite complex : SQLgrey would have to 
> support adding an empty database to a farm of databases and populate the 
> tables of each database without data allowing the message to pass when 
> there's at least another database with data making SQLgrey decice to 
> accept it. This must be done at every step of the decision process 
> (valid previous connection attempt, e-mail auto-whitelist entry, domain 
> auto-whitelist entry).

imho replication is not the sqlgery's responsibility!

> If this is what you want, I'm afraid it should be another project : 
> SQLgrey current model is not the best suited for this, you'll want to 
> make the same request to different databases in // and wait for all of 
> them to complete or timeout, mark databases as faulty to avoid spending 
> time waiting for timeouts, ...

i hope my former explanation show what i want:-)

> In the latter case you want SQLgrey being aware of the fact that there 
> is a replication process occuring between several databases and one of 
> them is the master, you want to be ensure only one is in RW mode, this 
> one is known by SQLgrey and when it goes down an external process 
> decides which slave becomes the master and
> - do what's needed to reconfigure it as the master,
> - signal each SQLgrey server to use this new one.

don't go that far! it seems to me that you always assume the failuer at 
the sql server level. i repeat myself:
i trust in the sql server (never died), but i do not trust the machine 
and the network!
and that'we what i'd like to avoid! usualy tha't the main reason of 
slave servers:
- that's why there is more mx,
- that's why there is slave ldap servers,
- that's why there backup domain controllers on windows,
- a bit similar raid-1,5,6 (one or two disk can fail at the same time, 
but no more).
so if there is one master and in case of the failure of this (ie. not 
reachable the greylist can switch to another one which has the same (or 
almost the same) database (ie. relicated or replicated eg. in the last 
hour). that can be enough! the sysadm can recognize that can fix the 
problems (like fix the mx, ldap server, domain contorller or replace the 
failed disk in the above example).

> For that, I only see one thing needed on SQLgrey's side : modify SQLgrey 
> in order to allow on the fly reconnection to another database. The rest 
> is database specific.
> But I don't really see the benefit of making this so complex, usually 
> replicated databases come with what's needed to make a slave replace a 
> master by taking over its IP address. In this case SQLgrey will work 
> correctly out of the box.
 >
>> imho it's be enough to switch to the slave and the slave can replicate 
>> eg. once a day the master (before becoming the master)
> 
> 
> 
> I'm not sure I understand.

i hope you understand my main problem/requirements/wish about a greylist 
server. if still not than it can be because my bad english:-(
yours.

-- 
   Levente                               "Si vis pacem para bellum!"