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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
