ietf-asrg
[Top] [All Lists]

Re: LMTP-style ESMTP extension (was: [Asrg] pre-rfc thought balloon: ESMTP DATAFIRST)

2006-06-07 15:13:16

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:

EHLO example.com
250-mail.example.org, please to meet you
250-EXTENDEDDATA
250 HELP
MAIL FROM:<user(_at_)example(_dot_)com>
250 <user(_at_)example(_dot_)com> sender ok
RCPT TO:<you(_at_)example(_dot_)org>
250 <you(_at_)example(_dot_)org> recipient ok
RCPT TO:<webmaster(_at_)example(_dot_)org>
250 <webmaster(_at_)example(_dot_)org> recipient ok
DATA RCPTSTATUS PART=HEAD
354 Enter email HEAD part and end with '.' line
From: user(_at_)example(_dot_)com
To: you(_at_)example(_dot_)org
Cc: webmaster(_at_)example(_dot_)org
.
350-<you(_at_)example(_dot_)org> unable to deliver at this time, queue not 
available
250 <wembaster(_at_)example(_dot_)org> message part accepted, please send the 
rest
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
QUIT

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.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

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

<Prev in Thread] Current Thread [Next in Thread>