I have twenty years experience with a messaging protocol that deals well with
these situations. The protocol was designed for very slow, expensive, and very
unreliable links, and deals with hundreds of recipients per message, each of
which can be accepted or rejected individually based on message content and
policy.... DSN equivalents are very expensive in it's operating environment.
The protocol sends recipients envelope until a sucesful recipient is accepted,
then the message contents, and then a series of additional envelopes that
essentially say "copy the message to this recipient also".
This good operational experience suggests to me an extension to SMTP, a new
verb to follow the data command. Lets call it ALSO TO.
The advantage of a single sucessful recipient first ensures that the
transmission is done for at least one likely recipient. You could extend the
DATA response code to cover additional non-envelope failure reasons, but a
failure for most cases, and all policy cases after DATA would not preclude ALSO
TO additional recipients.
So an interesting flow would be as follows:
Mail FROM Greg(_at_)me(_dot_)com
200 OK
RCPT To Beth(_at_)example(_dot_)com
500 on leave of absensce.
RCPT TO Joe(_at_)example(_dot_)com
200 OK
DATA
500 Joes does not do fax messages
ALSO TO Sam(_at_)example(_dot_)com
200 OK
ALSO To sue(_at_)example(_dot_)com
500 Nope. Too racy
Also to jack(_at_)example(_dot_)com
500 Nope. Don't like big messages
Quit.
Greg V.
-----Original Message-----
From: Claus Assmann [mailto:ietf-smtp(_at_)esmtp(_dot_)org]
Sent: Saturday, March 27, 2004 10:46 PM
To: ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
Subject: Re: deferred RCPT responses
On Sat, Mar 27, 2004, Eric A. Hall wrote:
So... there's no way to say "I'll accept the message for this user, but
not for that user" after the envelope loop has completed.
It seems you want LMTP, at least its RCPT replies after the final dot.
Someone should specify this as an ESMTP extension...