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?)
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?)
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?)
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. agreed. maintenance for spamassassin or equal tools is much more time intensive than setting up and controlling greylisting. though my experience was that it's not necessary to use a long greylisting time, 5 minutes are usually more than enough to filter out 95% of bad mailers and usually queue times are 5,10 or 30mins for the first retry so users don't have to wait more then 5-30 mins at average. the resource question isn't just about the software, using content filter tools e.g. spamassassin consumes a lot of CPU and memory and if you don't have proper hardware it might also result in delays or other problems... > > 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 ___ 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 . 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
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?)
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?)
> Don't blame greylisting for this behavior. > > Queue-and-retry was an option but it is mandatory since RFC-2821. > > The very obsolete RFC-821 stated that "clients should retry". > In the old RFC-2119 it was explained that "should" means recommended. > The actual RFC-2821 states clearly that: > - "the SMTP client retains responsibility for delivery of the message" > - "the SMTP client is encouraged to try again" > - "mail that cannot be transmitted immediately MUST be queued and > periodically retried by the sender." > > You'd rather blame the lazy programmers who don't cares about RFCs and other > standards ! > 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. we have a lot of webservers with php mailforms, newsletter scripts, customer carp scripts, etc... smtp port to the internet is blocked from all servers by local and sector firewalls. they must use the local sendmail. the local sendmail on each server has a smarthost configured which is our relay mail server cluster where we're also doing greylisting. no problem with that at all. greets from Barcelona Marco > Daniele > > > Tonnerre Lombard wrote: > >> The problem is that your users go to web sites and subscribe their mail >> addresses to newsletters generated by PHP programmers. As expected, a >> lot of these try to deliver the mail directly to the destination host >> from the PHP script using some Pear SMTP crap module, rather than local >> sendmail. A typical dialog looks about like this: >> >> Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) >> In: HELO gmail.com >> Out: 250 planck.ngas.ch >> In: MAIL FROM: <[EMAIL PROTECTED]> >> Out: 250 2.1.0 Ok >> In: RCPT TO: <[EMAIL PROTECTED]> >> Out: 450 4.7.0 You are greylisted for 300 seconds >> In: DATA >> Out: 554 Error: No valid recipients >> In: From [EMAIL PROTECTED] >> Out: 221 2.0.0 error: I can break rules, too. goodbye. >> >> 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. >> >> That's the problem I am seeing with Greylisting, and I have discovered >> that methods like rejecting SPAM after DATA can be way more effective >> if the SPAM filter databases are sufficiently trained and the RBLs well >> chosen. >> >> Tonnerre >> >> >> >> >> ___ >> 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?)
Don't blame greylisting for this behavior. Queue-and-retry was an option but it is mandatory since RFC-2821. The very obsolete RFC-821 stated that "clients should retry". In the old RFC-2119 it was explained that "should" means recommended. The actual RFC-2821 states clearly that: - "the SMTP client retains responsibility for delivery of the message" - "the SMTP client is encouraged to try again" - "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender." You'd rather blame the lazy programmers who don't cares about RFCs and other standards ! Daniele Tonnerre Lombard wrote: > The problem is that your users go to web sites and subscribe their mail > addresses to newsletters generated by PHP programmers. As expected, a > lot of these try to deliver the mail directly to the destination host > from the PHP script using some Pear SMTP crap module, rather than local > sendmail. A typical dialog looks about like this: > > Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) > In: HELO gmail.com > Out: 250 planck.ngas.ch > In: MAIL FROM: <[EMAIL PROTECTED]> > Out: 250 2.1.0 Ok > In: RCPT TO: <[EMAIL PROTECTED]> > Out: 450 4.7.0 You are greylisted for 300 seconds > In: DATA > Out: 554 Error: No valid recipients > In: From [EMAIL PROTECTED] > Out: 221 2.0.0 error: I can break rules, too. goodbye. > > 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. > > That's the problem I am seeing with Greylisting, and I have discovered > that methods like rejecting SPAM after DATA can be way more effective > if the SPAM filter databases are sufficiently trained and the RBLs well > chosen. > > 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, Marco, On Wed, 15 Oct 2008 11:01:06 +0200, 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". The problem is that your users go to web sites and subscribe their mail addresses to newsletters generated by PHP programmers. As expected, a lot of these try to deliver the mail directly to the destination host from the PHP script using some Pear SMTP crap module, rather than local sendmail. A typical dialog looks about like this: Out: 220 planck.ngas.ch ESMTP Postfix (2.5.1) In: HELO gmail.com Out: 250 planck.ngas.ch In: MAIL FROM: <[EMAIL PROTECTED]> Out: 250 2.1.0 Ok In: RCPT TO: <[EMAIL PROTECTED]> Out: 450 4.7.0 You are greylisted for 300 seconds In: DATA Out: 554 Error: No valid recipients In: From [EMAIL PROTECTED] Out: 221 2.0.0 error: I can break rules, too. goodbye. 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. That's the problem I am seeing with Greylisting, and I have discovered that methods like rejecting SPAM after DATA can be way more effective if the SPAM filter databases are sufficiently trained and the RBLs well chosen. 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?)
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?)
[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?)
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
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?)
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?)
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 ;-) > 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 > ___ 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?)
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?)
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?)
:: Greylisting only delays mails. Proper spammers just use ISP relays and Well recent analysis show that % of open proxies and botnets using fake smtp are still quite important. :: as the 450 is recognized and spam run you again later. So many easy ways :: around it and it only causes annoyance. actually I experience efficient results with ways to slow down connections to spammers. I doubt many spammers will create bots that act as real smtp gateway with the first bounce of the handshaking, doing this for 100+ or 1000+ hosts would slow down the process on their side. However never use only one technique, but cook some mixed recipes.. -- ___ 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?)
> Greylisting only delays mails. Proper spammers just use ISP relays and > then they will try forever. Or they will just nicely do the full SMTP > thing for the first message and try again later, or stall sending to you > as the 450 is recognized and spam run you again later. So many easy ways > around it and it only causes annoyance. 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. > On top of that, I guess you have whitelisted large mail providers like > gmail who try to send a single mail from several IP's, thus hitting your > greylist over and over again, and then just giving up? :) some greylisting packages have their whitelists already pre-filled in the distribution package, so it works quite well (we used http://policyd.sourceforge.net/ , and I have no complaints about this software, and neither do the users. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] RBL's (again) (Was: Anyone from Green here?)
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. > quite a few false positives: greylisting is much more efficient). Greylisting only delays mails. Proper spammers just use ISP relays and then they will try forever. Or they will just nicely do the full SMTP thing for the first message and try again later, or stall sending to you as the 450 is recognized and spam run you again later. So many easy ways around it and it only causes annoyance. On top of that, I guess you have whitelisted large mail providers like gmail who try to send a single mail from several IP's, thus hitting your greylist over and over again, and then just giving up? :) [..] > The last issue I had recently is with Yahoo delaying some of the > messages sent to mailing-lists I host, I had to go through an > interesting procedure during the last few months to be able to > get the opportunity of maybe getting delisted, including a Privacy > policy (http://www.alphanet.ch/privacy_policy.html if you > are interested). When you send mail (or packets for that matter) to a remote site, that remote site can deny/filter/mangle those packets every way they want. As long as you are a smaller fish then them and you want to still deliver packets/mail to them you will have to comply to their rules. But as you are doing greylisting yourself, why are you complaining about another little bit of delay? ;) As always, it is your site, thus any problems you make for yourself are, well, made for yourself ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
