On Mon, Feb 05, 2007, Eric A. Hall wrote:
[first response after end of data]
It provides a start point for the client's response timer, thereby
preventing the client from timing out sooner than it should.
The client starts its timer after the last I/O operation it did.
Whether the next input is the "first response after end of data"
or the first RCPT reply doesn't matter as long as you properly
specify the maximum timeouts.
I'd like to know what is difficult about the 353 response. If part of it
is too difficult for the value it provides we can look at stripping out
those parts of it. Some pseudo-code as I see it:
begin_inspection {
if global_inspection == 1 {
if global_return == 1 {
print 550;
exit;
}
foreach $recipient {
if recipient_return == 1 {
print 550;
} else {
print 250;
}
print 250;
}
[I removed the comments and empty lines...]
Does your pseudo code look correct to you?
It misses the "first response after end of data" (353) before the
"foreach" part... or was this code supposed to implement some other
model?
Moreover, it misses some optimizations (unless I misunderstood
your draft):
1. if all RCPTs return 250: send 250
2. if all RCPTs return 550: send 550
3. otherwise: send 353
and then the individual RCPT replies
and then 250.
As I wrote before: it would be really nice to get some feedback
from people who are familiar with MTAs to comment about the (code)
complexity etc.
PS: there are more complexities caused by your proposal, e.g.,
foreach $recipient
isn't as simple as it looks: you need a list of "ok" and "deferred"
RCPTs and for the latter you need "new status code" too. For the
LMTP model it's much simpler: the MTA keeps only the "ok" RCPTs (as
it has to do anyway) and it can override those values after the
data phase (as all of them were "ok", no need to distinguish between
"ok" and "deferred"). This is just one example of the "subtle"
problems introduced into existing code by the more complex proposal.