From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19164 invoked by alias); 18 Nov 2005 01:47:08 -0000 Received: (qmail 19153 invoked by uid 22791); 18 Nov 2005 01:47:02 -0000 Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO duck.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 01:47:02 +0000 Received: from [127.0.0.1] (duck.corp.specifix.com [192.168.1.1]) by duck.specifix.com (Postfix) with ESMTP id 5D3E84166 for ; Thu, 17 Nov 2005 17:47:01 -0800 (PST) Subject: strange bounces From: James E Wilson To: overseers@sourceware.org Content-Type: text/plain Message-Id: <1132278418.9250.66.camel@aretha.corp.specifix.com> Mime-Version: 1.0 Date: Fri, 18 Nov 2005 02:05:00 -0000 Content-Transfer-Encoding: 7bit Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00218.txt.bz2 Since no one seems to know what the problem is, I tried looking for info, and found an interesting thread on the nntp.perl.org server in the perl.qsmtpd mailing list, with the subject line "Strange bounce problem" sent on Nov 4, 2004. Since there is no convenient URL, I've quoted the interesting parts of the most interesting message: I don't know if this might help, but I just spent hours with ethereal and full debugging on all the servers and here is what is happening: telnet server 25 220 server ESMTP qpsmtpd 0.28 ready; send us your mail, but not your spam. 503 MAIL before RCPT 503 MAIL FIRST Now, looking at the tcpdumps reveals that you in fact never sent anything, however, if you look at the logs you see that the server was dispatching something like : RCTP TO: , back to ethereal and you can see that sure enough a server sent that packet a good 10-15 seconds ago but was denied with the require_resolvable_fromhost. What seems like is happening is that Qpsmtpd is dropping the connection but the buffers aren't being flushed so that when the next Qpsmtpd picks up the file handle the old one had it's getting the data that was left over. I am running Pperl with --no-cleanup but enabling cleanup did nothing to solve the problem as did just calling qpsmtpd directly from tcpserver without pperl. The only thing I have found that got rid of the problem was to edit the require_resolvable_fromhost plugin and change it from DENYHARD to DENYSOFT. Hope this helps somebody out there. Ed McLain End quote. There are also some other related suggestions in other messages in the thread, but this one seemed like the most useful. You might want to look at the entire thread. -- Jim Wilson, GNU Tools Support, http://www.specifix.com