[Asrg] ACK4

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 <scott@spamwolf.com>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg