RE: [Declude.JunkMail] CBL Blocks
Actually I have been lurking mostly for several years. I jump in from time to time. Most of the junkmail records are set to either warn or dump the suspected spam into a spam folder MAILBOX SPAM The users have been instructed to visit their spam mail box from time to time to verify that no good mail is there and clear it out. Of course some don't bother. I have not set any of the blacklists on weighted tests. Nothing is deleted except in my own account where I feel confident anything that is tagged by certain tests is indeed spam. Like I said all 251 messages held in my spam box were indeed spam. We don't just give the users a heading telling them it is suspected spam. They don't even want to see the stuff. Personally, I don't either. This does not seem to be a problem for them so far. Once in a while something like this IP address causes some concern. But most users are in systems with firewalls with trusted IP addresses and have not been subjected to this sort of thing. Some of the tests are being totally ignored. For example I finally stopped using SORBS-SPAM and SORBS-DUHL because they became so unreliable tagging just about everything that came along. But, we updated the Declude to 2.61 (or whatever version) recently and I have not gone in to read the latest documentation and apply the new features. A problem with time. Don't run for a political office, it is all consuming. At 12:32 AM 8/3/2005, Colbeck, Andrew wrote: That is easy. The CBL failure is set to go to the user Spam mailbox. I just reviewed mine (spam box) and found 251 e-mails there for the past 30 days. Every one of them was spam. Ok Orin, so you're using the SUBJECT action with CBL? I'm sorry to belabour it if you already know this, but I haven't seen many postings from you here... The prevailing wisdom in this birds of a feather mailing list is to use actions with weights and weightranges instead of individual tests. In this way, a single false positive doesn't hurt as much, and you won't have to pre-determine which specific tests are trustworthy; instead, you work out which ranges merit various actions. Do you HOLD or DELETE messages at all, or do you mark up the subject lines for your clients and let them bear the responsibility of deleting their spam? I'm not for or against either method, I'm just curious where you have drawn your lines. Andrew 8) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Spam box
Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] Spam box
Richard Farris wrote: Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing IMGate. http://imgate.meiway.com/ I'm seeing a reduction in rejected messages with no reduction in delivered mail. This with a pretty simplistic configuration of postfix ( IMGate ). Rod -- --- [This E-mail scanned for viruses by Declude Virus] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Spam box
Richard Farris wrote: Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Hi Richard - One method is to put ORF in front of your IMail box and via its recipients blacklist feature refuse all mail that does not have a legit address on the imail box. It has really helped me kill huge dictionary attacks - like in the magnitude of 2 mill a day .. -Nick Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support "Crossroads to a Cleaner Internet"
RE: [Declude.JunkMail] Spam box
I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? Thanx Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 1:43 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box Richard Farris wrote: Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Hi Richard - One method is to put ORF in front of your IMail box and via its recipients blacklist feature refuse all mail that does not have a legit address on the imail box. It has really helped me kill huge dictionary attacks - like in the magnitude of 2 mill a day .. -Nick Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet
Re: [Declude.JunkMail] Spam box
Hi Goran, The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? For ORF that is correct - at least the way I use it - If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I run a script every 15 min that looks at Imail's HOST file and the extract from Imail that runs at the same time. If things have changed then I update ORF. I have 2 ORF boxes and have pretty much all of my MX recs pointing there rather than at the Imail box. I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? It will work fine. Perfectly! The short explanation is you need to get lists of valid users from all your providers and update ORF as need be with the results. Matt does it - I do it and so do many others I believe. -Nick Thanx Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 1:43 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box Richard Farris wrote: Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Hi Richard - One method is to put ORF in front of your IMail box and via its recipients blacklist feature refuse all mail that does not have a legit address on the imail box. It has really helped me kill huge dictionary attacks - like in the magnitude of 2 mill a day .. -Nick Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support "Crossroads to a Cleaner Internet"
Re: [Declude.JunkMail] Spam box
- Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 2:10 PM Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? If you use a newer version of Postfix, you can use recipient address verification. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipientfor details. However, the receiving mail server needs to respond properly. If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification. Bill
RE: [Declude.JunkMail] Spam box
BL If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accountsOther add-on software aside, in the Microsoft world, that means the internal server needs to be Exchange Server 2003. Exchange Server 5.5 and Exchange Server 2000 will receive the message, and then bounce it when it discovers that the recipient is not in the Global Address List. Also, I'd be a little skeptical that ORF would do the job for Goran, as he is basically an ISP for multiple organizations. He would need extracts from their GALs for each organization, or whatever the equivalent address list is for their internal mail. I've no suggestion for that. Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill LandrySent: Thursday, August 04, 2005 2:27 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Spam box - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 2:10 PM Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? If you use a newer version of Postfix, you can use recipient address verification. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipientfor details. However, the receiving mail server needs to respond properly. If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification. Bill
Re: [Declude.JunkMail] Spam box
Goran and Richard, There are two things that a gateway will do for you; address validation and pre-scanning the most obvious spam in order to reduce the load on an IMail/Declude setup. Address validation is an absolute requirement if you add a gateway, but adding a gateway for address validation is not necessary if all you do is host E-mail on your own IMail box. Unfortunately if you gateway E-mail for other servers, the best way to do address validation is to add a gateway in front of IMail. If you don't load addresses into your gateway, it will almost definitely increase your load on the IMail/Declude setup by many times over. About 1 out of every 5 to 10 domains in my experience is actively being dictionary attacked, however there is hardly any load if you are doing address validation because these address attempts are very easily rejected prior to receiving the E-mail. IMail does this on it's own for locally hosted domains so long as you don't have any nobody aliases. As far as pre-scanning goes, the best method is to do some simple RBL stuff in a weighted config similar to Declude. Things like Len's Postfix config (IMgate) are only a white-black solution where any single hit will block a message (based on my understanding). ORF also has similar functionality where it can do white-black blocking and address validation. Both fall short as pre-scanning gateways IMO, though naturally some do use them. The benefits of ORF is that you can run this on your IMail/Declude box so long as you can do some port redirection with a router since both can't run on port 25, but your router can redirect port 25 to some other port that you configure one or the other for. I am preparing to move away from ORF as my gateway since it is a tad bit kludgey when it comes to maintaining the addresses for validation. It works great however if you are only gatewaying for a few Exchange boxes since it knows ActiveDirectory. I'm going to move to Postfix and expand from just doing address validation to doing pre-scanning as well. In a thread from last week under the title "OT: IMgate/Postfix", Dan Horne pointed to the availability of a Postfix add-on that does in fact give you weighting capabilities called policyd-weight (http://robtone.mine.nu/postfix/). This tool was designed specifically as a pre-scanner in order to save processing power on the server(s) that do the heavy lifting. My only issue is that I want to become a bit more comfortable with Linux and Postfix before I jump. Richard indicated that load was an issue and hence the query about gateways. I would recommend first looking at how your server is configured and see if there is any way to improve efficiency. I almost guarantee that there is, and I suspect that most systems running Declude Pro (i.e. filters and external tests) could save half or more of their CPU utilization by just simply optimizing their configs. YMMV of course. Regarding Goran's question about getting addresses from Exchange; this was a big pain for me to figure out how to do so that I could get a text file with one address per line. Basically what I did was use CSVDE.exe on the Exchange server to do an export to a comma delimited text file and then I parsed that file for addresses. There also needed to be a separate file containing addresses that I wanted to exclude. Then there is a whole system for uploading these when changes are detected, and then combining them into a single file, converting that file to the format that ORF likes, updating ORF's ini file and restarting ORF. It's not pretty but it works. The Postfix process is a bit easier since you can just dump the text file onto the server with one address per line. Keep in mind the need for error detection and correction whenever you do this type of automation as an error can result in rejecting all E-mail for one or more domains. Also, in IMail there is a tool called ExtractUsers.exe that was designed for use with IMgate and can be used for any of the three options that I have mentioned. Matt Goran Jovanovic wrote: I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? Thanx Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 1:43 PM To:
Re: [Declude.JunkMail] Spam box
Hi Andrew - Colbeck, Andrew wrote: Also, I'd be a little skeptical that ORF would do the job for Goran, as he is basically an ISP for multiple organizations. Common :) Don't be so negative.. He would need extracts from their GALs for each organization, or whatever the equivalent address list is for their internal mail. I've no suggestion for that. This is the long of it. The logistics of getting the extracts timely is the issue. He would have to figure that one out. There are some other quirks with ORF which I know you are aware but none the less it is a possible solution - depending on the circumstance. -Nick Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Landry Sent: Thursday, August 04, 2005 2:27 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 2:10 PM Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? If you use a newer version of Postfix, you can use recipient address verification. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipientfor details. However, the receiving mail server needs to respond properly. If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification. Bill
RE: [Declude.JunkMail] Spam box
Matt FWIW, Matt, this has changed recently. It makes little difference to you, but I thought this was worth pointing out. The whatsnew.txt for IMail 8.20 and up says that it has the ability to bind the SMTPD to specific IP addresses. Previously, it bound to all addresses. Assuming that ORF is as flexible, this means that you can install ORF and IMail on the same box, binding ORF to your"real" IP and binding IMail SMTPD to 127.0.0.1 and configuring ORF to forward allgood inboundmailto 127.0.0.1:25 On my own system, I am still waiting for Declude to go gold with the next build of Declude Junkmail 2.x that will co-exist happily with IMail 8.2x Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Thursday, August 04, 2005 2:58 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] Spam box Goran and Richard,There are two things that a gateway will do for you; address validation and pre-scanning the most obvious spam in order to reduce the load on an IMail/Declude setup.Address validation is an absolute requirement if you add a gateway, but adding a gateway for address validation is not necessary if all you do is host E-mail on your own IMail box. Unfortunately if you gateway E-mail for other servers, the best way to do address validation is to add a gateway in front of IMail. If you don't load addresses into your gateway, it will almost definitely increase your load on the IMail/Declude setup by many times over. About 1 out of every 5 to 10 domains in my experience is actively being dictionary attacked, however there is hardly any load if you are doing address validation because these address attempts are very easily rejected prior to receiving the E-mail. IMail does this on it's own for locally hosted domains so long as you don't have any nobody aliases.As far as pre-scanning goes, the best method is to do some simple RBL stuff in a weighted config similar to Declude. Things like Len's Postfix config (IMgate) are only a white-black solution where any single hit will block a message (based on my understanding). ORF also has similar functionality where it can do white-black blocking and address validation. Both fall short as pre-scanning gateways IMO, though naturally some do use them. The benefits of ORF is that you can run this on your IMail/Declude box so long as you can do some port redirection with a router since both can't run on port 25, but your router can redirect port 25 to some other port that you configure one or the other for. I am preparing to move away from ORF as my gateway since it is a tad bit kludgey when it comes to maintaining the addresses for validation. It works great however if you are only gatewaying for a few Exchange boxes since it knows ActiveDirectory.I'm going to move to Postfix and expand from just doing address validation to doing pre-scanning as well. In a thread from last week under the title "OT: IMgate/Postfix", Dan Horne pointed to the availability of a Postfix add-on that does in fact give you weighting capabilities called policyd-weight (http://robtone.mine.nu/postfix/). This tool was designed specifically as a pre-scanner in order to save processing power on the server(s) that do the heavy lifting. My only issue is that I want to become a bit more comfortable with Linux and Postfix before I jump.Richard indicated that load was an issue and hence the query about gateways. I would recommend first looking at how your server is configured and see if there is any way to improve efficiency. I almost guarantee that there is, and I suspect that most systems running Declude Pro (i.e. filters and external tests) could save half or more of their CPU utilization by just simply optimizing their configs. YMMV of course.Regarding Goran's question about getting addresses from Exchange; this was a big pain for me to figure out how to do so that I could get a text file with one address per line. Basically what I did was use CSVDE.exe on the Exchange server to do an export to a comma delimited text file and then I parsed that file for addresses. There also needed to be a separate file containing addresses that I wanted to exclude. Then there is a whole system for uploading these when changes are detected, and then combining them into a single file, converting that file to the format that ORF likes, updating ORF's ini file and restarting ORF. It's not pretty but it works. The Postfix process is a bit easier since you can just dump the text file onto the server with one address per line. Keep in mind the need for error detection and correction whenever you do this type of automation as an error can result in rejecting all E-mail for one or more domains. Also, in IMail there is a tool called ExtractUsers.exe that was designed for use with IMgate and
Re: [Declude.JunkMail] Spam box
One other note to add to this. ORF plugs-into MS SMTP. I have unfortunately found that MS SMTP doesn't appear to handle rejecting oversized attachments when sent with HELO (not EHLO). When messages don't get rejected properly, they are sent over and over again until they time out. I have a 20 MB limit currently, but I found yesterday that there were at least 4 messages being sent over and over and over again, all in excess of 20 MB. That's a lot of bandwidth, in fact these four or so messages chewed up about 4 times my normal bandwidth utilization. I also noted that this issue occurred with another server using the same version of MS SMTP, and others too of course. This issue with MS SMTP is quite serious as it requires manual intervention and lots of time to identify such messages, and therefore it is also one of the reasons why I am moving to Postfix. Matt Matt wrote: Goran and Richard, There are two things that a gateway will do for you; address validation and pre-scanning the most obvious spam in order to reduce the load on an IMail/Declude setup. Address validation is an absolute requirement if you add a gateway, but adding a gateway for address validation is not necessary if all you do is host E-mail on your own IMail box. Unfortunately if you gateway E-mail for other servers, the best way to do address validation is to add a gateway in front of IMail. If you don't load addresses into your gateway, it will almost definitely increase your load on the IMail/Declude setup by many times over. About 1 out of every 5 to 10 domains in my experience is actively being dictionary attacked, however there is hardly any load if you are doing address validation because these address attempts are very easily rejected prior to receiving the E-mail. IMail does this on it's own for locally hosted domains so long as you don't have any nobody aliases. As far as pre-scanning goes, the best method is to do some simple RBL stuff in a weighted config similar to Declude. Things like Len's Postfix config (IMgate) are only a white-black solution where any single hit will block a message (based on my understanding). ORF also has similar functionality where it can do white-black blocking and address validation. Both fall short as pre-scanning gateways IMO, though naturally some do use them. The benefits of ORF is that you can run this on your IMail/Declude box so long as you can do some port redirection with a router since both can't run on port 25, but your router can redirect port 25 to some other port that you configure one or the other for. I am preparing to move away from ORF as my gateway since it is a tad bit kludgey when it comes to maintaining the addresses for validation. It works great however if you are only gatewaying for a few Exchange boxes since it knows ActiveDirectory. I'm going to move to Postfix and expand from just doing address validation to doing pre-scanning as well. In a thread from last week under the title "OT: IMgate/Postfix", Dan Horne pointed to the availability of a Postfix add-on that does in fact give you weighting capabilities called policyd-weight (http://robtone.mine.nu/postfix/). This tool was designed specifically as a pre-scanner in order to save processing power on the server(s) that do the heavy lifting. My only issue is that I want to become a bit more comfortable with Linux and Postfix before I jump. Richard indicated that load was an issue and hence the query about gateways. I would recommend first looking at how your server is configured and see if there is any way to improve efficiency. I almost guarantee that there is, and I suspect that most systems running Declude Pro (i.e. filters and external tests) could save half or more of their CPU utilization by just simply optimizing their configs. YMMV of course. Regarding Goran's question about getting addresses from Exchange; this was a big pain for me to figure out how to do so that I could get a text file with one address per line. Basically what I did was use CSVDE.exe on the Exchange server to do an export to a comma delimited text file and then I parsed that file for addresses. There also needed to be a separate file containing addresses that I wanted to exclude. Then there is a whole system for uploading these when changes are detected, and then combining them into a single file, converting that file to the format that ORF likes, updating ORF's ini file and restarting ORF. It's not pretty but it works. The Postfix process is a bit easier since you can just dump the text file onto the server with one address per line. Keep in mind the need for error detection and correction whenever you do this type of automation as an error can result in rejecting all E-mail for one or more domains. Also, in IMail there is a tool called ExtractUsers.exe that was designed for use with IMgate and can be used for any of the three options that I have mentioned. Matt Goran Jovanovic wrote:
Re: [Declude.JunkMail] Spam box
Goran, Address validation is an absolute necessity unless you either want to spend extra money on multiple scanning boxes and/or suffer outages due to pure load. As you add on more domains, the load from dictionary attacks on non-validated addresses will bury you. If these bogus addresses make it through your spam blocking, they will then be bounced by your server when it tries to deliver them to their final destination creating an excessive amount of backscatter, and that is something that is intolerable IMO. Sandy's ldap2aliases can be used for this, but IMO, it isn't something that I would use for multiple different Exchange servers as the configuration can be a bit much. For one or two Exchange servers it would definitely be practicable. The load from doing address validation on either ORF or within IMail is negligible. The load from not validating addresses is enormous because of all of the extra volume. Matt Goran Jovanovic wrote: Hi guys thanks for the info. Another follow on question. In either the IMGate or ORF scenario can you only have an address list for some of the domains? So for some you would do the address validation and for others you would allow everything through? I also assume that I could accomplish the same thing by using IMail aliases and using the ldap2alias tool that is floating around here? The problem as I understand with this solution is that the load is placed right on the IMail/Declude box and you dont get any break for your poor overtaxed CPU. Correct? Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 6:10 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box Hi Andrew - Colbeck, Andrew wrote: Also, I'd be a little skeptical that ORF would do the job for Goran, as he is basically an ISP for multiple organizations. Common :) Don't be so negative.. He would need extracts from their GALs for each organization, or whatever the equivalent address list is for their internal mail. I've no suggestion for that. This is the long of it. The logistics of getting the extracts timely is the issue. He would have to figure that one out. There are some other quirks with ORF which I know you are aware but none the less it is a possible solution - depending on the circumstance. -Nick Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Landry Sent: Thursday, August 04, 2005 2:27 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 2:10 PM Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? If you use a newer version of Postfix, you can use recipient address verification. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipientfor details. However, the receiving mail server needs to respond properly. If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification. Bill -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] Spam box
Hi Goran, Another follow on question. In either the IMGate or ORF scenario can you only have an address list for some of the domains? So for some you would do the address validation and for others you would allow everything through? Sure. What you have now is wide open - so the more you restrict the better. You have exposure - exactly as you do now - to dictionary attacks, etc but on the other hand the more to hide behind some sort of validation box the better you are off. It does not *have* to be all or nothing. It can be a gradual thing like move in - check things out. Marriage can come later :) I also assume that I could accomplish the same thing by using IMail aliases and using the ldap2alias tool that is floating around here? The problem as I understand with this solution is that the load is placed right on the IMail/Declude box and you dont get any break for your poor overtaxed CPU. Correct? You will still get zillions of invalid reciepients but that is it [which is still allot depending on the volume]. But Declude etal will not seem them so you save big time in that regard. -Nick Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 6:10 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box Hi Andrew - Colbeck, Andrew wrote: Also, I'd be a little skeptical that ORF would do the job for Goran, as he is basically an ISP for multiple organizations. Common :) Don't be so negative.. He would need extracts from their GALs for each organization, or whatever the equivalent address list is for their internal mail. I've no suggestion for that. This is the long of it. The logistics of getting the extracts timely is the issue. He would have to figure that one out. There are some other quirks with ORF which I know you are aware but none the less it is a possible solution - depending on the circumstance. -Nick Andrew 8) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Landry Sent: Thursday, August 04, 2005 2:27 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box - Original Message - From: Goran Jovanovic To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 2:10 PM Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? If you use a newer version of Postfix, you can use recipient address verification. See http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipientfor details. However, the receiving mail server needs to respond properly. If Exchange is set to blindly accept all forwarded mail and then bounce mail sent to invalid accounts, then it will always respond positively to verification queries, thus defeating the purpose of recipient address verification. Bill
Re: [Declude.JunkMail] Spam box
- Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 3:18 PM Subject: Re: [Declude.JunkMail] Spam box One other note to add to this.ORF plugs-into MS SMTP. I have unfortunately found that MS SMTP doesn't appear to handle rejecting oversized attachments when sent with HELO (not EHLO). When messages don't get rejected properly, they are sent over and over again until they time out. I have a 20 MB limit currently, but I found yesterday that there were at least 4 messages being sent over and over and over again, all in excess of 20 MB. That's a lot of bandwidth, in fact these four or so messages chewed up about 4 times my normal bandwidth utilization. I also noted that this issue occurred with another server using the same version of MS SMTP, and others too of course.This issue with MS SMTP is quite serious as it requires manual intervention and lots of time to identify such messages, and therefore it is also one of the reasons why I am moving to Postfix. This would be true of any mail server. If the remote server does not announce the size of the message, which is only supported via ESMTP, then the receiving mail server must receive the message up to the set limit before it can reject the delivery. Bill
Re: [Declude.JunkMail] Spam box
Bill, The issue is that MS SMTP has a habit of sending back a 552 error while the DATA transfer is still going on, and the sending server doesn't notice the error and then just requeues the message. I did some extensive research into this behavior and found that this was in fact what was going on. See the following thread for the issue: http://www.mail-archive.com/declude.junkmail@declude.com/msg25017.html I then noticed yesterday a different form of behavior, at least in the way that it was logged. Before MS SMTP was logging a BDAT with 552 error when the limit was reached even though the transfer wasn't BDAT. Essentially the logging was not reflective of what was really going on. Yesterday I noticed that the BDAT/552 logging stuff wasn't going on anymore, instead it was logging QUIT after the 20 MB limit and then a mysterious 25 minute gap and a timeout: 2005-08-04 01:42:58 216.224.43.19 mail.example.com SMTPSVC1 VALHALLA 66.109.52.201 0 HELO - +mail.example.com 250 0 44 32 0 SMTP - - 2005-08-04 01:43:09 216.224.43.19 mail.example.com SMTPSVC1 VALHALLA 66.109.52.201 0 MAIL - +FROM:someone@example.com 250 0 58 45 0 SMTP - - 2005-08-04 01:43:09 216.224.43.19 mail.example.com SMTPSVC1 VALHALLA 66.109.52.201 0 RCPT - +TO:recipient@example.com 250 0 36 33 0 SMTP - - 20 MB of data transfered and then MS SMTP quits the reception of the data --- 2005-08-04 01:45:59 216.224.43.19 mail.example.com SMTPSVC1 VALHALLA 66.109.52.201 0 QUIT - mail.example.com 240 213343 105 4 169734 SMTP - - --- Strange 25 minute gap, no clue --- 2005-08-04 02:11:27 216.224.43.19 - SMTPSVC1 VALHALLA 66.109.52.201 0 TIMEOUT - - 121 321642712 220 4 116203 SMTP - - 2005-08-04 02:11:27 216.224.43.19 - SMTPSVC1 VALHALLA 66.109.52.201 0 QUIT - - 240 116203 220 4 116203 SMTP - - If you are wondering what this behavior does when you have 4 messages stuck in this redelivery loop, attached is a chart of my incoming bandwidth from Tuesday and then Wednesday shown in hourly averages. Based on my observations, there are terrible issues with messages that are too large when HELO is used with MS SMTP. I have fixed this by removing the limit from MS SMTP and if I want to apply one, I will do it with IMail. It turns out that places like Yahoo are allowing attachments up to 40 MB in size and not supporting ESMTP/EHLO, and unfortunately people are using it to send huge attachments. Matt Bill Landry wrote: - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Thursday, August 04, 2005 3:18 PM Subject: Re: [Declude.JunkMail] Spam box One other note to add to this. ORF plugs-into MS SMTP. I have unfortunately found that MS SMTP doesn't appear to handle rejecting oversized attachments when sent with HELO (not EHLO). When messages don't get rejected properly, they are sent over and over again until they time out. I have a 20 MB limit currently, but I found yesterday that there were at least 4 messages being sent over and over and over again, all in excess of 20 MB. That's a lot of bandwidth, in fact these four or so messages chewed up about 4 times my normal bandwidth utilization. I also noted that this issue occurred with another server using the same version of MS SMTP, and others too of course. This issue with MS SMTP is quite serious as it requires manual intervention and lots of time to identify such messages, and therefore it is also one of the reasons why I am moving to Postfix. This would be true of any mail server. If the remote server does not announce the size of the message, which is only supported via ESMTP, then the receiving mail server must receive the message up to the set limit before it can reject the delivery. Bill -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] Spam box
If you are running IMail and are using the registry, as opposed to an external database or windows user base, IPlus Info Browser will create this list for you. It can be scheduled to run periodically so your list stays up to date. You can download a demo at http://www.martekware.com/ipb. Evans Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Thursday, August 04, 2005 4:10 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Spam box I have a question about these boxes that go in front of Declude, be they IMGATE or ORF or whatever. The way that I understand it from reading the threads here is that these front end boxes require the complete list of valid e-mail addresses for all domains that are being processed. Is that correct? If that is correct, then perhaps someone who is gatewaying mail to clients could answer this. How do you get all the e-mail addresses on the front end box and how do you keep it updated? I am doing gatewaying to various Exchange and other hosting providers and do not host any mail on my site. So am I correct in assuming that this solution will not work in my setup? Thanx Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer Sent: Thursday, August 04, 2005 1:43 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Spam box Richard Farris wrote: Is there a box I can put in front of my Imail server that will help take some of the load off of the spam filtering that Declude is doing Hi Richard - One method is to put ORF in front of your IMail box and via its recipients blacklist feature refuse all mail that does not have a legit address on the imail box. It has really helped me kill huge dictionary attacks - like in the magnitude of 2 mill a day .. -Nick Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support Crossroads to a Cleaner Internet
Re: [Declude.JunkMail] Spam box
Sandy, FYI, restarting ORF doesn't affect MS SMTP as far as I can tell, and as long as you configure MS SMTP to accept all E-mail, all that a restart of ORF will do is cause a moment of un-validated E-mail which should get deleted by Declude as spam if it came from a dictionary attack. The problem is really finding a way to reliably restart ORF in a script. I have had two occasions where my script failed to restart it and that caused overflow each time. I would look more into it, but I deeply desire something that can weight RBL's and some other very obvious things while also doing address validation, and I have little hope for ORF to do this anytime soon based on previous queries. I will agree that doing an AD import would be a smoother implementation with ORF provided that you are comfortable with this. Matt Sanford Whiteman wrote: Sandy's ldap2aliases can be used for this, but IMO, it isn't something that I would use for multiple different Exchange servers as the configuration can be a bit much. For one or two Exchange servers it would definitely be practicable. Yes, exchange2aliases (ldap2aliases is for IMail MXs fronting IMail or other OpenLDAP mailbox servers) is designed for situations in which the mailbox server(s) are owned by, or at least open to control by, the MX provider. Though ORF speaks AD LDAP natively, it too is not built out-of-the-box to support a wide range of remote mailbox servers with real-time validation and/or live recipient list updates (updates that don't require that the ORF service be restarted). As a result, most end up using ORF's plain-text recipient lists, which unlike LDAP does require a quick service restart when the list is updated. If you have more than one ORF server, rolling restarts will do you fine, but with a single server and high load, it can require more hoops to be jumped through to ensure that nothing aberrant (leakage, orphans) happens while the service restarts. IME, the best solution with ORF is to import the remote recipient lists into a dedicated AD/ADAM LDAP server (which happens live) and point ORF to that server for recipient validation (which also happens live). This gives you a real-time route for consolidating the recipient lists of multiple remote mail servers, but it requires real LDAP knowledge to set up. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re[2]: [Declude.JunkMail] Spam box
FYI, restarting ORF doesn't affect MS SMTP as far as I can tell, and as long as you configure MS SMTP to accept all E-mail, all that a restart of ORF will do is cause a moment of un-validated E-mail which should get deleted by Declude as spam if it came from a dictionary attack. Depending on the nature of the service shutdown, files could definitely be orphaned. I say this because, like you, I'm not so confident about the neat shutdown and restart of the ORF service. A bigger problem than the orphans is that moment of leakage, though. The problem is really finding a way to reliably restart ORF in a script. I have had two occasions where my script failed to restart it and that caused overflow each time. Yep, that's why I like the live updates of LDAP. Constantly restarting any Windows service gives me the willies! I would look more into it, but I deeply desire something that can weight RBL's and some other very obvious things while also doing address validation, and I have little hope for ORF to do this anytime soon based on previous queries. Gotta agree. The rblpolicyd functionality is rare at the free/low-cost price point, and new and untested even on *nix (though sa-exim has been able to do the same for Exim for a couple of years, a kind of weird latency if you ask me). --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
