Subject: [Asrg] ACK4

From: Scott Nelson <[email-masked]>
Date: Wed, 21 May 2003 11:01:18 -0700

At 10:25 AM 5/21/03 +0100, Jon Kyme wrote:
>
>>The biggest practical problems I can think of for per-user filters
>>using the milter mechanism are that sendmail wants to do things
>>with the UID "daemon" or equivalent and that the SMTP protocol
>>doesn't let the SMTP server answer the DATA command with "250-ok
>>for Rcpt #1, 550-spam for Rcpt #2, and 450-try-later for Rcpt #3."
>>
>
>
>Personally, I think the easiest solution to this problem is to modify the
>semantics of 250 after DATA such that in the case of a message with
>multiple RCPT TO we shouldn't *require* that a notification be generated
>for a "delivery failure" if this "failure" is an action requested by a
>mailbox "owner".
>
>Such a change would effectively give different QOS to the two classes of
>messages.
>
>If a sender needs the higher QOS then it needs to stick to one RCPT TO per
>message, a sender that doesn't need it (or doesn't care) can
>bundle them.
>
>

If you're going to change SMTP,
I think it's better to create a new commands rather than modify old ones.
In this case, I'd suggest two new commands.
A "DATA4" which works like DATA and an ACK4 which doesn't
work like anything currently.

The only real difference between DATA and DATA4 is that after 
the message is sent, a separate ACK4 for each recipient is generated.
(I'm tempted to add a message size, like DATA4 n_bytes, but because
 of end of line madness that's not always easy to measure.)

ACK4 is essentially a repeat of the RCPT TO at the beginning of the
transaction, but now the receiver has the message and (presumably)
already knows what policy to enforce for it.  For example, if
one mailbox has a quota of 2 Megabytes, then messages over that
size can now be rejected in the SMTP stage.

Some advantages;
No need to negotiate if the sender understands the acks,
if they send DATA4/ACK4 they do, if not, they don't.

Extra handshake reduces time during the race condition
and reduces the subsequent danger of duplicate messages.

Some disadvantages;
Only useful if both sender and receiver have implemented it.
Till then it's just dead code/wasted text in the specification.

6 more bytes in every EHLO transaction.

Yet another RFC.

Scott Nelson <[email-masked]>
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 21 May 2003 13:15:46 -0600 (MDT)

> From: Scott Nelson <[email-masked]>

> ...
> ...

> If you're going to change SMTP,

When I first read Mr. Kyme's message, I ground my teeth at what I
thought was yet another worse than useless proposal to change SMTP
and then wait 15 or 20 years until the changes might or might not be
widely deployed and possibly start to have some effect, possibly but
probably not the intended effects.  Then I re-read it and realized
that it is not a proposal to change SMTP as SMTP is actually implemented,
installed, and used.  It instead would merely sanctify a well understood
mode that is already common in real life.  For example, that proposal
is the tactic I chose to deal with the protocol problem in the DCC clients.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 20:19:46 +0100

> I think it's better to create a new commands rather than modify old ones.

No, I don't believe so. A change such as I suggested is backward compatible
and works right away. I think. I'm not particularly attached to the idea.

> Till then it's just dead code/wasted text in the specification.

You've raised the killer objection to your own idea.

--

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 20:43:36 +0100

>> >Personally, I think the easiest solution to this problem is to modify
>
>When I first read Mr. Kyme's message, I ground my teeth 

Look after your teeth Mr. Schryver, unless you're very young
or very unusual they'll have to last you out.

>It instead would merely sanctify a well understood
>mode that is already common in real life.  

"merely sanctify"?  How about "document"?
But hey, well-spotted.