Date: Tue, 28 Sep 1999 23:11:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: n@nectar.com (Jacques Vidrine) Cc: freebsd@gndrsh.dnsmgr.net, chat@FreeBSD.ORG Subject: Re: Filtering port 25 (was Re: On hub.freebsd.org refusing to talk to dialups) Message-ID: <199909282311.QAA13317@usr07.primenet.com> In-Reply-To: <19990925003530.6331CBE08@gw.nectar.com> from "Jacques Vidrine" at Sep 24, 99 07:35:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques Vidrine writes: > > Well, I started the first ISP in New Orleans in 1994, and ran it > through late 1998. I was VP Technology of Verio Midamerica for most > of 1998 as well (that involved 10 ISP operations). I'm fairly > familiar with the problem. :-) In fact, I've dealt with this very > issue (filtering packets with destination TCP port 25 and a dial-up > source address) before. So, I do speak from some experience. > > I am not advocating making it easy for spammers. The RBL has been a > huge help, and the DUL looks potentially even more helpful. I just > object to blocking legitimate traffic. > > I applaud your effort at monitoring this traffic from your dial-up > users, to help you catch spammers early, but filtering should be > something for which they opt-in. Exactly. SPAM is something you can only act on post-facto, and then only once a violation of contract (e.g. an Acceptable Use Policy) has taken place. Rate limitation of outbound email through a transparent proxy server (based on service class and Quality Of Service warrants) is acceptable, as is setting trigger points below which legitimate customers are not harrassed. > > If we have an AUP that states that all outbound smtp port 25 connections > > shall be via our smarthost relay hosts we darn well have a right not > > only to monitor that this is being done, we further more have a right > > to inforce it if we so decide to. > > Of course you do have the ``right'', in a legal sense. An ``ISP'' also > has the right to not deliver any traffic with a destination port of, > say, 17, or 80 even. That doesn't make it a _good_ policy. To risk > repeating myself, I believe that a company that doesn't deliver the > legitimate (non-fraudulent) traffic of its customers is _not_ really > an Internet Service Provider, but something else. ``A JSP perhaps?'' a > friend and colleague of mine, with much more experience than me, once > said :-) Exactly right. > Analogously, a host can choose not to support, say, IP fragment > reassembly, but then it isn't then a host (by RFC 1122). 8-). > Yes, I know there is no RFC or other standards document that says what > an ISP is and how one must perform. I am merely expressing my opinion > on the matter. Actually, there should be such RFC's. At the very least, it is a topic ripe for Best Current Practice RFC's. > > We don't, but your violating IETF standards by doing anything other > > than smtp on port 25 of tcp. > > AFAIK, there is no IETF standard which disallows traffic other than > SMTP to flow on port 25. That isn't to say that it is wise to use > ports in a way that conflict with the IANA Assigned Numbers > (rfc1700?). Such use would probably be a response to some temporary > problem, or maybe an experimental protocol. But, the point is, that > is not the concern of the ISP. It is the business of the customer, > only. The ISP is simply to deliver the packets from A to B. Yes. Legally, it's important for ISP's to be recognized as common carriers, such that the Australia debacle gets resolved, and the responsibility of implementing the unfunded mandates of a foreign government does not devolve to people who are not even citizens of the offending country. Telephone carriers are not held legally responsible for interstate data transport (for example), even when said transport violates local community standards. They are common carriers; it is not seen to be their job to police their customers actions. This is not to say that ISP's should not have themselves held to account for the standards of conduct of their customers, nor that they should be permitted to disclaim all responsibility on the basis of their failure to contractually oblicate their customers to appropriate AUP's. But to hold someone responsible for the actions of another, especially if those actions are squelched quickly when they are reported, via contractual enforcement, is just wrong. > You skipped the issue of customers that do not wish to push their SMTP > traffic through your mail server (which is the more realistic > scenario). What do you do with the conscientious business customer > that has dial-up account with you, but due to company policy needs to > push SMTP through their own mail server? This is a common practice; however, you can charge these people more, since if they were to fan out through your servers, they would not tie up your (presumably lower bandwidth) downstream resources. A more and more common practice is, for reasons of security, to push the SMTP connection between two disparately located over a VPN. Unless you disallow VPN's, there are good business cases as to why a customer would not want someone, perhaps a disgruntled employee of their ISP, snooping their sensitive corporate data. Or worse, selling the relay mail logs from the server you forced your customers to use to SPAM'mers, who will then SPAM both ends of each connection. This is not a hypothetical situation; I have heard reports of just this at various ISP's and "mail portals". > > ISP's are _not_ common carriers, or at least the courts haven't made > > up thier minds on this one. > > I don't suggest that they are common carriers (though I would guess > that in time they will be). Me too! > I suggest that an ISP is in the business of moving packets. > Arbitrarily filtering packets conflicts with that business. Well, there's your stated business, and then there's your business. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909282311.QAA13317>