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 . 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?)
...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?)
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?)
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?)
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?)
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?)
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, 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?)
> 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? > some calls i got in the past. " your system is broken i miss some email but on my hatemail account i got them. are you not able to fix that ?" "your server again trashing my email" "client [EMAIL PROTECTED] cant send email to me, his mail getting back to him" some mentioned to change the provider if i dont get that working. NEVER heard: "There is spam in my inbox, fix that, on hatemail i dont have so much spam, maybe i should change the provider" sometimes heard:, "i have some small ammount of spam, but its not hard to handle. maybe you could do somthing about it." so see ? if you do something on the system which even rise the posibility of one email not deliverable, your on the wrong side. another thing is in an company your getting the responsability for getting the system working. improove the service. if you now implement systems which are preventing the service from working good, its up to the company if they COULD blame you for "sabotage" of the mail system... ever thought of that ? Theoretically of course ;-) Roger > 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 > ___ 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?)
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?)
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?)
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?)
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?)
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
