RE: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Indicts
Hm No sir, I don't like it! In the end where this is headed is that if you belong to their group then they will legitimize any messages that you send... then they will use their combined resources to loby and otherwise make it a bad thing for you to do any kind of filtering to their messages. The problem I see with this is that the receiver eventually loses control and power over that decision migrates toward those who have the money to pay for access. In my view it is another form of the sender-pays line of thinking - but worse because the paying part is downplayed. A tip-off is that the counter to this argument is up-front in their proposal. Specifically that they will create and manage a mechanism that tracks the end-user's subscrbe/unsubscribe requests... I think this is a lot like putting the foxes in charge of the hen house. My $0.02. _M |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of |Burzin Sumariwalla |Sent: Thursday, December 18, 2003 2:12 PM |To: [EMAIL PROTECTED] |Subject: Re: [Declude.JunkMail] Outbound Port 25, was - |Virginia Indicts Indicts | | |Does any one have comments on any of the following: | |http://www.computerworld.com/softwaretopics/software/groupware/ |story/0,10801,80626,00.html | |Project Lumos | |http://www.camram.org | |CANRAM | |Burzin | | |At 09:01 PM 12/15/2003, you wrote: | |How about some new suggestions for methods to combat the spammers? | |- | |--- |[This E-mail scanned for viruses by Declude Virus] | |--- |[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 virus scanned by 4C Web] | | |--- |[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 scanned for viruses by Declude Virus] | |-- |Burzin Sumariwalla Phone: (314) 994-9411 x291 |[EMAIL PROTECTED] Fax: (314) 997-7615 | Pager: (314) 407-3345 | |Networking and Telecommunications Manager |Information Technology Services |St. Louis County Library District |1640 S. Lindbergh Blvd. |St. Louis, MO 63131 | |--- |[This E-mail scanned for viruses by Declude Virus] | |--- |[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] Outbound Port 25, was - Virginia Indicts Indicts
Pete McNeil wrote: A tip-off is that the counter to this argument is up-front in their proposal. Specifically that they will create and manage a mechanism that tracks the end-user's subscrbe/unsubscribe requests... I think this is a lot like putting the foxes in charge of the hen house. I thought the tip-off was where they claimed that 15% of legitimate commercial E-mail was being blocked :) The good thing is that this will go no where because there are too many of us, and if it's unwanted and we block it, it only makes them look all the worse. As things stand, they have a lot of catching up to do. You don't create a monopoly out of anarchy. Matt --- [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 Indicts
|Pete McNeil wrote: | |A tip-off is that the counter to this argument is up-front in their |proposal. Specifically that they will create and manage a mechanism |that tracks the end-user's subscrbe/unsubscribe requests... I think |this is a lot like putting the foxes in charge of the hen house. | | |I thought the tip-off was where they claimed that 15% of legitimate |commercial E-mail was being blocked :) Just like me to miss the obvious first time around %^b _M --- [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 Indicts
Does any one have comments on any of the following: http://www.computerworld.com/softwaretopics/software/groupware/story/0,10801,80626,00.html Project Lumos http://www.camram.org CANRAM Burzin At 09:01 PM 12/15/2003, you wrote: How about some new suggestions for methods to combat the spammers? - --- [This E-mail scanned for viruses by Declude Virus] --- [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 virus scanned by 4C Web] --- [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 scanned for viruses by Declude Virus] -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [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 Indicts
Yes, I like the idea of reassuring that an unsubscribe site is not used for harvesting. I recognize that people often report something as spam, because they feel it's safer than being tricked into unsubscribing. Rather than getting negative weight du to Spamcop and being blocked, messages could pass to those people who truly wanted to know what items are new at Walmart. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Burzin Sumariwalla Sent: Thursday, December 18, 2003 02:12 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Indicts Does any one have comments on any of the following: http://www.computerworld.com/softwaretopics/software/groupware/story/0,10801 ,80626,00.html Project Lumos http://www.camram.org CANRAM Burzin At 09:01 PM 12/15/2003, you wrote: How about some new suggestions for methods to combat the spammers? - --- [This E-mail scanned for viruses by Declude Virus] --- [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 virus scanned by 4C Web] --- [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 scanned for viruses by Declude Virus] -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [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] Outbound Port 25, was - Virginia Indicts
Hi Darin, For the sake or arguement, I'm assuming one keeps one's server and up-to-date, patched, and takes prudent efforts to secure these devices. Most people probably don't secure workstations well enough. The server side of the equation is too complex. I don't think you (as an individual) can prevent spam from being sent. You can only control the email that you send and the actions you take in response to spam. You as an administator can prevent Spam from being sent outbound, but beyond securing the server and taking prudent measures your users are going to have to put up with false positives. Businesses run on email, and I'm not sure most companies would be willing to take such risks. Burzin At 09:12 PM 12/12/2003, you wrote: Everyone keep the ideas flowing... maybe we can come up with ideas as to how to keep spam from being sent to begin with. -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [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
Hi Burzin, I wasn't thinking from an individual standpoint, but globally, as in cooperative efforts by all mail system providers to provide traceability and valid sender enforcement. I certainly realize that I individually have no control over others' systems to prevent spam, but with cooperative efforts between all providers we can make a difference. Not sure about the second part of your argument regarding FPs and business risk, and how it relates to this topic. Certainly I've always taken the stance that we have to err on the conservative side to ensure all legitimate business correspondence gets delivered, even if it means some spam gets through. My point is again that I'd like us to all put our heads together to see what measures we can initiate that will prevent spam from being sent in the first place. Outbound port 25 blocking from dynamic addresses is a start, but would only be partially effective as trojans, open relays, and port redirectors allow spammers to get around it. I guess what I was thinking is if we all could come up with a scenario to all but eliminate spam through cooperation by all providers, we could write up our recommendations and publish the results to the major players, lobbyists, and independent and government agencies to try to make it happen. As I mentioned before I'm wary of efforts that encourage spammers to develop viruses and worms to circumvent the blocks we put in place, as that could be a much bloodier battle than the one we're currently in, but here's what I think the initial pieces to this are. There are obvious holes in this list, though, and it doesn't completely solve the problem. 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. 2. Port 25 blocking for all dynamic addresses with all network providers. This could cause some problems as I'm sure there are many legitimate networks that send from internal networks that are only connected via dynamic addresses, but it seems to be a critical piece to this effort. Forcing businesses that run internal mail servers to static addresses might not be a bad thing, though. 3. Globally managed open relay list and blacklist, preferably maintained by some sort of non-profit internet council. This could help close many open relays if an authoritative, complete list was formed and maintained. This organization should be responsive to removal requests, but require the burden of proof on the petitioner. 4. SMTP AUTH required on all SMTP servers, forcing users to properly authenticate in order to send. This might help reduce the virus threat. This is far from foolproof as the virus could use local mail profiles that have been set up with SMTP AUTH instead of embedding it's own SMTP component, but it's a start. I know that this won't be easy, but if we could make it happen, the end result would be extremely satisfying. Any comments, or other ideas to add to this list? Scott, sorry if this is too far off-topic, but I thought this would be a good community to discuss the possibilities. Let me know if you'd rather we take this discussion to another list. Darin. - Original Message - From: Burzin Sumariwalla [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 11:19 AM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Hi Darin, For the sake or arguement, I'm assuming one keeps one's server and up-to-date, patched, and takes prudent efforts to secure these devices. Most people probably don't secure workstations well enough. The server side of the equation is too complex. I don't think you (as an individual) can prevent spam from being sent. You can only control the email that you send and the actions you take in response to spam. You as an administator can prevent Spam from being sent outbound, but beyond securing the server and taking prudent measures your users are going to have to put up with false positives. Businesses run on email, and I'm not sure most companies would be willing to take such risks. Burzin At 09:12 PM 12/12/2003, you wrote: Everyone keep the ideas flowing... maybe we can come up with ideas as to how to keep spam from being sent to begin with. -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [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
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
Hi Darin, At 02:14 PM 12/15/2003, you wrote: Hi Burzin, I wasn't thinking from an individual standpoint, but globally, as in cooperative efforts by all mail system providers to provide traceability and valid sender enforcement. I certainly realize that I individually have no control over others' systems to prevent spam, but with cooperative efforts between all providers we can make a difference. I think what you are saying (traceability and valid sender) can be summed up as good email server management. RFCs provide a good place to start, but as many people on the list have pointed out, many server admins don't abide by these practices. Sometimes it's out of ignorance, sometimes its out of laziness, and sometimes admin knows what they are doing and has a valid reason for it. This doesn't even address RFC compliance by the software developers on the server or client side. Ultimately some of this may be fixed by a successor to SMTP. This may not be a bad route to pursue, but there's always this thing about backwards compatibility. As an Imail admin., I use the Delcude, Sniffer, and Imail forums/resources to make sure I'm following best practices. There are other flavors out there. Is there better forum, or site that can be used by admins to secure their servers, understand the dos and don'ts, and correctly implemement them? Not sure about the second part of your argument regarding FPs and business risk, and how it relates to this topic. Certainly I've always taken the stance that we have to err on the conservative side to ensure all legitimate business correspondence gets delivered, even if it means some spam gets through. SMTP is a dual edged sword it works very well on a technical and social/business levels. However, its precisely because it works well on these levels that we have to deal with spam. If a large enough ISP or a group of ISPs takes action to prevent spam and if these efforts prevent enough mail from being delivered or make it a hastle for email to be delivered, it dimishes the utility of email. My point is again that I'd like us to all put our heads together to see what measures we can initiate that will prevent spam from being sent in the first place. Outbound port 25 blocking from dynamic addresses is a start, but would only be partially effective as trojans, open relays, and port redirectors allow spammers to get around it. I guess what I was thinking is if we all could come up with a scenario to all but eliminate spam through cooperation by all providers, we could write up our recommendations and publish the results to the major players, lobbyists, and independent and government agencies to try to make it happen. As I mentioned before I'm wary of efforts that encourage spammers to develop viruses and worms to circumvent the blocks we put in place, as that could be a much bloodier battle than the one we're currently in, but here's what I think the initial pieces to this are. There are obvious holes in this list, though, and it doesn't completely solve the problem. I think we are only a step or two (at most) away from spammers developing viruses/worms. 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. I do this myself, but I can imagine organizations where they may not want this information out there for all to see. 2. Port 25 blocking for all dynamic addresses with all network providers. This could cause some problems as I'm sure there are many legitimate networks that send from internal networks that are only connected via dynamic addresses, but it seems to be a critical piece to this effort. Forcing businesses that run internal mail servers to static addresses might not be a bad thing, though. A subject of much discussion and consternation. I weight dynamic addresses. 3. Globally managed open relay list and blacklist, preferably maintained by some sort of non-profit internet council. This could help close many open relays if an authoritative, complete list was formed and maintained. This organization should be responsive to removal requests, but require the burden of proof on the petitioner. I think we have several defacto lists out there already. Some of these are free, but I suspect that the better ones will become non-profits and charge a subscription. 4. SMTP AUTH required on all SMTP servers, forcing users to properly authenticate in order to send. This might help reduce the virus threat. This is far from foolproof as the virus could use local mail profiles that have been set up with SMTP AUTH instead of embedding it's own SMTP component, but it's a start. I do this now, but had to get all my users upgraded to correct clients. I know that this won't be easy, but if we could make it happen, the end result would be extremely satisfying. Any comments, or other ideas to add to
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
snip I think what you are saying (traceability and valid sender) can be summed up as good email server management. /snip Yes, I believe most of us on the list do this. The point is bringing more awareness to the global community to encourage all admins to do this. snip but as many people on the list have pointed out, many server admins don't abide by these practices. /snip Ditto from above snip Ultimately some of this may be fixed by a successor to SMTP. This may not be a bad route to pursue, but there's always this thing about backwards compatibility. /snip I've long advocated a successor to SMTP to deal with the authentication and traceability issues snip If a large enough ISP or a group of ISPs takes action to prevent spam and if these efforts prevent enough mail from being delivered or make it a hastle for email to be delivered, it dimishes the utility of email. /snip Yes, obviously we need to make to make every effort to ensure valid email gets delivered. That's why I suggested a global internet council to support tighter standards. Again, the only way we're going to win this battle is through cooperation. snip I think we are only a step or two (at most) away from spammers developing viruses/worms. /snip They already have. I want to avoid encouraging them to be more active in this area. Again, soliciting suggestions for this. snip 1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with. I do this myself, but I can imagine organizations where they may not want this information out there for all to see. /snip Again, cooperation is needed. snip 2. Port 25 blocking for all dynamic addresses with all network providers. ... A subject of much discussion and consternation. I weight dynamic addresses. /snip With weighting only for dynamic addresses, there is always the possibility that spam can slip through. If we shut down other ways of sending, not blocking dynamic addresses will result in a mich higher percentage of spam getting through. snip I think we have several defacto lists out there already. Some of these are free, but I suspect that the better ones will become non-profits and charge a subscription. /snip None are adequate to the needs. That's why I suggested a global internet council to manage them. snip 4. SMTP AUTH required on all SMTP servers, forcing users to properly ... I do this now, but had to get all my users upgraded to correct clients. snip We switched about three years ago, but it was well received by our customer base. Yes, all of these suggestions will take some effort, but the end result of this, along with other suggestions not as yet raised, will be significant progress in the battle. How about some new suggestions for methods to combat the spammers? - --- [This E-mail scanned for viruses by Declude Virus] --- [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 virus scanned by 4C Web] --- [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] 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 im
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
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
Has anyone considered the trouble this causes to remote mail hosts? First this has caused many calls from my fairly small customer base whenever someone starts all of a sudden blocking port 25. Secondly, it limits my capabilities as I can no longer handle their outgoing E-mail. Third, this creates issues where things like slow ISP mail servers, blocked E-mail and other issues related to the ISP impact my business regardless of my ability to control it. If an ISP is going to do this as a practice, they shouldn't do it from dynamic addresses, and they should have a simple method of asking that a static IP be allowed to use port 25. If Road Runner ever did this to me, I would be gone the next day even if I had to deal with slower speeds with DSL. This is a very bad idea, and it's a kluge of a fix for what should be done through monitoring and action only on those that cause problems. ISP's should be proactive in monitoring for zombied machines and shutting off certain ports to them when found. I know that some large ISP's do this type of thing already, but there needs to be some products that the smaller ISP's also integrate so that the blunt-force method doesn't stop companies like me from better serving business customers. If the trend keeps up, I'll probably look at ways to accept SMTP connections over port 80 as a work around, but that expense comes out of my pocket for no good reason IMO. Matt Burzin Sumariwalla wrote: I was thinking of something much simpler... Verifying that the IP appears in a MX record Verifying that Reverse DNS is set Basically the RFC ignorant stuff... Of course your network would have to deal with traffic before shunning it. :( I like your idea much better. Burzin At 01:10 PM 12/12/2003, you wrote: If ISPs would block outbound port 25 that would go a long way towards keeping spam. Right now most of our spam is coming from cable and DSL IPs. We block outbound port 25 except from our mail servers and a couple of customers who have a legitimate reason to use another mail server. If so we open a hole to that mail server only. It's done on a case by case basis. Is it a pain in the ass? Most certainly but if any spam leaves our network it will be easy as hell to track. It really burns my ass to be spammed from these networks because the provider is either too lazy or incompetent to block these ports. David Daniels Administrator Starfish Internet Service [EMAIL PROTECTED] - Original Message - From: Burzin Sumariwalla [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 1:22 PM Subject: OT: [Declude.JunkMail] Virginia Indicts Two Men On Spam Charges I agree with you. The statement was more general than it should have been. Personally I think the ISP route is one of the best places to begin active anti-spam measures at (Sorry ISP admins). If legislatively, ISPs can be forced to have customers adhere to strict RFC compliance and if legislatively ISPs can be forced to take consistent and strict measures it might force spammers into smaller and smaller corners. I don't represent and ISP, so maybe I'm being to optimistic. Burzin At 10:59 AM 12/12/2003, you wrote: The only people that will hit the spammers' pocketbooks are the ISPs getting together and forcing them out of their jobs... or to get people to stop buying their stuff! -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [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 scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --- [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 scanned for viruses by Declude Virus] -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail was scanned for viruses by Declude Virus
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
Dynamic IP's is exactly where it should be done, that's where most of the spam comes from. As far as serving your customers goes it's easy enough to open a hole for a customer with a legitimate reason to use a remote mail server. Any action is going to be a pain for someone, that's the reason spam is so rampant. In the interest of free and open communication we've let things get too lax. Sometimes for good reason. It would be great to use reverse DNS or rather the lack of as a reason to reject mail but this results in rejecting mail from not only the new or clueless admin but also the many whose providers don't give them control of their reverse DNS. Blocking port 25 will accomplish nearly as much with a lot less pain I believe. Most customers simply don't have the need to use a remote SMTP server and one line in an access list will take care of those who do. It's more trouble for the provider for sure yet if enough people did it the resulting savings in spam control would make up for it many times. Road Runner is one that should do it by the way. We get a lot of spam from their dynamic IPs. They should have no trouble doing a DNS entry and opening port 25 for a paying business customer. David Daniels System administrator Starfish Internet Service [EMAIL PROTECTED] - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 5:25 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Has anyone considered the trouble this causes to remote mail hosts? First this has caused many calls from my fairly small customer base whenever someone starts all of a sudden blocking port 25. Secondly, it limits my capabilities as I can no longer handle their outgoing E-mail. Third, this creates issues where things like slow ISP mail servers, blocked E-mail and other issues related to the ISP impact my business regardless of my ability to control it. If an ISP is going to do this as a practice, they shouldn't do it from dynamic addresses, and they should have a simple method of asking that a static IP be allowed to use port 25. If Road Runner ever did this to me, I would be gone the next day even if I had to deal with slower speeds with DSL. This is a very bad idea, and it's a kluge of a fix for what should be done through monitoring and action only on those that cause problems. ISP's should be proactive in monitoring for zombied machines and shutting off certain ports to them when found. I know that some large ISP's do this type of thing already, but there needs to be some products that the smaller ISP's also integrate so that the blunt-force method doesn't stop companies like me from better serving business customers. If the trend keeps up, I'll probably look at ways to accept SMTP connections over port 80 as a work around, but that expense comes out of my pocket for no good reason IMO. Matt Burzin Sumariwalla wrote: I was thinking of something much simpler... Verifying that the IP appears in a MX record Verifying that Reverse DNS is set Basically the RFC ignorant stuff... Of course your network would have to deal with traffic before shunning it. :( I like your idea much better. Burzin At 01:10 PM 12/12/2003, you wrote: If ISPs would block outbound port 25 that would go a long way towards keeping spam. Right now most of our spam is coming from cable and DSL IPs. We block outbound port 25 except from our mail servers and a couple of customers who have a legitimate reason to use another mail server. If so we open a hole to that mail server only. It's done on a case by case basis. Is it a pain in the ass? Most certainly but if any spam leaves our network it will be easy as hell to track. It really burns my ass to be spammed from these networks because the provider is either too lazy or incompetent to block these ports. David Daniels Administrator Starfish Internet Service [EMAIL PROTECTED] - Original Message - From: Burzin Sumariwalla [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 1:22 PM Subject: OT: [Declude.JunkMail] Virginia Indicts Two Men On Spam Charges I agree with you. The statement was more general than it should have been. Personally I think the ISP route is one of the best places to begin active anti-spam measures at (Sorry ISP admins). If legislatively, ISPs can be forced to have customers adhere to strict RFC compliance and if legislatively ISPs can be forced to take consistent and strict measures it might force spammers into smaller and smaller corners. I don't represent and ISP, so maybe I'm being to optimistic. Burzin At 10:59 AM 12/12/2003, you wrote: The only people that will hit the spammers' pocketbooks are the ISPs getting together and forcing them out of their jobs... or to get people
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
While I generally agree with port 25 blocking as an interim mechanism to stem the tide of spam, especially from dynamic IPs, more and more is coming from trojan viruses that get installed on poorly protected PCs. All we need right now is to add an economic incentive to the worm/virus threat, which has the potential to be a much more insidious problem. Bottom line: The open architecture of the internet is coming back to haunt us. Not enough safeguards were put in place to protect from this unforeseen problem. Traceability is one of the most important aspects of policy enforcement, but as in port blocking, that would also encourage spam worms and viruses... and it still treats the symptoms and not the cause. Everyone keep the ideas flowing... maybe we can come up with ideas as to how to keep spam from being sent to begin with. Darin. - Original Message - From: David Daniels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 7:12 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Dynamic IP's is exactly where it should be done, that's where most of the spam comes from. As far as serving your customers goes it's easy enough to open a hole for a customer with a legitimate reason to use a remote mail server. Any action is going to be a pain for someone, that's the reason spam is so rampant. In the interest of free and open communication we've let things get too lax. Sometimes for good reason. It would be great to use reverse DNS or rather the lack of as a reason to reject mail but this results in rejecting mail from not only the new or clueless admin but also the many whose providers don't give them control of their reverse DNS. Blocking port 25 will accomplish nearly as much with a lot less pain I believe. Most customers simply don't have the need to use a remote SMTP server and one line in an access list will take care of those who do. It's more trouble for the provider for sure yet if enough people did it the resulting savings in spam control would make up for it many times. Road Runner is one that should do it by the way. We get a lot of spam from their dynamic IPs. They should have no trouble doing a DNS entry and opening port 25 for a paying business customer. David Daniels System administrator Starfish Internet Service [EMAIL PROTECTED] - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 5:25 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Has anyone considered the trouble this causes to remote mail hosts? First this has caused many calls from my fairly small customer base whenever someone starts all of a sudden blocking port 25. Secondly, it limits my capabilities as I can no longer handle their outgoing E-mail. Third, this creates issues where things like slow ISP mail servers, blocked E-mail and other issues related to the ISP impact my business regardless of my ability to control it. If an ISP is going to do this as a practice, they shouldn't do it from dynamic addresses, and they should have a simple method of asking that a static IP be allowed to use port 25. If Road Runner ever did this to me, I would be gone the next day even if I had to deal with slower speeds with DSL. This is a very bad idea, and it's a kluge of a fix for what should be done through monitoring and action only on those that cause problems. ISP's should be proactive in monitoring for zombied machines and shutting off certain ports to them when found. I know that some large ISP's do this type of thing already, but there needs to be some products that the smaller ISP's also integrate so that the blunt-force method doesn't stop companies like me from better serving business customers. If the trend keeps up, I'll probably look at ways to accept SMTP connections over port 80 as a work around, but that expense comes out of my pocket for no good reason IMO. Matt Burzin Sumariwalla wrote: I was thinking of something much simpler... Verifying that the IP appears in a MX record Verifying that Reverse DNS is set Basically the RFC ignorant stuff... Of course your network would have to deal with traffic before shunning it. :( I like your idea much better. Burzin At 01:10 PM 12/12/2003, you wrote: If ISPs would block outbound port 25 that would go a long way towards keeping spam. Right now most of our spam is coming from cable and DSL IPs. We block outbound port 25 except from our mail servers and a couple of customers who have a legitimate reason to use another mail server. If so we open a hole to that mail server only. It's done on a case by case basis. Is it a pain in the ass? Most certainly but if any spam leaves our network it will be easy as hell to track. It really burns my ass to be spammed from these networks because the provider is either too lazy or incompetent
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
David and Matt- Congratulations, David, on finding and implementing the best way to deal this issue. I own a hosting company in the DC area, and StarPower here is doing the same thing that you are. Now if only we could get Verizon, Comcast, RR and the others to follow suit, things could be a lot better. Verizon took the opposite approach. They refuse to provide SMTP transport unless they host the domain, and they leave their entire system open on port 25. This was done in the name of spam reduction about two years ago. All it did was force me into the SMTP AUTH business to cut down traffic on their mailservers. And, oh yeah, the marketing implications of the move were not lost on me. We did not lose a single customer to this scam, but it took a lot of effort since we have a large number of customers who use Verizon DSL for access. I thought the RFCs required access providers to provide outbound SMTP transport for all their customers. The access providers, after all, are the only ones who know whether the senders are legit. So either I'm wrong, or Verizon is. 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. We've been in business since 1995, and we never provided SMTP transport until Verizon's move. -Dave Doherty Skywaves, Inc. - Original Message - From: David Daniels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 7:12 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Dynamic IP's is exactly where it should be done, that's where most of the spam comes from. As far as serving your customers goes it's easy enough to open a hole for a customer with a legitimate reason to use a remote mail server. Any action is going to be a pain for someone, that's the reason spam is so rampant. In the interest of free and open communication we've let things get too lax. Sometimes for good reason. It would be great to use reverse DNS or rather the lack of as a reason to reject mail but this results in rejecting mail from not only the new or clueless admin but also the many whose providers don't give them control of their reverse DNS. Blocking port 25 will accomplish nearly as much with a lot less pain I believe. Most customers simply don't have the need to use a remote SMTP server and one line in an access list will take care of those who do. It's more trouble for the provider for sure yet if enough people did it the resulting savings in spam control would make up for it many times. Road Runner is one that should do it by the way. We get a lot of spam from their dynamic IPs. They should have no trouble doing a DNS entry and opening port 25 for a paying business customer. David Daniels System administrator Starfish Internet Service [EMAIL PROTECTED] - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 12, 2003 5:25 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Has anyone considered the trouble this causes to remote mail hosts? First this has caused many calls from my fairly small customer base whenever someone starts all of a sudden blocking port 25. Secondly, it limits my capabilities as I can no longer handle their outgoing E-mail. Third, this creates issues where things like slow ISP mail servers, blocked E-mail and other issues related to the ISP impact my business regardless of my ability to control it. If an ISP is going to do this as a practice, they shouldn't do it from dynamic addresses, and they should have a simple method of asking that a static IP be allowed to use port 25. If Road Runner ever did this to me, I would be gone the next day even if I had to deal with slower speeds with DSL. This is a very bad idea, and it's a kluge of a fix for what should be done through monitoring and action only on those that cause problems. ISP's should be proactive in monitoring for zombied machines and shutting off certain ports to them when found. I know that some large ISP's do this type of thing already, but there needs to be some products that the smaller ISP's also integrate so that the blunt-force method doesn't stop companies like me from better serving business customers. If the trend keeps up, I'll probably look at ways to accept SMTP connections over port 80 as a work around, but that expense comes out of my pocket for no good reason IMO. Matt Burzin Sumariwalla wrote: I was thinking of something much simpler... Verifying that the IP appears in a MX record Verifying that Reverse DNS is set Basically the RFC ignorant stuff
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts
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 certainly affects mine and I'm not the one blocking this stuff. Matt --- [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.
