Thanks for the feedback John.
I agree 100% with each of your points, most notably having a "SUBJ" precede
the other commands to pre-empt further unnecessary overhead. About
internationalization. Admittingly, I have to study this more. We are
getting hit hard from some international customers about this in our Web
Mail client and just got a reminder the other day.
The only comment I have is that we might lost tracing and auditing if it
precedes the commands. If implemented, an system admin may wish to log
the rejected transactions by atleast FROM and SUBJ, and quite maybe RCPT.
We learned from our CBV work that it works best to delay the MAIL FROM
validation until the RCPT is provided. If RCPT is going to refused, there
is no need to perform the CBV. This was an overwhelming major improvement
since atleast 60-70% recipients attempts on our site are rejected. In any
case, I agree. SUBJ should probably precede the other commands and
implementations can chose when to validate it.
Incidently, this delayed MAIL FROM validation concept is suggested in
'2821'. The same can written about SUBJ.
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>;
Sent: Monday, January 26, 2004 7:17 PM
Subject: "Subject" in the envelope (was: Re: Comments requested on
I just wanted to comment on one aspect of your proposal
--On Sunday, 25 January, 2004 06:40 -0500 Hector Santos
is too restrictive to a particular need where the same result
can be achieved with a simple SUBJECT line. The SUBJECT
line idea can address this and many other neat concepts such
as overhead reducing mail driven events. For example,
subcribing to a mail list:
MAIL FROM: <jsmoe(_at_)example(_dot_)com>
RCPT TO: listadmin-somelist(_at_)whereever(_dot_)com
The feature and product benefits offered by a SUBJECT line
design change is much greater and wider than this specific
EHLO/MAIL FROM design change which targets only one concept.
If one really wanted to do this, and I'm not yet convinced,...
(1) You need to work out a number of details, preferably in the
form of an Internet-Draft, if you expect this to go anywhere.
For example, Subject lines can get pretty long, and there is no
equivalent to 822 continuation lines in SMTP sender dialogues.
Some of the internationalization issues also raise coding
questions, and it isn't clear to me that the right answers for
2822 would be the right answers for the envelope.
(2) You will find that it is easier to establish
interoperability with a wider range of SMTP servers if you
confine the verb to four characters, e.g., SUBJ and not SUBJECT
(3) I would think that you would want SUBJECT to precede RCPT
and possibly MAIL, not follow them. If you are trying to
conserve resources, it would be good to not need to validate
RCPT commands (or give the sender a clue about what is and is
not valid), and probably not even apply whatever testing is done
to the return path, if you are going to reject the transmission
on the content of a subject command.