[xmail] Re: GLST on secondary server
Thank you for the answer Davide. That basically means that as long as a source address sends e-mail, the entry will immediately pass through the greylisting. I know, I know, I should have read the man pages, but wasn't anywhere near a machine to access the server... :) Thus, the 30 day expiry time is excessive overkill, and possibly a 14 day window might be better under normal operating conditions. In this particular case of our server, I am going to leave it, as it is a low volume private type server, rather than commercial. Thursday, June 22, 2006, 8:26:26 AM, you wrote: On Mon, 19 Jun 2006, Jorn Hass wrote: I am not sure if an incoming mail resets the date-stamp as it comes in, back to the original 30 days, or wether the time-stamp just gets left to the initial access. In which case it would mean that the stream mail would never expire. Davide can possibly confirm/deny that... From the GLST man page: --exptimeo NSEC Specify the expire timeout for triplets that have been successfully accepted by the glst module. Every time a triplet is accepted (the remote mailer retried after the blackout window set with --timeo) the count of successfully accepted messages is increased, and the record timestamp is updated with the current time. During cleanup, if the timestamp is found older that the current time minus the timeout specified with --exptimeo, the record (triplet plus record metadata) is purged from the glst database. -- Best regards, Jornmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
Thus, the 30 day expiry time is excessive overkill, and possibly a 14 day window might be better under normal operating conditions. In this I usually use 36 days. There is lot of newsletters and digests and so on, which are issued with monthly periodicity. -- Michal A. Valasek | Chief Software Architect of Altairis LLC, ASP.NET MVP PGP 0xC4F3579D | www.altairis.cz | www.rider.cz | www.aspnet.cz You can have peace. Or you can have freedom. Don't ever count on having both at once. (Lazarus Long) - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
On Mon, 19 Jun 2006, Jorn Hass wrote: I am not sure if an incoming mail resets the date-stamp as it comes in, back to the original 30 days, or wether the time-stamp just gets left to the initial access. In which case it would mean that the stream mail would never expire. Davide can possibly confirm/deny that... From the GLST man page: --exptimeo NSEC Specify the expire timeout for triplets that have been successfully accepted by the glst module. Every time a triplet is accepted (the remote mailer retried after the blackout window set with --timeo) the count of successfully accepted messages is increased, and the record timestamp is updated with the current time. During cleanup, if the timestamp is found older that the current time minus the timeout specified with --exptimeo, the record (triplet plus record metadata) is purged from the glst database. - Davide - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Davide Libenzi Envoyé : samedi 17 juin 2006 18:20 À : 'xmail@xmailserver.org ' Objet : [xmail] Re: GLST on secondary server On Fri, 16 Jun 2006, CLEMENT Francis wrote: Simple way is to share the same base for the two servers. Primary xmail server with glst database and it shares (nfs, ...) the glst directory on secure backoffice network (or with ssl/stunnel/vpn, ) Secondary xmail server glst points to this share. I can't say I'd recomend using GDBM over NFS. GDBM is a nice, small, zero-setup DB API, but it doesn't fit sharing over NFS very well. - Davide It's globaly what I said with : 'Don't ask me about reliability and possible timeouts ... I did test this setup at this time :)' So, best way seems to be a glst version using a sort of sql server, or a glst client/server model (like spamd/clamd, ...) Francis - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
Hi All... Ok, so there has been various comments around this. As you wish to LIMIT delays on valid incoming, what you need to do is keep your expire time-out on the database as long as possible. My settings are as follows: # 10 minutes timeo=600 # 30 days... exptimeo=2592000 # 2 hour lametimeo=7200 This effectively means that if any e-mail does not re-enter the server in 2 hours, the entry gets moved to the lameroos... This might be overzealous, but works for this instance. If it does re-enter, it will be kept in the database for 30 days, Before expiring, effectively causing a re-check every 30 days on regular mails. So if there is a stream of mail, that comes in regularly, it will be immediate, but once a month it will be forced through the grey-listing again. This is the one you want to extend considerably should you want to ensure minimum delays. I am not sure if an incoming mail resets the date-stamp as it comes in, back to the original 30 days, or wether the time-stamp just gets left to the initial access. In which case it would mean that the stream mail would never expire. Davide can possibly confirm/deny that... Even so, a 30 day re-prompt is valid enough for me... As I run a cron doing the cleanup every two hours, a lamer entry could become as old as 2 hours 59 minutes, which is not an issue to me... Not much difference either or... As to the secondary server, do the same. The chances are that an email might hit both, which makes it a double delay. Some percentage somewhere along the line... But, once it is in either of the two, that server will accept it immediately. You then need to make sure that you use an xnet on the primary for the secondary server, to make sure there is not an added greylisting delay. Seeing as the secondary should be trusted anyway, that is a good thing to do. As a caveat on that, spammers tend to use the secondary MX only, in the hope that it does not have a recipient list, and will blindly accept for the domain, to pass it on, making it the problem of the secondary server to deal with bounces... As they get paid per e-mail sent, they don't care how it's sent, or if it bounces after the fact that they have delivered it... I have a few XNET entries in my file, including the xmalserver.org and our fax sources, to prevent any unnecessary delays. So, if you have sources that you know don't source spam, add an XNET to speed things up... -- Best regards, Jornmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
On Fri, 16 Jun 2006, CLEMENT Francis wrote: Simple way is to share the same base for the two servers. Primary xmail server with glst database and it shares (nfs, ...) the glst directory on secure backoffice network (or with ssl/stunnel/vpn, ...) Secondary xmail server glst points to this share. I can't say I'd recomend using GDBM over NFS. GDBM is a nice, small, zero-setup DB API, but it doesn't fit sharing over NFS very well. - Davide - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
Simple way is to share the same base for the two servers. Primary xmail server with glst database and it shares (nfs, ...) the glst directory on secure backoffice network (or with ssl/stunnel/vpn, ...) Secondary xmail server glst points to this share. Don't ask me about reliability and possible timeouts ... I did test this setup at this time :) - For the glst cleanup procedure, and shared database. You can create a single batch doing stop/clean/start on only primary server if it can execute remote commands on secondary (rsh, ...) to stop and restart secondary xmail: 1 stop local (primary) xmail 2 stop secondary xmail remotely 3 only if you are sure secondary is stopped, do glst cleanup 4 restart secondary xmail remotely 5 restart local xmail Second option if remote sh not available : schedule two batchs on first and second servers at same time to : First server batch : 1- stop local xmail 2- create a 'primarystoppedforcleanup' flag file in glst database dir to confirm to secondary that its time to stop xmail 3- wait until a 'secondarystoppedforcleanup' flag file exist in glst database dir to confirm secondary is stopped (need a sort of timeout to skip cleanup, go to step 5 directly, in case secondary didn't start cleanup batch at all ...) 4- do the glst cleanup 5- delete primarystoppedforcleanup flag file in glst database dir. this mark the end of cleanup 6- restart local xmail Secondary server batch : 1- wait until primarystoppedforcleanup exist in glst database dir (need a sort of timeout to simply exit batch in case primary didn't start cleanup batch at all ...) 2- stop local xmail 3- create 'secondarystoppedforcleanup' flag file to fire real cleanup on primary 4- wait until primatystoppedforcleanup file is deleted by primary (need a sort of timeout to continue, step 5, in case primary didn't start cleanup batch at all or didn't delete flag file ...) 5- delete secondarystoppedforcleanup 6- restart local xmail More complicated as you need to use sort of synchronisation to avoid stopping definitively one or the two xmail ... (here syncho with files used as semaphores/flags) Francis -Message d'origine- De: [EMAIL PROTECTED] A: xmail@xmailserver.org Date: 15/06/06 18:17 Objet: [xmail] Re: GLST on secondary server it should read I **dont** want to get big delay in mail delivery. Hi! What is the best way to implement the GLST on a secondary mail server? I want to get big delay in mail delivery. What is the recommended GLST database cleanup procedure and how often should it be done? Matic - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
[xmail] Re: GLST on secondary server
it should read I **dont** want to get big delay in mail delivery. Hi! What is the best way to implement the GLST on a secondary mail server? I want to get big delay in mail delivery. What is the recommended GLST database cleanup procedure and how often should it be done? Matic - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe xmail in the body of a message to [EMAIL PROTECTED] For general help: send the line help in the body of a message to [EMAIL PROTECTED]
