[Declude.JunkMail] SPAMDOMAINS and REVDNS
When a message comes from an IP that has no PTR record, and the sender domain is in the SPAMDOMAINS list, it is getting double penalized for the same violation. That is not the desired effect. Is there a way that SPAMDOMAINS can be configured not to fail if there is no PTR record, based on the assumption that most of us use the REVDNS test? John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
RE: [Declude.JunkMail] Connection Type Filtering Policy
I, and believe many others, completely block any Dynamic IP range on my outer mail gateway (IMGate). They are infested with open relays, zombies, proxies. To me, blocking all this range is worth the one or two false positives that happen every month. I use sorb's list. Check it out at http://www.dnsbl.au.sorbs.net/DUL-FAQ.html. They are not that aggressive and don't block declude's server :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ognenoff Sent: Friday, December 12, 2003 10:15 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] Connection Type Filtering Policy I was wondering what people's feelings were on blacklisting based on the sending computers connection type (of course based on IP range)? I have heard on other threads that some just assume that if a message came from a server that has an IP within a range of IPs that is listed as being cable, DSL, or dial-up it should be treated as spam. When talking about this are people referring to all DSL and cable IP ranges or just the dynamically assigned ones? The reason I am asking is because I am thinking of tinkering with a setup on my home network to provide email to my family. I wouldn't consider myself an expert mail admin but I know enough from the mail administration I do at work to configure my server securely (and of course run Declude AV and JM :)) The only thing holding me back from playing with this project is that I fear my mail will be filtered as spam by most other mail admins because there is no way I can afford a T1 or above for my home. I would be using business class DSL or cable with static IPs. Any thoughts? Andy Ognenoff Online Systems Administrator - Cousins Submarines, Inc. http://www.cousinssubs.com --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
Re: [Declude.JunkMail] SPAMDOMAINS and REVDNS
John, nothing should be listed in spamdomains unless it has a valid PTR , that's the very nature of the test - to test the mailfrom domain of a message that has a matching domain listed in spamdomains (again, which should already be confirmed to have valid PTR records), and reject those that either have no PTR or have an invalid PTR. Bill - Original Message - From: John Tolmachoff (Lists) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 13, 2003 12:52 AM Subject: [Declude.JunkMail] SPAMDOMAINS and REVDNS When a message comes from an IP that has no PTR record, and the sender domain is in the SPAMDOMAINS list, it is getting double penalized for the same violation. That is not the desired effect. Is there a way that SPAMDOMAINS can be configured not to fail if there is no PTR record, based on the assumption that most of us use the REVDNS test? John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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. e.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
This may be a crutch solution, but it is what we have implemented, and our customers seem to like it. I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an intermediary between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser. At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats. I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I need direct access to my SMTP server for monitoring, I absolutely have to have a provider that allows SMTP traffic through. If the majority of ISP's played by the rules that you do, SMTP would be broken for all practical purposes as far as I'm concerned. If you ask around, most here don't consider blocking on DUL lists to be a wise thing to do, though using that in a weighting scheme is a decent idea. It's pretty clear that even Scott is being blocked by Road Runner's servers because of a poor implementation of a DUL list that includes his IP space even though it is static and business-class. Blocking outbound SMTP is even worse than blocking by DUL. I'm sure that many around here have had similar issues with large ISP's that improperly have tagged their IP space as being dynamic. I know that this practice negatively affects my business, and it's quite difficult to explain to a non-technical customer why this is, and never once has one of them been happy that their ISP has chosen to do so. Maybe you aren't aware of this affecting your business, but I, along with several of my LAN integrator friends, would absolutely not recommend an ISP that blocks outbound SMTP traffic because of the problems that it causes me, and the perception that such an implementation is a lazy way of fighting spam. And as far as my experience goes, none of the ISP's doing this that I have encountered went about this in a fully responsible manner. They all chose to make a change and then have me take the calls and do the diagnosis and call them for verification instead of alerting their customers as to the issues. This also starts encroaching into the areas of censorship and policing ones customers. Once you start getting involved with disallowing SMTP, you remove legitimate objections to blocking file sharing networks, and could even make yourself liable for such things. The industry has taken a very purposeful approach to this by usurping as much responsibility as possible. They don't want to become the Internet's police force, and costly defenses of John Doe's by places like Yahoo and Verizon were not intended to protect criminals, but instead to protect their businesses from liability and burden. The RIAA has even gone after universities for file sharing, and this implicates the universities as being liable for the actions of their students. If you know anything about public colleges, then you should know that they generally have a huge aversion to any form of blocking because of the implications. After one student at my old school got arrested for child porn, a friend of mine who was the sys admin, removed all such groups from their news server, figuring that it wouldn't make for good publicity if they found the guy got it off of their own servers...well, when the guy's boss got wind of this, he forced him to add all of the groups back in. The view here is that it was a can of worms that they wanted nothing to do with as a proactive measure, and their job was not to enforce either moral standards nor the law itself. Spam is of course a serious problem, and one of the problems is that it causes ISP's to limit access to my servers by my own clients. I assure you that I am not the only one that feels this way, and it does affect your business, though maybe not measureably...it
RE: [Declude.JunkMail] SPAMDOMAINS and REVDNS
John, nothing should be listed in spamdomains unless it has a valid PTR , that's the very nature of the test - to test the mailfrom domain of a message that has a matching domain listed in spamdomains (again, which should already be confirmed to have valid PTR records), and reject those that either have no PTR or have an invalid PTR. Ah, I guess that is what I get for being busy and not fully paying attention to how the test works. Thanks. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.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.
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
That sounds like a nice crutch to have available. Much better IMO than setting up such a thing on a different server as IMail would seem to require. Am I correct in assuming that you can still secure things by way of SMTP AUTH without needing to accept every message coming into that port? And more importantly, would you be willing to share your fine work :) Matt Scott MacLean wrote: This may be a crutch solution, but it is what we have implemented, and our customers seem to like it. I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an intermediary between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser. At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats. I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I need direct access to my SMTP server for monitoring, I absolutely have to have a provider that allows SMTP traffic through. If the majority of ISP's played by the rules that you do, SMTP would be broken for all practical purposes as far as I'm concerned. If you ask around, most here don't consider blocking on DUL lists to be a wise thing to do, though using that in a weighting scheme is a decent idea. It's pretty clear that even Scott is being blocked by Road Runner's servers because of a poor implementation of a DUL list that includes his IP space even though it is static and business-class. Blocking outbound SMTP is even worse than blocking by DUL. I'm sure that many around here have had similar issues with large ISP's that improperly have tagged their IP space as being dynamic. I know that this practice negatively affects my business, and it's quite difficult to explain to a non-technical customer why this is, and never once has one of them been happy that their ISP has chosen to do so. Maybe you aren't aware of this affecting your business, but I, along with several of my LAN integrator friends, would absolutely not recommend an ISP that blocks outbound SMTP traffic because of the problems that it causes me, and the perception that such an implementation is a lazy way of fighting spam. And as far as my experience goes, none of the ISP's doing this that I have encountered went about this in a fully responsible manner. They all chose to make a change and then have me take the calls and do the diagnosis and call them for verification instead of alerting their customers as to the issues. This also starts encroaching into the areas of censorship and policing ones customers. Once you start getting involved with disallowing SMTP, you remove legitimate objections to blocking file sharing networks, and could even make yourself liable for such things. The industry has taken a very purposeful approach to this by usurping as much responsibility as possible. They don't want to become the Internet's police force, and costly defenses of John Doe's by places like Yahoo and Verizon were not intended to protect criminals, but instead to protect their businesses from liability and burden. The RIAA has even gone after universities for file sharing, and this implicates the universities as being liable for the actions of their students. If you know anything about public colleges, then you should know that they generally have a huge aversion to any form of blocking because of the implications. After one student at my old school got arrested for child porn, a friend of mine who was the sys admin, removed all such groups from their news server, figuring that it wouldn't make for good publicity if they found the guy got it off of their own servers...well, when the guy's boss got wind of this, he forced
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
That's a damn good solution. The ISP can block outbound spam from dynamic connections which stops the trojaned machines and the junior spammers. Your customer gets their mail to your server with no fuss. Well done. David DanielsSystem administratorStarfish Internet Service[EMAIL PROTECTED] - Original Message - From: Scott MacLean To: [EMAIL PROTECTED] Sent: Saturday, December 13, 2003 8:12 AM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts This may be a crutch solution, but it is what we have implemented, and our customers seem to like it.I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an "intermediary" between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser.At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPowercustomers. Once they understand that security and spam control requires thatthey use StarPower's SMTP service, they are very cooperative and happy tomake the adjustments. We are fanatical about customer service, and I willhave a tech talk a customer through the email setup, even if it takes anhour.I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats.I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I need direct access to my SMTP server for monitoring, I absolutely have to have a provider that allows SMTP traffic through. If the majority of ISP's played by the rules that you do, SMTP would be broken for all practical purposes as far as I'm concerned.If you ask around, most here don't consider blocking on DUL lists to be a wise thing to do, though using that in a weighting scheme is a decent idea. It's pretty clear that even Scott is being blocked by Road Runner's servers because of a poor implementation of a DUL list that includes his IP space even though it is static and business-class. Blocking outbound SMTP is even worse than blocking by DUL. I'm sure that many around here have had similar issues with large ISP's that improperly have tagged their IP space as being dynamic.I know that this practice negatively affects my business, and it's quite difficult to explain to a non-technical customer why this is, and never once has one of them been happy that their ISP has chosen to do so. Maybe you aren't aware of this affecting your business, but I, along with several of my LAN integrator friends, would absolutely not recommend an ISP that blocks outbound SMTP traffic because of the problems that it causes me, and the perception that such an implementation is a lazy way of fighting spam. And as far as my experience goes, none of the ISP's doing this that I have encountered went about this in a fully responsible manner. They all chose to make a change and then have me take the calls and do the diagnosis and call them for verification instead of alerting their customers as to the issues.This also starts encroaching into the areas of censorship and policing ones customers. Once you start getting involved with disallowing SMTP, you remove legitimate objections to blocking file sharing networks, and could even make yourself liable for such things. The industry has taken a very purposeful approach to this by usurping as much responsibility as possible. They don't want to become the Internet's police force, and costly defenses of John Doe's by places like Yahoo and Verizon were not intended to protect criminals, but instead to protect their businesses from liability and burden. The RIAA has even gone after universities for file sharing, and this implicates the universities as being liable for the actions of their students. If you know anything about public colleges, then you should know that they generally have a huge aversion to any form of blocking because of the
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
It would be even more damn good if IMail would allow you to specify the port per domain :) Maybe soon this won't be an issue. Matt David Daniels wrote: That's a damn good solution. The ISP can block outbound spam from dynamic connections which stops the trojaned machines and the junior spammers. Your customer gets their mail to your server with no fuss. Well done. David Daniels System administrator Starfish Internet Service [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - Original Message - From: Scott MacLean mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Saturday, December 13, 2003 8:12 AM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts This may be a crutch solution, but it is what we have implemented, and our customers seem to like it. I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an intermediary between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser. At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats. I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I need direct access to my SMTP server for monitoring, I absolutely have to have a provider that allows SMTP traffic through. If the majority of ISP's played by the rules that you do, SMTP would be broken for all practical purposes as far as I'm concerned. If you ask around, most here don't consider blocking on DUL lists to be a wise thing to do, though using that in a weighting scheme is a decent idea. It's pretty clear that even Scott is being blocked by Road Runner's servers because of a poor implementation of a DUL list that includes his IP space even though it is static and business-class. Blocking outbound SMTP is even worse than blocking by DUL. I'm sure that many around here have had similar issues with large ISP's that improperly have tagged their IP space as being dynamic. I know that this practice negatively affects my business, and it's quite difficult to explain to a non-technical customer why this is, and never once has one of them been happy that their ISP has chosen to do so. Maybe you aren't aware of this affecting your business, but I, along with several of my LAN integrator friends, would absolutely not recommend an ISP that blocks outbound SMTP traffic because of the problems that it causes me, and the perception that such an implementation is a lazy way of fighting spam. And as far as my experience goes, none of the ISP's doing this that I have encountered went about this in a fully responsible manner. They all chose to make a change and then have me take the calls and do the diagnosis and call them for verification instead of alerting their customers as to the issues. This also starts encroaching into the areas of censorship and policing ones customers. Once you start getting involved with disallowing SMTP, you remove legitimate objections to blocking file sharing networks, and could even make yourself liable for such things. The industry has taken a very purposeful approach to this by usurping as much responsibility as possible. They don't want to become the Internet's police force, and costly defenses of John Doe's by places like Yahoo and Verizon were not intended to protect criminals, but instead to protect their businesses from liability and burden. The RIAA has even gone after universities
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
You just have to be careful - I set up SMTP relay for addresses to accept connections from every IP in our group except for the IP of the mail server itself, so that our web servers can send mail without using SMTP AUTH. If you put the IP of the mail server in the relay for addresses list - or use a group that includes the mail server, you basically create an open relay - given, a relay using a nonstandard port number, but an open relay nonetheless. Exclude the mail server's IP, and it works properly, requiring SMTP AUTH from outside connections through the redirector. The mail server (and web messaging server and monitor) seem to have no issues with its own IP being excluded from the list. So yes, it works using SMTP AUTH - as long as the client use SMTP AUTH, it sends it right through. I had thoughts of actually marketing this as a product at some point, and wrote it as such - perhaps I should get off my arse and do it? Would there be interest in such a thing? At 06:09 PM 12/13/2003, Matthew Bramble wrote: That sounds like a nice crutch to have available. Much better IMO than setting up such a thing on a different server as IMail would seem to require. Am I correct in assuming that you can still secure things by way of SMTP AUTH without needing to accept every message coming into that port? And more importantly, would you be willing to share your fine work :) Matt Scott MacLean wrote: This may be a crutch solution, but it is what we have implemented, and our customers seem to like it. I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an intermediary between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser. At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats. I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I need direct access to my SMTP server for monitoring, I absolutely have to have a provider that allows SMTP traffic through. If the majority of ISP's played by the rules that you do, SMTP would be broken for all practical purposes as far as I'm concerned. If you ask around, most here don't consider blocking on DUL lists to be a wise thing to do, though using that in a weighting scheme is a decent idea. It's pretty clear that even Scott is being blocked by Road Runner's servers because of a poor implementation of a DUL list that includes his IP space even though it is static and business-class. Blocking outbound SMTP is even worse than blocking by DUL. I'm sure that many around here have had similar issues with large ISP's that improperly have tagged their IP space as being dynamic. I know that this practice negatively affects my business, and it's quite difficult to explain to a non-technical customer why this is, and never once has one of them been happy that their ISP has chosen to do so. Maybe you aren't aware of this affecting your business, but I, along with several of my LAN integrator friends, would absolutely not recommend an ISP that blocks outbound SMTP traffic because of the problems that it causes me, and the perception that such an implementation is a lazy way of fighting spam. And as far as my experience goes, none of the ISP's doing this that I have encountered went about this in a fully responsible manner. They all chose to make a change and then have me take the calls and do the diagnosis and call them for verification instead of alerting their customers as to the issues. This also starts encroaching into the areas of censorship and policing ones customers. Once you start getting involved with disallowing SMTP, you remove legitimate objections to blocking file sharing networks, and could even make yourself liable for such things. The industry has taken a
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
I'm not quite sure if that would work in my environment. I only recently started moving my IMail domains over to virtual ones, and most of them share the same IP as the Web sites that correspond to those domains. On the other hand, I have MS SMTP set up to handle all of the E-mail from the scripts on these sites except for just one case. I do have the entire block of addresses set up for relay, but it appears that in my case, I would need to remove this list and just allow the IP of my MS SMTP server and that one other IP, and make sure to change that client's configuration. All future domains are being directed at a single IP for local SMTP. Do you think this would work? Regarding marketing it as a product, I'd buy something at a reasonable price that gave me this ability and was stable enough to be relied upon. It would seem though that this might be a bit difficult to support as some small software products go, so there might be a trade-off there. In other words, is the extra work on your part necessary for supporting a product worth charging for it. Maybe you should gather some testers and get some feedback. The only problem here though is that once you start having clients configure a special port, you really need to continue to support that because client configurations can be problematic, especially when they are mostly spread around home computers or very small businesses when this issue presents itself, and they don't generally have an IT person that can do the configuration changes. I wouldn't want to roll something out that constantly needed attention, and couldn't be monitored effectively through some automated means. Maybe it might help to start by explaining the environment more fully, i.e. the language and how is it run as a service. Matt Scott MacLean wrote: You just have to be careful - I set up SMTP relay for addresses to accept connections from every IP in our group except for the IP of the mail server itself, so that our web servers can send mail without using SMTP AUTH. If you put the IP of the mail server in the relay for addresses list - or use a group that includes the mail server, you basically create an open relay - given, a relay using a nonstandard port number, but an open relay nonetheless. Exclude the mail server's IP, and it works properly, requiring SMTP AUTH from outside connections through the redirector. The mail server (and web messaging server and monitor) seem to have no issues with its own IP being excluded from the list. So yes, it works using SMTP AUTH - as long as the client use SMTP AUTH, it sends it right through. I had thoughts of actually marketing this as a product at some point, and wrote it as such - perhaps I should get off my arse and do it? Would there be interest in such a thing? At 06:09 PM 12/13/2003, Matthew Bramble wrote: That sounds like a nice crutch to have available. Much better IMO than setting up such a thing on a different server as IMail would seem to require. Am I correct in assuming that you can still secure things by way of SMTP AUTH without needing to accept every message coming into that port? And more importantly, would you be willing to share your fine work :) Matt Scott MacLean wrote: This may be a crutch solution, but it is what we have implemented, and our customers seem to like it. I wrote a small port redirection program that runs on the mail server. It listens on a specific port number, and when it receives a connection, opens a connection on the mail server on port 25, and acts as an intermediary between the two. Our customers reconfigure their clients to connect on this port number other than 25, it skips around the various ISP's port 25 blocking, they get to use our SMTP server, and noone is the wiser. At 12:21 AM 12/13/2003, Matthew Bramble wrote: Dave Doherty wrote: Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. I think you are assuming too much about your customers being happy under those arrangements. Maybe your outbound SMTP server is problem free, but the ISP's that are implementing such things are far from problem free in my experience, and I hate getting calls about why someone's E-mail isn't reaching it's destination when we aren't handling their outbound traffic. We also provide virus scanning on outbound traffic, which such a configuration defeats. I see this approach in the same light as closing down the highways because people speed. It punishes customers and providers that play by the rules, whereas only a small number are sending spam or have computers that are compromised to do so. Because I
