ietf-smtp
[Top] [All Lists]

Re: another per-recipient data reply proposal

2007-02-06 10:53:06


On 2/5/2007 10:52 PM, Claus Assmann wrote:

  begin_inspection {
     if global_inspection == 1 {
        if global_return == 1 {
           print 550;
           exit;
        }

        ; tell the client we are starting per-recipient filters

        print 353;

     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?

I didn't run it through lint, sorry

It misses the "first response after end of data" (353) before the
"foreach" part...  or was this code supposed to implement some other
model?

That was supposed to follow the comment line that I've reinserted

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.

Section 6.2 says the following:

|     If the message is accepted or refused by every recipient, the 353
|     response code and the subsequent responses MAY be substituted with
|     a single response code which reflects the global outcome.

although that could probably be clarified. I think the particulars would
be up to the implementation. Here are some scenarios:

1) MTA implements some kind of global filtering such as virus scanning,
and issues 550 instead of per-recipient codes.

2) MTA knows that some recipients are exempt from filtering (eg, abuse@
needs to get viruses, in case spewing users are being reported), and if
the MTA knows that all of the recipients are in the safe-list then return
a 250.

3) MTA temporarily stores individual recipient response codes in array and
compresses them into a single response (assuming that a timer does not
expire first).

There are other possibilities here, but I don't want to argue about what I
consider implementation details. The point is that it is optional, and to
the extent that it is optional then implementations can do what they like
to use it or not. I can improve the wording if you think it's too vague.

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.

I thought we had eliminated deferred RCPT so that only the 25x recipients
were processed. If an implementation wants to manage some of those
differently (such as with checking the all-mail list if it's available)
then that's up to the implementation.


-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/