[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: Nolisting
>-Message d'origine- >De : [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] la part de Bart Mortelmans >Envoy=E9 : mardi 20 f=E9vrier 2007 12:17 >=C0 : xmail@xmailserver.org >Objet : [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 ? >> =20 > >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=20 >"recipient unknown". Absolutly, fatal error codes 5xx (that means there was a successfull connexion to remote mx) have the effect to stop any try, and return a = ndr to the sender. > >I don't know if there is a difference between the=20 >retry-schedule for no=20 >response from the primary MX, or a temporary error (4xx). I=20 >would assume=20 >that most MTA's would handle both the same way, but haven't=20 >tested this yet. In theory, rfc don't say anything, so it make sense that a 'retry' is = not to be considered as a 'retry' except for the retry count, so the server = have to redo all tries as if the mail was just send first time (redo mx lookup, = mx test one by one, ...) No connexion to an mx IS NOT to be count as a retry, and each mx try is = in the same 'atomic' send > >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] > - 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 ? Hit&Run 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: Nolisting
On Tue, 20 Feb 2007, Davide Libenzi wrote: > 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 ? > > Hit&Run spammers are already caught by greylisting, that is simpler to > setup. The ones using real MTAs would be caught by both. s/would/won't/ - 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]
