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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message