Re: [Asrg] Re: draft-hall-inline-dsn-01

On 2007-01-29 16:35:02 -0600, David Nicol wrote:

On 1/28/07, Peter J. Holzer <hjp-asrg(_at_)hjp(_dot_)at> wrote:

On 2007-01-28 21:24:33 +0100, Frank Ellermann wrote:

Peter J. Holzer wrote:

David Nicol's DATAFIRST proposal.

[...]


I'm not interested in DATAFIRST. I'm interested in returning
per-recipient results to DATA.


they aren't mutually exclusive.


I didn't say they were. DATAFIRST includes the ability to return
per-recipient results to DATA. That's what I like about it.
Unfortunately it also removes the ability to return per-recipient
results before getting DATA, which I don't like.

So I prefer Eric's proposal, although it is admittedly more complex.

What I didn't like in draft-hall-inline-dsn was the sequence of
per recipient responses after DATA matching the sequence of RCPT
before DATA.


That's what the proposal is about. It allows several return codes for
DATA. The exact mechanism might be different (for example, there could
be a multiline-response instead of multiple single-line responses, or
the return codes can be matched by address instead of order), but these
are minor changes.


the one request, one response model is crucial to SMTP servers -- you
can write a smtp server that essentially does

     smtp_connect;
     while (accept and fork){
          send_smtp("EHLO blah blah blah");
          send_smtp(craft_smtp_response(receive_smtp())) while 1;
     };


I think you mixed server and client a bit, here.

and multiple response lines makes that no longer work; or means that
the receive_smtp() has to have a lot more data in it than if we are reading
a data block or not.


Yep, it gets more complicated. The server's implementation of the data
command has to be able to send intermediate reply codes (I think that's
how I would implement it in qpsmpd - simply write out the replies for
each recipient and return DONE instead of OK/DENY/whatever from the
data_post hook; the final reply would then be returned from the queue
hook as normal).

The client OTOH has to remember how many reply codes it is expecting and
match them up with the recipients.

so if the ordering is important, maintain it; how about a big response that
is a well-defined XML block?


I'm not sure I would want to introduce the complexities of XML into
SMTP. When I suggested a single multi-line response earlier in this
thread I was more thinking about nesting SMTP responses like this:

250-Message accepted by some recipients. Individual replies follow:
250-250 <user1(_at_)example(_dot_)com> accepted message.
250-550-<user2(_at_)example(_dot_)com> rejected message.
250-550 see http://www.example.com/mail-policy/ for details.
250 250 <user3(_at_)example(_dot_)com accepted message.

which would be equivalent to

353 Message accepted by some recipients. Individual replies follow:
250 <user1(_at_)example(_dot_)com> accepted message.
550-<user2(_at_)example(_dot_)com> rejected message.
550 see http://www.example.com/mail-policy/ for details.
250 <user3(_at_)example(_dot_)com accepted message.
250 Message queued.

in Eric's draft.

        hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Sam in "Freefall"

signature.asc
Description: Digital signature

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg