[xmail] Re: Nolisting
It is indeed a poor mans greylisting. Real greylisting is however much more effective. Reasonably large amounts of spam is targeted directly at the backup mailserver and will come through. It doesn't seem have the drawback that greylisting has: possible large delays. But it did make me think of a possible solution for that in greylisting. What if you would have primary and secondary MX point to two different IP's on the same host. Both IP's do accept mail and run the same greylisting filter. Currently, greylisting will only start accepting mail from one sender if it retries (for example) 15 or more minutes after the first attempt. And MTA's can take much longer before doing a second attempt on the same MX. With both MX's pointing to one machine (two IP's), we could instruct Greylisting to accept mails without delay if we have first seen an attempt on the primary IP, and now get one on the sencondary. XMailserver has a *LOCALADDR-variable that will help with this.* If the information on that site is correct, then most MTA's would retry on the second MX almost instantly after trying on the first one. So there basically is hardly any delay. Do take into account that the delay does also has its benefits. Spam that is delayed, is more likely to be captured by an other filter (blacklist, Pyzor, Razor, DCC, ...). Any thoughts? Sincerely, Bart Mortelmans Filip Supera wrote: Hello, Just heard about this in the Spamtools mailing list : http://www.joreybump.com/code/howto/nolisting.html Any thought ? - 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: Nolisting
Currently, greylisting will only start accepting mail from one sender if it retries (for example) 15 or more minutes after the first attempt. And MTA's can take much longer before doing a second attempt on the same MX. With both MX's pointing to one machine (two IP's), we could instruct Greylisting to accept mails without delay if we have first seen an attempt on the primary IP, and now get one on the sencondary. XMailserver has a *LOCALADDR-variable that will help with this.* If the information on that site is correct, then most MTA's would retry on the second MX almost instantly after trying on the first one. So there basically is hardly any delay. If the primary MX is accepting connections and telling it to try again later, don't SMTAs try the primary again before sending to a secondary, hence the need for the RST packet in the firewall in the nolisting info ? I might be totally wrong about that, but I was thinking the secondary was only used when the primary was unreachable or returning fatal errors ? Greylisting is working great for me, using it with spamassassin + ocr plugin + white and black lists + a few dnsrbls and i rarely get spam anymore. One thing that helps is I have a perl script that tails the maillog (created by the filter script) and watches for two email attempts from the same ip to the same rcpt email address but from different senders in any given 5 minute time frame and auto-blacklists them. Indeed the delay in greylisting is the only thing I don't like about the setup (like password retrieval from a forum or something). ~darren - 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: Nolisting
If the primary MX is accepting connections and telling it to try again later, don't SMTAs try the primary again before sending to a secondary, hence the need for the RST packet in the firewall in the nolisting info ? I might be totally wrong about that, but I was thinking the secondary was only used when the primary was unreachable or returning fatal errors ? When an MTA get a fatal error (5xx) it normally shouldn't try again at all, also not on the secondary MX. A fatal error can for example by recipient unknown. I don't know if there is a difference between the retry-schedule for no response from the primary MX, or a temporary error (4xx). I would assume that most MTA's would handle both the same way, but haven't tested this yet. Sincerely, Bart Mortelmans - 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: config files discussion
On Mon, 19 Feb 2007, Dave Henderson wrote: Gang, I have not used xmail very much (or any email daemon for that matter) but had a question regarding the configuration files for xmail. I noticed that it uses several many different files and wondered if there was ever going to be any type of consolidation into, say, an Apache style config file. What are the pro's and con's to that approach? Is this an idea that any one else shares? Files in a folder are easier to spot than sections inside a huge configuration blob. Updating a specific 4 lines config file, does not require a lock over the whole config file. No, that's really not a good idea. And it'd have had to be a *really* good one, in order to change all over the code and break compatibility with the install base. - 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: Nolisting
On Tue, 20 Feb 2007, Filip Supera wrote: Hello, Just heard about this in the Spamtools mailing list : http://www.joreybump.com/code/howto/nolisting.html Any thought ? HitRun spammers are already caught by greylisting, that is simpler to setup. The ones using real MTAs would be caught by both. - 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: config files discussion
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Davide Libenzi Envoy=E9 : mardi 20 f=E9vrier 2007 16:28 =C0 : 'xmail@xmailserver.org' Objet : [xmail] Re: config files discussion On Mon, 19 Feb 2007, Dave Henderson wrote: Gang, I have not used xmail very much (or any email daemon for=20 that matter) but had a question regarding the configuration=20 files for xmail. I noticed that it uses several many=20 different files and wondered if there was ever going to be any=20 type of consolidation into, say, an Apache style config file. =20 What are the pro's and con's to that approach? Is this an=20 idea that any one else shares? Files in a folder are easier to spot than sections inside a huge=20 configuration blob. Updating a specific 4 lines config file, does not=20 require a lock over the whole config file. No, that's really=20 not a good=20 idea. And it'd have had to be a *really* good one, in order to=20 change all=20 over the code and break compatibility with the install base. - Davide I agree with Davide, with exception for the cmd line parameters, as = these are the only 'external' parameters not in xmailroot but in deamon start script or registry (win32), that could be centralized in server.tab = file, keeping them usable on the cmd line to overwrite the server.tab = equivalent. Davide never respond to this request :( - 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: config files discussion
On Tue, 20 Feb 2007, Dave Henderson wrote: Davide, Thanks for your reply. I can see your points. It was just a question I had as it seems alot of the daemons I use, use the apache style or a single config file method. The daemons also don't lock the files when reading them, they just read them upon startup (of course) and re-read them automatically within a certain period of time (to check for any changes made to them). I suppose both styles have their strengths and weaknesses. In either case, thanks for the reply. I'm not an heavy Apache user (actually, I use thttpd ;) but IIRC Apache is going in the exact opposite direction (splitting configs). - 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: config files discussion
On Tuesday 20 February 2007 12:32, Davide Libenzi wrote: On Tue, 20 Feb 2007, Dave Henderson wrote: Davide, Thanks for your reply. I can see your points. It was just a question I had as it seems alot of the daemons I use, use the apache style or a single config file method. The daemons also don't lock the files when reading them, they just read them upon startup (of course) and re-read them automatically within a certain period of time (to check for any changes made to them). I suppose both styles have their strengths and weaknesses. In either case, thanks for the reply. I'm not an heavy Apache user (actually, I use thttpd ;) but IIRC Apache is going in the exact opposite direction (splitting configs). In recent openSUSE releases httpd.conf is nothing more than comments and Include statements. All the actual configuration is divided up amongst the Included config files and directories. Most of the user configuration is in vhost containers that each have a vhostname.conf file in the vhosts.d directory. It takes a little getting used to but the design is actually very nice once you see how it works. Jeff - 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]
