On 2/4/2007 10:50 PM, Claus Assmann wrote:
On Sun, Feb 04, 2007, Eric A. Hall wrote:
See the discussion on reliability timers earlier--a start code is going to
be important. Also see the last post by me in re global filters--this is
Your draft requires a first response after 1 minute and then each
RCPT command within 10 minutes. I don't see why that first response
is important wrt timeouts, but I'll look at that discussion again.
It provides a start point for the client's response timer, thereby
preventing the client from timing out sooner than it should.
the right place to issue such a response. Frank's is also correct that
there is some efficiency and reliability if we can avoid enumerating long
lists of response codes. For all those reasons I'd like to ask you to try
using it and see if it's not too hard.
I understand that your proposal is the most complete and offers all
kind of optimizations. As a consequence of that it also the most
complex and hence most complicated to implement. As I wrote before:
that may prevent other MTA authors from implementing it and it may
introduce implementation errors. Remember: it is _S_imple Mail
Transport Protocol :-)
protocols should be as simple as possible, but no simpler :)
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 {
; are global filters enabled?
if global_inspection == 1 {
; check for viruses, etc
if global_return == 1 {
; found a problem
print 550;
exit;
}
; tell the client we are starting per-recipient filters
foreach $recipient {
; check the content against recipient rules
if recipient_return == 1 {
; found a problem
print 550;
} else {
; no problem
print 250;
}
; accept responsibility for the message
print 250;
}
That doesn't include the timers or the detailed operations of course. Are
the timers the problem? Is the process too hard to integrate with existing
functions and operations?
I'm all for simplicity here but there is so much value provided by the
head-of-list response code that I really feel that it needs to be kept.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/