Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Tonnerre Lombard wrote: Salut, Marco, On Mon, 20 Oct 2008 14:15:41 +0200, Marco Fretz wrote: What I'm trying to say is: As a mail service provider (recipient side) you can use greylisting and if there are some buggy mailers out there in the internet (or in your local network) it's not a greylisting problem and it's not your problem. they have to fix there mailer problems (sender side). it's not the ISP who has to adapt mail services to buggy customer stuff ^^ Or maybe you just didn't listen... ...and maybe we should stop discuss this :-) Tonnerre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Hi Tonnerre, You got me wrong :-) What I'm trying to say is: As a mail service provider (recipient side) you can use greylisting and if there are some buggy mailers out there in the internet (or in your local network) it's not a greylisting problem and it's not your problem. they have to fix there mailer problems (sender side). it's not the ISP who has to adapt mail services to buggy customer stuff ^^ A mailer script which doesn't support queueing or in other words RFC-conform MTA operation will cause problems anyway regardless if greylisting is used or not, other 4xx codes, etc... maybe my opinion is very radical but I think it's the way it should be. Of course I know there are exceptions with individual customer situations, etc. bests Marco Tonnerre Lombard wrote: Salut, Marco, On Fri, 17 Oct 2008 15:21:59 +0200, Marco Fretz wrote: Of course I know what you mean. That's the thing every webhoster have to fight with. Last year I was on the Secure Linux Admin Conference in Berlin. There was a workshop how to protect shared hosting webservers... I am talking about the recipient side. I don't think it's a safe assumption that all scripts _your_ _mail_ _users_ will receive mail from are under your control. If I remember correctly the 2nd or 3th step was: prevent the users from using SMTP (or any other port) to the internet and only allow the destination you choose, your mailrelay servers, http proxy, etc. That is great, but not everyone does that. In fact the number of providers which do that is fairly low. I would do so myself, also for the reason that this prevents people owning a web service to spam around in a volatile manner, but that's not the point at all. crap customer scripts don't look like a reasonable argument against greylisting to me. though some webhosting customers might send mails with their mailer script to recipients which are not on your mail server and this other mail server maybe is also protected with greylisting, ergo same problem ergo problem not solved... For the receiving server, it is. do you see what I mean, now? :) or maybe I didn't fully understand the issue you had. No, you don't. but agreed it's always hard to decide if you want secure systems or happy users. That would be true if there was no way around greylisting, but there is. Tonnerre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Marco, On Mon, 20 Oct 2008 14:15:41 +0200, Marco Fretz wrote: What I'm trying to say is: As a mail service provider (recipient side) you can use greylisting and if there are some buggy mailers out there in the internet (or in your local network) it's not a greylisting problem and it's not your problem. they have to fix there mailer problems (sender side). it's not the ISP who has to adapt mail services to buggy customer stuff ^^ Or maybe you just didn't listen... Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
On the Fri, Oct 17, 2008 at 12:06:45AM +0200, Tonnerre Lombard blubbered: Hallo. This is basically the collision between lazy technicians coming up with excuses why they're not responsible and stupid users who cannot do things right. I'm afraid that the purely technical point of view is not worth a dime if your users look for alternative providers. What do you do, when customers are quitting their contracts because they think they receive too much spam? Which of the two groups will it be for you? CU, Venty -- What we're planning here is World Domination! ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Martin, On Fri, 17 Oct 2008 10:18:31 +0200, Martin Ebnoether wrote: What do you do, when customers are quitting their contracts because they think they receive too much spam? Which of the two groups will it be for you? You're falsely implying that greylisting is the only way to fight SPAM. In fact, I don't receive much SPAM at all due to my strategies, none of which prevent the newsletters people subscribe to. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Tonnerre Lombard wrote: Salut, Marco, On Thu, 16 Oct 2008 15:22:39 +0200, Marco wrote: fully agreed. thats a bad argument against greylisting. if php scripts or other webserver stuff, like newsletter servers, etc.. use their own MTA which is most likely a fancy carp script, as you said, then its actually not the ISPs problem if a mail won't get delivered. Technically, this is perfectly right, and personally I would like to see everyone writing such scripts burn in hell. But if your users insist on receiving the mail, you will either have to disable greylisting or to get a better set of customers. Another option is to disable greylisting just for that one mailserver. /Per Jessen, Herrliberg ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Tonnerre Lombard wrote: Salut, Marco, On Thu, 16 Oct 2008 15:22:39 +0200, Marco wrote: fully agreed. thats a bad argument against greylisting. if php scripts or other webserver stuff, like newsletter servers, etc.. use their own MTA which is most likely a fancy carp script, as you said, then its actually not the ISPs problem if a mail won't get delivered. Technically, this is perfectly right, and personally I would like to see everyone writing such scripts burn in hell. But if your users insist on receiving the mail, you will either have to disable greylisting or to get a better set of customers. This is basically the collision between lazy technicians coming up with excuses why they're not responsible and stupid users who cannot do things right. I'm afraid that the purely technical point of view is not worth a dime if your users look for alternative providers. Do you see what I mean? Of course I know what you mean. That's the thing every webhoster have to fight with. Last year I was on the Secure Linux Admin Conference in Berlin. There was a workshop how to protect shared hosting webservers... If I remember correctly the 2nd or 3th step was: prevent the users from using SMTP (or any other port) to the internet and only allow the destination you choose, your mailrelay servers, http proxy, etc. Our customers cannot send mails directly, no way. The have to use local sendmail. Out of 50 of our webhostings there was 1 using such carp mailer scripts. we forced them to change it because no other good provider will allow it anyway (of course a lot do so but maybe the shouldn't :-)) My opinion is still that greylisting is a good thing against spam but as you said not the only one. crap customer scripts don't look like a reasonable argument against greylisting to me. though some webhosting customers might send mails with their mailer script to recipients which are not on your mail server and this other mail server maybe is also protected with greylisting, ergo same problem ergo problem not solved... do you see what I mean, now? :) or maybe I didn't fully understand the issue you had. but agreed it's always hard to decide if you want secure systems or happy users. Der Kunde ist König? actually he is but not always, we want to satisfy our customers but we are also responsible that systems are secure, do what the should do, etc.. if his buggy script or what ever possibly compromises my systems I usually tell that to our customers and more often than not they do not cancel any contracts due to my explanation that we want to have secure systems. Are you at SwiNOG next week, too? And interesting topic, isn't it? :) nice weekend, Marco Tonnerre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
On Wednesday 15 October 2008, Tonnerre Lombard wrote: [..] Not very problematic for the mail server but of course the PHP script does _not_ attempt redelivery. And your users go to gmail, because there they get the mail. Not sure that's desirable for you. This whole discussion is pointless. Greylisting is a religion. The believers worship it, the others damn it. The realy important point is: Greylisting is a just using a mechanism that should get going when something is goes wrong accepting a message. This mechanics of retransmitting should not only take action with greylisting involved but (and that is the important point) when there appears a real technical problem. And that is something a customer with his little online shop will show open ears to you explaining him why to change his mailer script. have fun Michi ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Michael Naef wrote: On Wednesday 15 October 2008, Tonnerre Lombard wrote: [..] Not very problematic for the mail server but of course the PHP script does _not_ attempt redelivery. And your users go to gmail, because there they get the mail. Not sure that's desirable for you. This whole discussion is pointless. Greylisting is a religion. The believers worship it, the others damn it. The realy important point is: Greylisting is a just using a mechanism that should get going when something is goes wrong accepting a message. This mechanics of retransmitting should not only take action with greylisting involved but (and that is the important point) when there appears a real technical problem. And that is something a customer with his little online shop will show open ears to you explaining him why to change his mailer script. that's exactly what I was trying to say in my last post :-) thank you Michi... have fun Michi ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Per, On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote: Another option is to disable greylisting just for that one mailserver. This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Marco, On Fri, 17 Oct 2008 15:21:59 +0200, Marco Fretz wrote: Of course I know what you mean. That's the thing every webhoster have to fight with. Last year I was on the Secure Linux Admin Conference in Berlin. There was a workshop how to protect shared hosting webservers... I am talking about the recipient side. I don't think it's a safe assumption that all scripts _your_ _mail_ _users_ will receive mail from are under your control. If I remember correctly the 2nd or 3th step was: prevent the users from using SMTP (or any other port) to the internet and only allow the destination you choose, your mailrelay servers, http proxy, etc. That is great, but not everyone does that. In fact the number of providers which do that is fairly low. I would do so myself, also for the reason that this prevents people owning a web service to spam around in a volatile manner, but that's not the point at all. crap customer scripts don't look like a reasonable argument against greylisting to me. though some webhosting customers might send mails with their mailer script to recipients which are not on your mail server and this other mail server maybe is also protected with greylisting, ergo same problem ergo problem not solved... For the receiving server, it is. do you see what I mean, now? :) or maybe I didn't fully understand the issue you had. No, you don't. but agreed it's always hard to decide if you want secure systems or happy users. That would be true if there was no way around greylisting, but there is. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Michael, On Fri, 17 Oct 2008 15:40:18 +0200, Michael Naef wrote: And that is something a customer with his little online shop will show open ears to you explaining him why to change his mailer script. That's illusionary. Most of the time they don't care about the one or two customers you at $technically_intelligible_isp have. They care about gmail and hatemail because they are the large ones. Your two customers just don't cover the cost of changing the running system. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source. It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive. so, basically as we discussed it already last week in regards to Skype: use the right tools for the right task :-) - Original Message From: Tonnerre Lombard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: swinog@lists.swinog.ch; [EMAIL PROTECTED] Sent: Friday, October 17, 2008 5:27:10 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?) Salut, Per, On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote: Another option is to disable greylisting just for that one mailserver. This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM. Tonnerre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Tonnerre Lombard wrote: Salut, Per, On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote: Another option is to disable greylisting just for that one mailserver. This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM. Very true - I guess we're fortunate that our customers do tell us about such problems. We actively maintain a list of not-to-be-greylisted servers, plus of course we do auto-whitelisting. /Per Jessen, Herrliberg ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Hi Tonnerre On Friday 17. October 2008, Tonnerre Lombard wrote: [..] That's illusionary. Most of the time they don't care about the one or two customers you at $technically_intelligible_isp have. Did you realize that I'm not talking about greylisting but _real_ 4xx? They care about gmail and hatemail because they are the large ones. Your two customers just don't cover the cost of changing the running system. I had the completly different experience dozens of times. If you explain them, that this way they can't be sure (as sure as one can be using email) that their mail reaches the recipient, they'll change with allmost no exception! don't know about your customers and will to explain such problems but if you take your time it works quite good. have fun Michi ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
...and beside that, is really strange that 90% of the professional spam cleaner (I'm talking about services not appliances) extensively use greylisting. I'm using greylisting (with some self made scripts to auto learn to withe and blacklist) since 2 1/2 years and I never missed a single mail. Someone said that greylisting is a religion. No, it's not. It's just a pretty effective method of keep the spam out. There are lot of tools, scripts and applications to do that but most of them are quite cpu intensive. 98% of the incoming spam is catched by the greylisting engine with almost zero cpu, only the remaining 2% need to be analyzed. And so fair as I am, I also put a notice in the 450 and 554 error code explaining why it is delayed or rejected. That's not true for notorious spammers which will hangs for hours in my tarpit (and thus saving some other people from being spammed). I know that spammers don't cares about logs but I expect a serious mail-admin does (at least the non M$ admins) and can react on it. As long as the internet community does not efficiently fight spam at the source I will put my efforts on fighting spam at the destination ! My personal opinion is that no consumer hoster or ISP (xDSL/Docsis) should allow their customers to send SMTP directly (beside some exceptions). Just a matter of keep the mess out of the net. We all know that most of the spam comes from bot pc which are on residential access. I guess that if every ISP would apply a mandatory SMTP-relay we would have at least 70% less spam ! And now I stop before we start another never ending flame-up discussion :-) Stanislav Sinyagin wrote: actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source. It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive. so, basically as we discussed it already last week in regards to Skype: use the right tools for the right task :-) - Original Message From: Tonnerre Lombard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: swinog@lists.swinog.ch; [EMAIL PROTECTED] Sent: Friday, October 17, 2008 5:27:10 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?) Salut, Per, On Fri, 17 Oct 2008 12:47:48 +0200, Per Jessen wrote: Another option is to disable greylisting just for that one mailserver. This implies that either you know all servers hosting broken scripts (NP-complete I think) or your customers will always communicate problems. Usually they encounter them and rant about it on their Stammtisch and then change provider to someone with one hell of a lot of SPAM. Tonnerre ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog -- This message has been scanned for viruses and dangerous content by MailGate, and is believed to be clean. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Stanislav, On Fri, 17 Oct 2008 08:42:49 -0700 (PDT), Stanislav Sinyagin wrote: actually greylisting works pretty well, and the whitelist of exceptions is relatively small (not more than 300 entries as far as I remember). Also if you communicate the value of it to the customers, they tend to agree that having 90% of spam filtered before entering the system is worth waiting for half an hour for email from a new source. They don't care as long as they receive all mails they want to. It's also a matter of resources: if you don't want or cannot enable greylisting, you have to invest more resources into a more sophisticated mail filtering software. Even if it's available for free, still developing and maintaining your solution might become too expensive. I've found a different method to be at least equally time-saving: rejecting SPAM rather than accepting and deleting it. The basic dialog looks about like this: Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) In: HELO gurgel.org Out: 250 planck.ngas.ch In: MAIL FROM: [EMAIL PROTECTED] Out: 250 2.1.0 Ok In: RCPT TO: [EMAIL PROTECTED] Out: 250 2.1.0 Ok In: DATA Out: 354 End data with CRLF.CRLF In: [...] In: . Out: 550 Keep your SPAM to yourself. The scheme doesn't look as great as it works. The end result is that the spammer learns that the address is not reachable (because permanent errors are usually received for non-existent addresses) and won't retry as frequently as for others. This keeps the level of incoming SPAM really low. In addition, it has the great advantage that if a sender really happens to fall into the false positive trap, he will discover it immediately by receiving a mail from his own mail server saying that the mail could not be delivered, rather than to notice after days that the other end has deleted or never read the mail. Greetings from inside the Grenchenbergtunnel, Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Daniele, On Thu, 16 Oct 2008 00:05:38 +0200, Daniele Guazzoni wrote: You'd rather blame the lazy programmers who don't cares about RFCs and other standards ! I think that blame is for people who don't care about solutions. I care for my users and their ability to receive the mail they want, as long as it is reasonable. While I do think that these scripts are broken and terribly wrong, I have no power over their programmers and cannot make them change the scripts. I, however, also don't have the authority to tell my users not to want to receive that newsletter. So you see, what I am saying is that greylisting prevents users from receiving these mails, not that these mails are good or correctly sent. But being a solution oriented provider, this is a clear reason why I cannot use greylisting. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Salut, Marco, On Thu, 16 Oct 2008 15:22:39 +0200, Marco wrote: fully agreed. thats a bad argument against greylisting. if php scripts or other webserver stuff, like newsletter servers, etc.. use their own MTA which is most likely a fancy carp script, as you said, then its actually not the ISPs problem if a mail won't get delivered. Technically, this is perfectly right, and personally I would like to see everyone writing such scripts burn in hell. But if your users insist on receiving the mail, you will either have to disable greylisting or to get a better set of customers. This is basically the collision between lazy technicians coming up with excuses why they're not responsible and stupid users who cannot do things right. I'm afraid that the purely technical point of view is not worth a dime if your users look for alternative providers. Do you see what I mean? Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
[EMAIL PROTECTED] wrote: Am 11 Sep 2008 um 5:17 hat Stanislav Sinyagin geschrieben: Greylisting only delays mails. Proper spammers just use ISP relays and how about registering on an page and waiting for the accept email for hours because your ISP do graylisting ? taking a relax and drink some beers till the server forwards you the expected email will lead to alcoholism ;-) we made the experience that not greylisting itself is the problem. the problem are miss configured mailservers with wrong queue times or servers interpreting the greylisting temp error code as an error. on your backup mx servers a greylisting time of 2-5 minutes reduced 98% of incoming spam. our customer didn't notice that. of course it was only on our backup mx and relay servers. i've to see what effect it has when we implement if on regular mailservers... marco Roger ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Daniel Kamm wrote: There are times, where the sending MTAs queue size is far to big for the MTA to meet the queue times. I saw such problems multiple times. When graylisting is configured for too short acceptance time, you will have messages, which won't be transmitted. # How long will the greylist database retain tuples. timeout 5d This is the default for the milter-greylist-port in FreeBSD. Maybe on very heavy loaded servers You have to go back. But even 12hrs should be big enough for very big queues. I think this is your idea of short acceptance time? Or are there other parameters I am missing? For me, the main factor is the greylist time. There is defined, how long NOT to recieve a mail for a touple. # How long a client has to wait before we accept # the messages it retries to send. Here, 1 hour. # May be overridden by the -w greylist_delay command line argument. greylist 5m but normally this is not the problem... (There are still problems with greylist... but there are greater problems without ;-) Beat ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
On Oct 15, 2008, at 11:01 AM, Marco wrote: we made the experience that not greylisting itself is the problem. the problem are miss configured mailservers with wrong queue times or servers interpreting the greylisting temp error code as an error. There are times, where the sending MTAs queue size is far to big for the MTA to meet the queue times. I saw such problems multiple times. When graylisting is configured for too short acceptance time, you will have messages, which won't be transmitted. My 0.015€. - Dan ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Am 11 Sep 2008 um 5:17 hat Stanislav Sinyagin geschrieben: Greylisting only delays mails. Proper spammers just use ISP relays and how about registering on an page and waiting for the accept email for hours because your ISP do graylisting ? taking a relax and drink some beers till the server forwards you the expected email will lead to alcoholism ;-) Roger ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
I think that server (coloured) lists are but an easy way out for for those who either aren't willing or able to do spam mail feature analysis. Spam is spam, even when it comes from a respectable server that has been temporarily compromised. All the up-and-coming premium spam services shy away from them, which is correct and proper. Maybe shying away from ISPs that use them would be correct and proper as well. Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 11, 2008 3:07 PM To: [EMAIL PROTECTED] Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?) Am 11 Sep 2008 um 5:17 hat Stanislav Sinyagin geschrieben: Greylisting only delays mails. Proper spammers just use ISP relays and how about registering on an page and waiting for the accept email for hours because your ISP do graylisting ? taking a relax and drink some beers till the server forwards you the expected email will lead to alcoholism ;-) Roger ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Jeroen Massar schrieb: Marc SCHAEFER wrote: [..] I am a heavy users of those RBL lists, they offer quite a bit of protection (but not as much as you might think, and with You should use RBL's only for *scoring*; not for decision making and then directly rejecting based on it. In Switzerland, you can whitelist most of the known-good (dynamic) IP address ranges (and important mailservers) quite easily with a mixture of the list provided by the swinog-RBL and some historic data. There rest is dealt with a few customer-support tickets. That's the beauty of Switzerland - it's so small ;-) Rainer ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Am 11.09.2008 um 20:28 schrieb [EMAIL PROTECTED]: great idea, whitelisting every system on the world which sends confirmation email .. it will be an big efford for that small country to convince the rest of the world ;-) To be precise: I use dnsbl.sorbs.net to blacklist all dynamic IPs (and the RBL from spamcop, and also the swinog RBL - I would use spamhaus, but they blocked us because we make too many requests and we can't afford their prices). Then, I use the list on the SWINOG-RBL homepage to whilelist all the swiss dynamic IPs (and some other big systems, plus various IPs clients requested us to whitelist over the years) - because those are the one's that may actually want to relay through our system or send us mail legitimately. senderbase.org helps finding IPs of outbound relays, too. I don't use greylisting - IMO, it's a system that doesn't work large- scale, in a similar way TMDA or other please reply to this email or click on this link-systems don't work in practise. To be vaguely on topic - most of our customers have static IPs, and it's not a problem to set the PTR to another value. But we also don't boast 10+ customers, like www.green.ch does - maybe they're afraid of having to change 100k PTRs, if they set a precedent? ;-) IT would be so easy - it's just users and customers that make it difficult :-))) Rainer ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
Stanislav Sinyagin schrieb: I don't know anything about proper spammers. Greylisting has reduced the amount of incoming spam significantly, probably at 90-95%. Of course there are spambots which play around greylisting, but they aren't yet that widely used. Agreed. For my mail system at business i have at the moment a high amount of blocked mails by greylisting, swinog list and some other RBL lists. At the beginning of this week we had a high amount of blocked mails. Reason was probably a new wave of spam bot mails. Without the blocking system our mail gateway wouldn't be able to process the load. And no we don't have any complains since months! Nor for the greylisting , nor for the RBL blocking. Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] RBL's (again) (Was: Anyone from Green here?)
actually about a year and a half ago there was a new spambot which was re-sending the message after a temporary reject. But it did it precisely in 4 minutes after the first rejection, and never tried again. So, increasing the greylisting timeout to 5 minutes has solved the problem :) - Original Message From: Adrian Senn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 11, 2008 9:37:08 PM Subject: Re: [swinog] RBL's (again) (Was: Anyone from Green here?) Stanislav Sinyagin schrieb: I don't know anything about proper spammers. Greylisting has reduced the amount of incoming spam significantly, probably at 90-95%. Of course there are spambots which play around greylisting, but they aren't yet that widely used. Agreed. For my mail system at business i have at the moment a high amount of blocked mails by greylisting, swinog list and some other RBL lists. At the beginning of this week we had a high amount of blocked mails. Reason was probably a new wave of spam bot mails. Without the blocking system our mail gateway wouldn't be able to process the load. And no we don't have any complains since months! Nor for the greylisting , nor for the RBL blocking. Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
