Date: Fri, 24 Sep 1999 17:34:22 -0600 From: Brett Glass <brett@lariat.org> To: Terry Lambert <tlambert@primenet.com> 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: <4.2.0.58.19990924172733.047be8c0@localhost> In-Reply-To: <199909242140.OAA26254@usr05.primenet.com> References: <4.2.0.58.19990924144336.04490ba0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry: In your message below, you express disapproval of both the DUL and authentication. Unfortunately, the solution you DO propose does not appear to solve the problem of hit-and-run attacks from throwaway dial-up accounts (for which the ISP would need to provide certificates -- or use its own and risk having it voided if someone sent spam). Many other questions arise, too, including: What authority issues the certificates? What if one is stolen? A legitimate user whose certificate is stolen could lose vital mail. People don't take the time to sign PGP keys now. Will they be willing to go through the hassle of signing e-mail certificates? For us, the DUL seems to work quite well; I, for one, have never lost a legitimate e-mail because of it. And I watch the logs. --Brett At 09:40 PM 9/24/99 +0000, Terry Lambert wrote: > > 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 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?4.2.0.58.19990924172733.047be8c0>