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.
:: 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..
--
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
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: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of roger@mgz.ch Sent: Thursday, September 11, 2008 3:07 PM To: swinog@swinog.ch 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
roger@mgz.ch 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
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
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
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: blubber@gurgel.org Out: 250 2.1.0 Ok In: RCPT TO: kreisch@ngas.ch Out: 450 4.7.0 You are greylisted for 300 seconds In: DATA Out: 554 Error: No valid recipients In: From blubber@gurgel.org 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
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: blubber@gurgel.org Out: 250 2.1.0 Ok In: RCPT TO: kreisch@ngas.ch Out: 450 4.7.0 You are greylisted for 300 seconds In: DATA Out: 554 Error: No valid recipients In: From blubber@gurgel.org 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
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: blubber@gurgel.org Out: 250 2.1.0 Ok In: RCPT TO: kreisch@ngas.ch Out: 450 4.7.0 You are greylisted for 300 seconds In: DATA Out: 554 Error: No valid recipients In: From blubber@gurgel.org 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
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
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
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
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 marketing@blabla.com 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
Adrian Senn -
Beat Siegenthaler -
Charles Buckley -
Daniel Kamm -
Daniele Guazzoni -
julien mabillard -
Marco -
Marco Fretz
-
Martin Ebnoether -
Michael Naef -
Per Jessen -
roger＠mgz.ch -
Stanislav Sinyagin -
Tonnerre Lombard