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