From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 01:44:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67E729EC for ; Mon, 22 Jul 2013 01:44:15 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 491351C20 for ; Mon, 22 Jul 2013 01:44:14 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id EA60E3B604 for ; Sun, 21 Jul 2013 18:44:05 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: <20130721041338.2121.qmail@f5-external.bushwire.net> Date: Sun, 21 Jul 2013 18:44:05 -0700 Message-ID: <91904.1374457445@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:44:15 -0000 In message <20130721041338.2121.qmail@f5-external.bushwire.net>, "Mark Delany" wrote: >> servers running certain protocols. For example, the rules of the SMTP >> protocol... just to name one... require that a client wait until the >> server has sent out an initial greeting banner before the client sends >> anything to the server. Some SMTP servers are lenient about enforcing >> this protocol rule, so in practice it may often not be necessary to wait > >A while back "fast talkers" as they were called, were a known >signature of some spam bots. That is correct. >The guess is that they would just write >the whole SMTP transaction in one write() immediately following the >connect() and be done with it. Yes. >A useful optimization when you're >blatting out billions of spam. I suppose so. >You don't see a big mention of this in search engines, so I don't know >how prevalent they are now. > >Point being that such an option might be useful to avoid triggering >any detectors that might still be looking for this. I'm sorry, but I am not following you. Were you attempting to say that this would be a good thing or a bad thing? (Personally, don't think it matters much one way or the other. Blocking "fast talkers" was never a terribly effective anti-spam technique. It was just "security through protocol pendantry", and was/is quite entirely trivial for the spammers to work around.) Regards, rfg