On Wed, 7 Jun 2006, Tony Finch wrote:
"william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:
I'm not a fan of what you proposed with separate keyword just to
check status. I'd much rather have this as separate DATA commands
if done at all.
That doesn't work because there isn't an extension mechanism for
adding parameters to the DATA command, so it means your extension
must duplicate all the other DATA-like commands, i.e. DATA, BDAT,
BURL, and you must revise your spec whenever a new DATA-like
command is introduced. This is not a good long-term strategy.
We're only talking about SMTP (as in multi-network email transport),
not LMTP which has different set of commands for data and already has
ways to deal with this. As I noted I personally feel that DATA command
needs to be extended for SMTP use like it was done for other protocols
derived from SMTP.
BTW, that reminded me (including of the conversation just a few months
ago) that I do see a need to add parameters to new DATA command, in fact
in the way I saw it the first such parameter would be what data it is
(i.e. header of body part).
I also have to note that nothing really prevents us from actually adding
parameters to DATA command and extending it this way (well maybe except
RFC ABNF, but we know how that worked from RFC821 to 2821) within context
of SMTP extension framework. You could say that if server advertises in
EHLO certain extension (like say "EXTENDEDDATA'), it means it the server
understands extended DATA syntax and client could choose to do:
250-mail.example.org, please to meet you
250 <user(_at_)example(_dot_)com> sender ok
250 <you(_at_)example(_dot_)org> recipient ok
250 <webmaster(_at_)example(_dot_)org> recipient ok
DATA RCPTSTATUS PART=HEAD
354 Enter email HEAD part and end with '.' line
350-<you(_at_)example(_dot_)org> unable to deliver at this time, queue not
250 <wembaster(_at_)example(_dot_)org> message part accepted, please send the
DATA RCTPSTATUS PART=BODY ENDDATA
354 Enter email BODY part and end with '.' line
Hi There, you seem to have a broken link on your homepage.
250 <webmaster(_at_)example(_dot_)org> message accepted for delivery
But I also quite easily see that maybe new command (EDATA) would be better
to make it clear that its basically an extended command (like we did when
moving from HELO to EHLO).
Your suggestion of a STATUS parameter on the RCPT command is not
bad, but the problem is that the client doesn't know which recipients
have differing content-filter options, so it doesn't know which RCPT
commands do or do not require the parameter.
Some smtp clients may have means of finding which users have different
'content-filter options', plus I see use and non-use of STATUS for RCTP
in this case as being based on recipient domains (i.e. if you send it
to secondary or to primary mx for a domain and other parameters), but
I'd suspect that most who want this will just add STATUS to all RCTP
commands - its not a big deal or a problem.
Asrg mailing list