From owner-freebsd-current Wed Jun 12 23:30: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 61F4C37B411 for ; Wed, 12 Jun 2002 23:29:58 -0700 (PDT) Received: from pool0150.cvx22-bradley.dialup.earthlink.net ([209.179.198.150] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17IO7G-0004n1-00; Wed, 12 Jun 2002 23:29:55 -0700 Message-ID: <3D083BB9.E74021F0@mindspring.com> Date: Wed, 12 Jun 2002 23:29:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Taylor , freebsd-current@freebsd.org Subject: Re: looking for warn quota tools References: <5.1.0.14.0.20020611152151.00acbb30@pop.oanet.com> <3D0677C2.ED706536@mindspring.com> <20020613004244.GA89486@gattaca.yadt.co.uk> <3D0838FB.13B6DA3E@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > For this to work, you would have to serialize access to maildrops > by receiver SMTPs (this is an intractable problem), AND you would > need to reject mail sent without the "SIZE" extension, or mail > whose actual size exceeded that specified by the "SIZE" extension > (you are not permitted to do this last, since the "SIZE" extension > is defined, by standard, to be advisory, not regulatory). This is > on top of the other coupling requirements. To elaborate a little on why this is bad, consider the delivery of a message to (A,B,C) that lock maildrops, but occurs concurrently with another deliver to (C,H,I,J,K,L,M,N,O,P,A). Thus, a deadlock may occur during the locking stage. The problem with this is that for each "RCPT TO:" line, you must respond with a success/failure notification to the peer SMTP server, so if you depend upon the locking occurring, then the only method you have of rejecting in the case noted above is to fail the DATA request, since the "MAIL FROM:" and one or more "RCPT TO:" have already been accepted. Thus the very design of the protocol is antithetical to the locking of maildrops to provide the enforcement which you seek. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message