Date: Fri, 24 Sep 1999 21:40:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brett@lariat.org (Brett Glass) Cc: alk@pobox.com, gary@eyelab.psy.msu.edu, chat@FreeBSD.ORG Subject: Re: On hub.freebsd.org refusing to talk to dialups Message-ID: <199909242140.OAA26254@usr05.primenet.com> In-Reply-To: <4.2.0.58.19990924144336.04490ba0@localhost> from "Brett Glass" at Sep 24, 99 02:48:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Our community network's mail server refuses connections from dialups, and > this has cut our spam by about 80-90%. Many ISPs also firewall outgoing TCP > sessions on port 25 to prevent "hit and run" spam from throwaway accounts. > > Neither is an ideal solution, but until authenticated mail becomes widespread, > there will be no better methods for avoiding spam. Authenticate mail is an abomination before God. I believe we will all rue that day that Qualcomm was able to cram RFC 2554 through the IETF. Let us pray that "ATRN" does not make it through committee. The real fix for this is not to add Rube Goldberg frobs onto every protocol in existance to provide for authentication for that particular protocol, but to go to IPv6 and enable TLS (there are TLS retrofits, such as SSL, for IPv4, as well, which allow for running an smtp daemon out of inetd.conf on an alternate port, using SSLeay to do the encapsulation; this is how SSL LDAP is normally configured). If you must implement a technical soloution, the following is the best I have seen so far: What is really needed in terms of identifying SPAM'mers is the concepts of the RBL, combined with a ceertificate server that is willing to sign time-limited certificates, which act as "licenses" to send email. A "caller ID" for email. This soloution, unlike the Qualcomm "SMTP AUTH+ATRN" soloution, is capable of being implemented incrementally, and transparently for servers which need to communicate with older email clients. If the server answers the phone with a "250-ESMTP" followed by a list of extensions which includes "250-CALLID", the client is expected to present its certificate. If it doesn't, the server contacts the certificate server and asks "would you sign the certificate for this machine, were it to ask you to sign one?". If the answer is "yes", then the transaction proceeds as if a valid certificate had been presented. If the answer is "no", then the caller is identified as a SPAM'mer. This also alleviates the problem of RICO Statute violations based on Blacklisting (the RBL is incorporated as an LLP for a reason), since the server operator can decide which list of certificate servers to respect, and this list can include servers run by SPAM "providers" for people who want to get their email. I also think that the dialup list is a very bad idea. The intent of this list is to blacklist the entirety of the existing shared IPv4 address space. The fix for this is, again, IPv6. Another obvious problem with the dialup list is that it shifts, successfully, the responsibility for the content coming from an ISPs customer to the ISP. ISPs already have a hard enough time in not being granted common carrier status. An ISP will enforce aUP based on a notification, and using the DUL as a club to threaten ISPs with violence is not the correct way to go. We have seen in Australia what the loss of common carrier status for ISPs results in: the ability to impose state-enforced content censorship at the dorrs of "those responsible", i.e. the ISPs. I, for one, dilike the idea of putting a single control knob in the hands of even the US government, let alone governments I don't trust, and which are less inclined to agree to the concept of personal liberty. If such a knob exists, such governments will use it, as the Australia censorship situation has amply demonstrated. The blacklist of dialup will soon have to expand, and in fact it will have to blacklist any host IP configured via a stateless autoconfiguration mechanism. This is acceptable for IPv4, since link.local is defined to be non-routable; however, in IPv6, stateless autoconfiguration results in a routable address. THIS WAS AN INTENDED IPv6 DESIGN GOAL. Given the availability of a technology that doesn't require an MIS staff to ride herd on one or more aspects of machine configuration, I can't possibly believe that the techology will not find wide deployment. The idea that someone using what amounts to an anonymous space for autoconfiguration (whether it be via link.local, IPv6 stateless autoconfiguration, or ...dialup IP address assignment) should not be permitted to send email is fundamentally flawed. Once again, the CALLID extension would resolve this, by using the certificate, not the IP address, to identify the user as a non-SPAM'mer. Overreacting, and making it so that dialup servers can not send email does no one any good, and bringing almost every system on the planet into that fold when IPv6 is widely deployed is, well, there's no kind way to say it: moronic. Complicating an otherwise simple protocol with SASL based authentication is, likewise, moronic. 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?199909242140.OAA26254>