Re: thanks to thinking people.
On 7/20/2010 1:01 PM, Ted Mittelstaedt wrote: You are mistaken. I'm a proponent of port 25 blocks. What I am saying is that port 25 blocks work far better than attempting to spamfilter outbound mail. It is the other guy who is arguing that spamfiltering outbound mail is better than port 25 blocks. Ted You need to actually read what I'm writing instead of skimming. The subjects being discussed are outbound mail from your own MTA, not joe-user's IP address, your own mail server's IP address. How internal and/or authenticated users with an infection can cause your MTA to end up on blacklists (especially trap fed) regardless of your rate based tripwires/log scanning. And how dumb-bots nearly never send outbound (to the rest of the world) through your MTA, only the smarter ones that can use SMTP-AUTH usually do that. That all leads to needing something a bit more than log scanning and rate limiting. Again, blocking outbound 25 from everything but your own MTA is all well and good for containing internal outbreaks from causing everyone else grief, but it has little impact on keeping your own MTA clean.
Re: thanks to thinking people.
On 7/22/2010 2:23 PM, Ted Mittelstaedt wrote: On 7/22/2010 11:29 AM, Benny Pedersen wrote: On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). and why not show logs ? bounces is newer external since postfix change sender to mailer-daemon with will end in some mailbox local if it was sent from local ip, if it sent remotely its just a reject that makes the remote mta do the bounce, but it will be the same that happend remotely when it bounces if bounces go external then the mta is not configured correct, and it can be other reasons it does bounce then just not used a reject Nonsense. You have internal users. They are using auth-smtp. One of those internal users is running a laptop He takes laptop to starflucks and joins the wireless He sends mail through your server. How exactly does Postfix know that he is an internal user. Spammer in the wild sees a mail from your user with a senders address of ilovec...@example.com originating from your smtp-auth system Spammer in the wild guesses user is using a UID of ilovecats and a password of pussy Spammer in wild authenticates into your auth-smtp server and spams the world with a forged senders address. How exactly does Postfix know the difference between Spammer and the internal user on the laptop at Starflucks? The notion of bouncing mail to inside users is a joke. Ted You don't BOUNCE you SMTP REJECT. No DSNs, no backscatter, and any FP from a legit user ends up with a support call to the correct party. If the outbound message does not exceed your SMTP REJECT level you let it go out WITHOUT MODIFICATION, no markup, no nothing.
Re: thanks to thinking people.
On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote You can have forged return-path and /or stollen credentials... in both cases you look like a backscatter source. show logs i belive postfix is smart to change forged sender to something that is not fqdn before it bounce :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: thanks to thinking people.
On Thu, 22 Jul 2010, Benny Pedersen wrote: On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote You can have forged return-path and /or stollen credentials... in both cases you look like a backscatter source. i belive postfix is smart to change forged sender to something that is not fqdn before it bounce :) A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). - C
Re: thanks to thinking people.
On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). and why not show logs ? bounces is newer external since postfix change sender to mailer-daemon with will end in some mailbox local if it was sent from local ip, if it sent remotely its just a reject that makes the remote mta do the bounce, but it will be the same that happend remotely when it bounces if bounces go external then the mta is not configured correct, and it can be other reasons it does bounce then just not used a reject -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: [sa] Re: thanks to thinking people.
On Thu, 22 Jul 2010, Benny Pedersen wrote: On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). and why not show logs ? Sorry. Not OP. Just noting that the opinion that postfix should be smart enough to rewrite a forged sender just doesn't make sense. bounces is newer external since postfix change sender to mailer-daemon with will end in some mailbox local if it was sent from local ip Postfix doesn't change the sender. Mailer Daemon is the 'sender' for all buonces. But it will be sent TO the original sender listed in the 'From' header. If postfix has generated the From header based on transaction authentication, then a 'bounce' would indeed go back to the originating mail account. But if you are merely going by IP, then the 'sender' that postfix tries to 'bounce' mail to will be the forged sender. And postfix has no way to know it is forged - C
Re: thanks to thinking people.
On 7/22/2010 11:03 AM, Charles Gregory wrote: On Thu, 22 Jul 2010, Benny Pedersen wrote: On ons 21 jul 2010 19:09:55 CEST, Alexandre Chapellon wrote You can have forged return-path and /or stollen credentials... in both cases you look like a backscatter source. i belive postfix is smart to change forged sender to something that is not fqdn before it bounce :) A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). Wash your mouth out! Didn't you know Postfix is God's Gift to Mail Admins? It can do ANYTHING. Postfix is so smart that it can reach back through the SMTP connection to the spammer and blow his computer up!!! Or so the Postfix bigots would have you believe. Ted
Re: thanks to thinking people.
On 7/22/2010 11:29 AM, Benny Pedersen wrote: On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). and why not show logs ? bounces is newer external since postfix change sender to mailer-daemon with will end in some mailbox local if it was sent from local ip, if it sent remotely its just a reject that makes the remote mta do the bounce, but it will be the same that happend remotely when it bounces if bounces go external then the mta is not configured correct, and it can be other reasons it does bounce then just not used a reject Nonsense. You have internal users. They are using auth-smtp. One of those internal users is running a laptop He takes laptop to starflucks and joins the wireless He sends mail through your server. How exactly does Postfix know that he is an internal user. Spammer in the wild sees a mail from your user with a senders address of ilovec...@example.com originating from your smtp-auth system Spammer in the wild guesses user is using a UID of ilovecats and a password of pussy Spammer in wild authenticates into your auth-smtp server and spams the world with a forged senders address. How exactly does Postfix know the difference between Spammer and the internal user on the laptop at Starflucks? The notion of bouncing mail to inside users is a joke. Ted
Re: thanks to thinking people.
Thanks Ted for that example i could not have wrote in english myself. Le jeudi 22 juillet 2010 à 13:23 -0700, Ted Mittelstaedt a écrit : On 7/22/2010 11:29 AM, Benny Pedersen wrote: On tor 22 jul 2010 20:03:18 CEST, Charles Gregory wrote A forged sender looks no different than a legitimate sender. Postfix would have no way to be 'smart' about this (except for some instances of SPF fail, but then why 'bounce'? Why not reject?). and why not show logs ? bounces is newer external since postfix change sender to mailer-daemon with will end in some mailbox local if it was sent from local ip, if it sent remotely its just a reject that makes the remote mta do the bounce, but it will be the same that happend remotely when it bounces if bounces go external then the mta is not configured correct, and it can be other reasons it does bounce then just not used a reject Nonsense. You have internal users. They are using auth-smtp. One of those internal users is running a laptop He takes laptop to starflucks and joins the wireless He sends mail through your server. How exactly does Postfix know that he is an internal user. Spammer in the wild sees a mail from your user with a senders address of ilovec...@example.com originating from your smtp-auth system Spammer in the wild guesses user is using a UID of ilovecats and a password of pussy Spammer in wild authenticates into your auth-smtp server and spams the world with a forged senders address. How exactly does Postfix know the difference between Spammer and the internal user on the laptop at Starflucks? The notion of bouncing mail to inside users is a joke. Ted -- Alexandre Chapellon alexandre.chapel...@mana.pf Mana SAS
Re: thanks to thinking people.
On 20.07.10 00:48, RW wrote: I was asking what's the point of adding headers or markup that *is* seen by the recipient. On 7/20/2010 4:55 AM, Matus UHLAR - fantomas wrote: I think Brian understood youre question as disagreement :) I think there's no logical point. In case of FP you are only telling the recipient your spam filter sucks :) On 20.07.10 11:16, Ted Mittelstaedt wrote: Exactly, meaning that if you run SA on outbound mail then there's no point at all unless you configure it to DELETE the outbound mail it thinks is spam - and if you do that your going to get shot by your users over the FPs. I think that at this level by outgoing email we mean email coming from authenticated users. Such e-mail we can reject at smtp time so the users will get proper error message. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I drive way too fast to worry about cholesterol.
Re: thanks to thinking people.
Le mardi 20 juillet 2010 à 18:56 -0600, LuKreme a écrit : On Jul 20, 2010, at 18:07, Alexandre Chapellon alexandre.chapel...@mana.pf wrote: Bouncing spam?? What a good way to become a backscatter source (in addition to spam)! We are talking about Checking OUTBOUND messages. It is perfectly ok to bounce internal messages. You can have forged return-path and /or stollen credentials... in both cases you look like a backscatter source. -- Alexandre Chapellon alexandre.chapel...@mana.pf Mana SAS
Re: thanks to thinking people.
On Mon, 19 Jul 2010 13:25:26 -0700 Ted Mittelstaedtt...@ipinc.net wrote: It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, On 7/19/2010 4:01 PM, RW wrote: What's the point of adding spam-filtering headers or markup to outgoing mail? On Mon, 19 Jul 2010 16:58:49 -0600 Brian Godette bgode...@idcomm.com wrote: Indeed, the point would be to score and SMTP reject outbound over some score, anything under would be sent unmodified. On 20.07.10 00:48, RW wrote: I was asking what's the point of adding headers or markup that *is* seen by the recipient. I think Brian understood youre question as disagreement :) I think there's no logical point. In case of FP you are only telling the recipient your spam filter sucks :) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Eagles may soar, but weasels don't get sucked into jet engines.
Re: thanks to thinking people.
On 7/19/2010 3:55 PM, Brian Godette wrote: On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I said it only does very little in THEORY, but in actual practice (right now) it does a tremendous amount. In actual practice it does very little for YOUR OWN MX, the simple bots simply do not target internal mail servers, they send direct. Which is why I said it's good from a policy standpoint but does nothing to actually prevent YOUR OWN MX from ending up on an RBL because all the bots that can do that don't care that you've got outbound 25 from your internal network blocked. Last I checked RBL's worked off IP addresses not MX's. If joe schmoe on some other network has a bot that's sending with my MX forged then I'm not going to end up in an RBL. If I have a customer with a bot on it then that bot isn't going to be able to send since I block outbound port 25 and virtually all bots only send via 25, not the submission port (using auth) except for a few that will attack via a webmail interface. I won't rule out that the spammers won't become smarter but right now they are stupid. I guess there's just too many wide-open servers still out there for them to bother trying to get around one that's been tightened down. I've seen bots use smtp-auth from inside, whether it's by injecting into O/OE or recovered auth I can't say. I've seen bots use webmail as you have, I've also seen them use smtp-auth vs submission/ssl (587/495). But again, that's only after they've either guessed or phished the account info. In either case you're still left with having to scan outbound from your own MX, and/or rate limit, or accept being RBL'd for short periods of time being reactive to log analysis and spam reports. If you keep on top of the logs then you won't generally be RBLed. And you can run a monitoring program like Big Sister and with a bit of scripting you can be notifed when your server starts spamming. Out-of-the-box the SMTP monitor in Big Sister will alarm if the mailserver starts slowing down - which
Re: thanks to thinking people.
On 7/20/2010 4:55 AM, Matus UHLAR - fantomas wrote: On Mon, 19 Jul 2010 13:25:26 -0700 Ted Mittelstaedtt...@ipinc.net wrote: It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, On 7/19/2010 4:01 PM, RW wrote: What's the point of adding spam-filtering headers or markup to outgoing mail? On Mon, 19 Jul 2010 16:58:49 -0600 Brian Godettebgode...@idcomm.com wrote: Indeed, the point would be to score and SMTP reject outbound over some score, anything under would be sent unmodified. On 20.07.10 00:48, RW wrote: I was asking what's the point of adding headers or markup that *is* seen by the recipient. I think Brian understood youre question as disagreement :) I think there's no logical point. In case of FP you are only telling the recipient your spam filter sucks :) Exactly, meaning that if you run SA on outbound mail then there's no point at all unless you configure it to DELETE the outbound mail it thinks is spam - and if you do that your going to get shot by your users over the FPs. Ted
Re: thanks to thinking people.
You argue about the fficiency of blicking network flow like we do But beyond argue they are simples facts: Before I introduce port 25 blocking I had more than 200 feedback loop complaints daily from differents MSP (Yahoo, AOL, abusix and others). Since blocking is enabled it I have have less than 50. Half of which are from user that are not blocked already, and 30 others percents are from my users who don't know to manage subscription list (let's say my very own spammers). I know it doesn't mean I do not spam at all right now But what I know it means is that now I have much more control on what's going out of my network. Scanning outgoing mails throug ANY content scanning is dangerous because of FP (except viral analysis maybe which produce very few FP). Further more if you compare the amount of ressources spent with the amount of spams stopped, networks ACL are much more efficicent than ANY spam filter configured to avoid FP! Anyway, everyone here knows you can't fight spam with one single weapon (there's no Hiroshima in this war). You need to protect your people, and SA is good at it but you also need to make sure you're not yourself part of the dark side... If everyone cares, we get a cleaner network. Le mardi 20 juillet 2010 à 10:52 -0700, Ted Mittelstaedt a écrit : On 7/19/2010 3:55 PM, Brian Godette wrote: On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I said it only does very little in THEORY, but in actual practice (right now) it does a tremendous amount. In actual practice it does very little for YOUR OWN MX, the simple bots simply do not target internal mail servers, they send direct. Which is why I said it's good from a policy standpoint but does nothing to actually prevent YOUR OWN MX from ending up on an RBL because all the bots that can do that don't care that you've got outbound 25 from your internal network blocked.
Re: thanks to thinking people.
You are mistaken. I'm a proponent of port 25 blocks. What I am saying is that port 25 blocks work far better than attempting to spamfilter outbound mail. It is the other guy who is arguing that spamfiltering outbound mail is better than port 25 blocks. Ted On 7/20/2010 11:46 AM, Alexandre Chapellon wrote: You argue about the fficiency of blicking network flow like we do But beyond argue they are simples facts: Before I introduce port 25 blocking I had more than 200 feedback loop complaints daily from differents MSP (Yahoo, AOL, abusix and others). Since blocking is enabled it I have have less than 50. Half of which are from user that are not blocked already, and 30 others percents are from my users who don't know to manage subscription list (let's say my very own spammers). I know it doesn't mean I do not spam at all right now But what I know it means is that now I have much more control on what's going out of my network. Scanning outgoing mails throug ANY content scanning is dangerous because of FP (except viral analysis maybe which produce very few FP). Further more if you compare the amount of ressources spent with the amount of spams stopped, networks ACL are much more efficicent than ANY spam filter configured to avoid FP! Anyway, everyone here knows you can't fight spam with one single weapon (there's no Hiroshima in this war). You need to protect your people, and SA is good at it but you also need to make sure you're not yourself part of the dark side... If everyone cares, we get a cleaner network. Le mardi 20 juillet 2010 à 10:52 -0700, Ted Mittelstaedt a écrit : On 7/19/2010 3:55 PM, Brian Godette wrote: On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellonalexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I said it only does very little in THEORY, but in actual practice (right now) it does a tremendous amount. In actual practice it does very little for YOUR OWN MX, the simple bots simply do not target internal mail servers, they send direct. Which is why I said it's good from a policy standpoint but does nothing to
Re: thanks to thinking people.
Sorry it was not directly for you, but more like a general post. Le mardi 20 juillet 2010 à 12:01 -0700, Ted Mittelstaedt a écrit : You are mistaken. I'm a proponent of port 25 blocks. What I am saying is that port 25 blocks work far better than attempting to spamfilter outbound mail. It is the other guy who is arguing that spamfiltering outbound mail is better than port 25 blocks. Ted On 7/20/2010 11:46 AM, Alexandre Chapellon wrote: You argue about the fficiency of blicking network flow like we do But beyond argue they are simples facts: Before I introduce port 25 blocking I had more than 200 feedback loop complaints daily from differents MSP (Yahoo, AOL, abusix and others). Since blocking is enabled it I have have less than 50. Half of which are from user that are not blocked already, and 30 others percents are from my users who don't know to manage subscription list (let's say my very own spammers). I know it doesn't mean I do not spam at all right now But what I know it means is that now I have much more control on what's going out of my network. Scanning outgoing mails throug ANY content scanning is dangerous because of FP (except viral analysis maybe which produce very few FP). Further more if you compare the amount of ressources spent with the amount of spams stopped, networks ACL are much more efficicent than ANY spam filter configured to avoid FP! Anyway, everyone here knows you can't fight spam with one single weapon (there's no Hiroshima in this war). You need to protect your people, and SA is good at it but you also need to make sure you're not yourself part of the dark side... If everyone cares, we get a cleaner network. Le mardi 20 juillet 2010 à 10:52 -0700, Ted Mittelstaedt a écrit : On 7/19/2010 3:55 PM, Brian Godette wrote: On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellonalexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I
Re: thanks to thinking people.
On Jul 20, 2010, at 12:16, Ted Mittelstaedt t...@ipinc.net wrote: Exactly, meaning that if you run SA on outbound mail then there's no point at all unless you configure it to DELETE the outbound mail it thinks is spam - and if you do that your going to get shot by your users over the FPs. Well, no. If you do filter outbound and trigger on a spammy message, you bounce it, not delete it.
Re: thanks to thinking people.
Le mardi 20 juillet 2010 à 14:40 -0600, LuKreme a écrit : On Jul 20, 2010, at 12:16, Ted Mittelstaedt t...@ipinc.net wrote: Exactly, meaning that if you run SA on outbound mail then there's no point at all unless you configure it to DELETE the outbound mail it thinks is spam - and if you do that your going to get shot by your users over the FPs. Well, no. If you do filter outbound and trigger on a spammy message, you bounce it, not delete it. Bouncing spam?? What a good way to become a backscatter source (in addition to spam)! Definately not to be done! -- Alexandre Chapellon alexandre.chapel...@mana.pf Mana SAS
Re: thanks to thinking people.
On Jul 20, 2010, at 18:07, Alexandre Chapellon alexandre.chapel...@mana.pf wrote: Bouncing spam?? What a good way to become a backscatter source (in addition to spam)! We are talking about Checking OUTBOUND messages. It is perfectly ok to bounce internal messages.
Re: thanks to thinking people.
On Tue, 20 Jul 2010, Alexandre Chapellon wrote: Le mardi 20 juillet 2010 ?? 14:40 -0600, LuKreme a ??crit : On Jul 20, 2010, at 12:16, Ted Mittelstaedt t...@ipinc.net wrote: Exactly, meaning that if you run SA on outbound mail then there's no point at all unless you configure it to DELETE the outbound mail it thinks is spam - and if you do that your going to get shot by your users over the FPs. Well, no. If you do filter outbound and trigger on a spammy message, you bounce it, not delete it. Bouncing spam?? What a good way to become a backscatter source (in addition to spam)! Definately not to be done! Bounce _internally_, on _outbound_ email. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Today: the 41st anniversary of Apollo 11 landing on the Moon
Re: [sa] Re: thanks to thinking people.
On Tue, 20 Jul 2010, LuKreme wrote: We are talking about Checking OUTBOUND messages. It is perfectly ok to bounce internal messages. Caveat: As long as proper care is taken to send the bounce to the authenticated sender of the mail and NOT just lamely use the 'From' header! Still prefer an SMTP reject over a bounce! - C
Re: thanks to thinking people.
On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much.
Re: thanks to thinking people.
Hi, On Mon, 19.07.2010 at 09:43:20 -0600, Brian Godette bgode...@idcomm.com wrote: I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. this is true, BUT Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. this measure makes it much easier to track down the spammers in your userbase, because the sent emails usually contain a header like X-Authenticated: joe-sixpack-with-his-can-of-worms. Then you only have to verify that the spam report is legit, and then can simply block this user's account until they have cleaned their PC. Running SA on outbound is still a necessity, though. Kind regards, --Toni++
Re: thanks to thinking people.
On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted
Re: thanks to thinking people.
On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. I've seen bots use smtp-auth from inside, whether it's by injecting into O/OE or recovered auth I can't say. I've seen bots use webmail as you have, I've also seen them use smtp-auth vs submission/ssl (587/495). But again, that's only after they've either guessed or phished the account info. In either case you're still left with having to scan outbound from your own MX, and/or rate limit, or accept being RBL'd for short periods of time being reactive to log analysis and spam reports.
Re: thanks to thinking people.
On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I said it only does very little in THEORY, but in actual practice (right now) it does a tremendous amount. I won't rule out that the spammers won't become smarter but right now they are stupid. I guess there's just too many wide-open servers still out there for them to bother trying to get around one that's been tightened down. I've seen bots use smtp-auth from inside, whether it's by injecting into O/OE or recovered auth I can't say. I've seen bots use webmail as you have, I've also seen them use smtp-auth vs submission/ssl (587/495). But again, that's only after they've either guessed or phished the account info. In either case you're still left with having to scan outbound from your own MX, and/or rate limit, or accept being RBL'd for short periods of time being reactive to log analysis and spam reports. If you keep on top of the logs then you won't generally be RBLed. And you can run a monitoring program like Big Sister and with a bit of scripting you can be notifed when your server starts spamming. Out-of-the-box the SMTP monitor in Big Sister will alarm if the mailserver starts slowing down - which is customary when a spammer commences a large spam run. But you can also write a script that runs once an hour and monitors your mailflow and alarms if it jumps. If your graphing your mailflow then spam runs will create spikes that are very obvious. It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, your going to be in a heap of trouble. But if it's your customer's recipient's mailserver then that admin will be in the hotseat. Sometimes even the spamassassin header addition, even if the outbound mail ISN'T marked as spam, will trigger a spamfilter.
Re: thanks to thinking people.
Blocking outbound 25 from the rest of your network, and disallowing
submission to your MX on 25 from your network
, does very little for keeping your own MX from sending spam which is what SA
on outgoing SMTP would be for.
It's great from a policy standpoint and contains the simple bots, but for
keeping your outbound from MX clean,
not so much.
In Exim you can ratelimit SMTP connections like so:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTratelimiting
# Slow down fast senders; note the need to truncate $sender_rate
# at the decimal point.
warn ratelimit = 100 / 1h / per_rcpt / strict
delay = ${eval: ${sg{$sender_rate}{[.].*}{}} - \
$sender_rate_limit }s
Sure there are ways of doing this with other MTA's as well.
Since spam depends on many thousands of messages this effectively
limits the usefulness of your MTA for sending spam. Must also limit
the number of connections per IP. I also think this examples 100
recipients per hour is to low.
Matt
Re: thanks to thinking people.
On Mon, 19 Jul 2010 13:25:26 -0700 Ted Mittelstaedt t...@ipinc.net wrote: It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, What's the point of adding spam-filtering headers or markup to outgoing mail?
Re: thanks to thinking people.
On 7/19/2010 2:25 PM, Ted Mittelstaedt wrote: On 7/19/2010 12:56 PM, Brian Godette wrote: On 7/19/2010 1:29 PM, Ted Mittelstaedt wrote: On 7/19/2010 8:43 AM, Brian Godette wrote: On 7/15/2010 6:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration! -- Alexandre Chapellon alexandre.chapel...@mana.pf mailto:alexandre.chapel...@mana.pf Mana SAS I hope you realize you still need to deal with the issues of users with weak/guessable passwords and phishing of account info as well as the newer bots that recover account info from Outlook/Outlook Express/Thunderbird. Blocking outbound 25 from the rest of your network, and disallowing submission to your MX on 25 from your network, does very little for keeping your own MX from sending spam which is what SA on outgoing SMTP would be for. It's great from a policy standpoint and contains the simple bots, but for keeping your outbound from MX clean, not so much. That absolutely isn't true. Yes I agree that it's possible for a spammer to write a virus that uses the submission port and authenticated SMTP to send mail and runs on a user's PC. But if your running even a simple log analysis script on your mailserver and you READ the daily reports from it, then a user that sends many tens to hundreds of thousands of e-mails will stick out like a sore thumb. We have NEVER had a spammer do this to one of our users. I don't know why because it seems to me like it's an obvious way to relay spam. What we HAVE had happen is spammers guess weak passwords and relay spam through the webmail interface. My guess is that it's just a lot easier to do this for them. Of course, when they do that their outgoing spam is stamped with the username that was used to relay, and it's very easy to detect and change the password. So far, all the spam viruses we have encountered on user systems are of the variety where they infect the client and attempt to relay to port 25. Ted So basically you're agreeing with what I said. It stops the simple bots, but the other stuff, not so much. No, you said it does very little and I said it only does very little in THEORY, but in actual practice (right now) it does a tremendous amount. In actual practice it does very little for YOUR OWN MX, the simple bots simply do not target internal mail servers, they send direct. Which is why I said it's good from a policy standpoint but does nothing to actually prevent YOUR OWN MX from ending up on an RBL because all the bots that can do that don't care that you've got outbound 25 from your internal network blocked. I won't rule out that the spammers won't become smarter but right now they are stupid. I guess there's just too many wide-open servers still out there for them to bother trying to get around one that's been tightened down. I've seen bots use smtp-auth from inside, whether it's by injecting into O/OE or recovered auth I can't say. I've seen bots use webmail as you have, I've also seen them use smtp-auth vs submission/ssl (587/495). But again, that's only after they've either guessed or phished the account info. In either case you're still left with having to scan outbound from your own MX, and/or rate limit, or accept being RBL'd for short periods of time being reactive to log analysis and spam reports. If you keep on top of the logs then you won't generally be RBLed. And you can run a monitoring program like Big Sister and with a bit of scripting you can be notifed when your server starts spamming. Out-of-the-box the SMTP monitor in Big Sister will alarm if the mailserver starts slowing down - which is customary when a spammer commences a large spam run. But you can also write a script that runs once an hour and monitors your mailflow and alarms if it jumps. If your graphing your mailflow then spam runs will create spikes that are very obvious. At which point it's already too late. It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it.
Re: thanks to thinking people.
On 7/19/2010 4:01 PM, RW wrote: On Mon, 19 Jul 2010 13:25:26 -0700 Ted Mittelstaedtt...@ipinc.net wrote: It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, What's the point of adding spam-filtering headers or markup to outgoing mail? Indeed, the point would be to score and SMTP reject outbound over some score, anything under would be sent unmodified. If it's a FP your own user contacts you.
Re: thanks to thinking people.
On Mon, 19 Jul 2010 16:58:49 -0600 Brian Godette bgode...@idcomm.com wrote: On 7/19/2010 4:01 PM, RW wrote: On Mon, 19 Jul 2010 13:25:26 -0700 Ted Mittelstaedtt...@ipinc.net wrote: It's been our experience that spam-scanning outbound mail causes a lot more problems than setting up mailserver monitoring and being responsive to it. Sooner or later one of your customers is going to call you and bitch because their mail ended up in their coorespondents spam folder due to them using HTML or including a bad URL and if it was your server that tagged it spam, What's the point of adding spam-filtering headers or markup to outgoing mail? Indeed, the point would be to score and SMTP reject outbound over some score, anything under would be sent unmodified. I was asking what's the point of adding headers or markup that *is* seen by the recipient.
Re: thanks to thinking people.
Great! 1 down, 19,587,294,872,875 more admins to go! ;-) Ted On 7/15/2010 5:55 PM, Alexandre Chapellon wrote: Hi all, Few months ago I asked this list if using SA on outgoing smtp was a good idea (Thread: SA on outgoing SMTP). This thread quickly moved to Block direct port 25 for non-mta users! I was really afraid of doing so and didn't really wanted to go this way. now about 6 months later I have to say: I was a fool! Today. After spending some time trying to find a more user-friendly way to clean up the mess around here, I came to the conclusion that port 25 blocking on the bound of my network was inevitable. Today it's done, and I have followed few others advices given on list. I wanted to testify the benfits of good designed network for thoose who like me are afrais of annying customer with security (even more blocking port 25 on the limits of the network is not really annoying for most of customers). Thanks to Ted Mittelstaedt, Matus UHLAR, Martin Gregorie, with your help dudes, all I have to care about now is my mailservers configuration!
