|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: open relays at Earthlink
Steve Davies wrote: > On Fri, 21 Aug 1998, Dalvenjah FoxFire wrote: > > > One extremely simple fix that the UUnet folks appear not to have stumbled > > upon is to firewall outgoing connections on port 25 to any hosts other > > than a specific list of earthlink, MSN, &etc mail hosts. This would only > > require reconfiguration on the part of the particularly obstinate customers > > who didn't follow the directions properly in the first place, and would > > for the most part kill off the relay hijacking that goes on from those > > networks. FWIW, I block port 25 on all my dialups, except to my own mail servers. Only 2 customers complained. One was actually a mail-only customer who dialed another small ISP in another state. We assisted him in changing his configuration to using the mail server at his dialup ISP. The other was roaming to numerous ISPs and was a more complicated case. > ISPs sell customers a TCP/IP connection to the Internet. To me that means > taking my IP datagrams and delivering them to where I address them. I > don't see that filtering of outbound traffic is part of such a product, > any more than hijacking my connects to port 80 somewhere and plumbing me > into a "transparent" web cache is. Not all ISPs do that. Some sell a limited service consisting of a subset of the entire scope of possible IP packets. Of course there are also many that sell IP "wide open". You can take your pick. I elect to offer just those services which offer what I feel to be the best combination of what most of my customers want, and what allows me to continue to offer these services to all customers. Those "services" that result in my staff having to deal with huge volumes of complaints, denial of service attacks, and being filtered by other ISPs, I simply do not offer. > On the other hand, I would fully support anyone's right to filter > connections from my dialin user pool addresses if they felt that they > needed to do that. I would, in my personal opinion, be happy to provide > such a person with my IP pool address ranges, or info on the domain names > we use for that (which are easy to deduce, anyway?). I won't need to take advantage of your offer since my mail servers are not open for relaying. If I or my customers receive spam from your customers, it will either be delivered the correct way, or be delivered via a direct connection on port 25 to a mail server that is open for relaying. My main goal is to block the spam using the latter method since it predominates. But in the course of discovering all the little poorly administered mail servers that can be used as relays, I and my customers will have to endure tons of spam, and I will get less real work done. > (Of course, I'd rather persuade this person than my organization deals > responsibly with spammers - but no doubt I'd be unable to persuade some) Most spam is sent using the "hit and run" method. Cancelling the account is pointless, as it probably won't be used again. Putting a stop on the CC number from getting further accounts may help some, but they can use other numbers, or the numbers may be stolen, or they just go to other ISPs. IMHO, if you want to prevent spam from being sent by your customers, that is, if you do _not_ offer this as a service, then you need to block it. If you do not block it, then IMHO, you are offering it (whether for pay or for free). > If enough people refused to take mail from my pool addresses then I guess > my customers will be duly "encouraged" to use the provided relays. (Most > do anyway, of course) If only a few refuse to take the mail then most > deliveries still work fine directly; and those few feel happy that they > are "protected". The majority of mail servers are run by small businesses with little to no average technical knowledge, and rarely do much to deal with it, especially since most spam software distributes the load rather evenly so no one server gets hit too hard. Getting this _large_ number of servers to clean up their act is difficult at best due to these large numbers, and the constant arrival of more servers. Unlike mail servers, the greatest growth in dialup is large providers like UUNET. The technical knowledge > Doesn't this arrangement make sense? It makes sense, but it is not practical. I have not yet added mail filtering that allows me to scan every "Received" header for any mention of known dialup spam sources. If/when I do, UUNET will be one of the early ones I will have to add (depending on the growth rate of spam). The worst source I see this month is ATT Canada, not UUNET. What does UUNET do to _prevent_ spam originating from people so bent on sending it that they will disregard the policy and proceed to send spam anyway, if the service of connecting to any port 25 is offered to them? It's not good enough to cancel an account that has already been sacrified by the "customer". They don't pay and you don't get any money, but then you don't lose anything, either. > Regards, > Steve Davies > Operations, UUNET UK > (Who is in the UUNET group but does not influence policy for UUNET US) What we are trying to do is to influence policy, not just for UUNET anywhere, but all others. Influencing spammers themselves is not going to work. So someone else has to be influenced. We're going to choose who to influece based on what appears to be the most practical course to the desired end result. Much talk is about network peering. We generally don't think about it this way, but e-mail is a form of peering, too. Any it is getting to look like more and more of us will have to suspend such peering in certain cases. We will want to influence your good paying customers to switch to whatever of your competition discovers that they can gain these customers by applying the kind of filtering mentioned early on, blocking port 25 access. -- Phil Howard | [email protected] [email protected] [email protected] phil | [email protected] [email protected] [email protected] at | [email protected] [email protected] [email protected] ipal | [email protected] [email protected] [email protected] dot | [email protected] [email protected] [email protected] net | [email protected] [email protected] [email protected]
|