Subject: [EAI] RFC 4409 Message Submission

From: [email-masked]
Date: Fri, 28 Apr 2006 11:53:11 +0900 (JST)

MUA uses Submission protocol to send mail to its first MTA.
So, RFC 2476 also needs to be updated with smtpext.

This is written in framework ID without reference to RFC 2476.

Does 'smtpext' document need to describe Submission ?

Does 'downgrade' document need to describe Submission ?

--
Kazunori Fujiwara, JPRS

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Apr 2006 08:24:06 -0400

> So, RFC 2476 also needs to be updated with smtpext.

RFC 2476 was replaced by RFC 4409, a Draft Standard.  Having
just gotten 4409 finished after many delays, I suspect that the
authors of that document would be reluctant to open it again,
especially with a change that would return it to Proposed (I
can't speak for the main author, but...).  So we need to think
about either a stand-alone document that updates 2476 or of
attaching some changes to 2476 to some other document.   We
could even break that in two: (i) a comment about submission
with the i18n extension turned on (which really does not require
a modification to 4409, just a note in the smtpext document --
see below).  (ii) A discussion of downgrading, and possibly even
upgrading, at the submission point, a topic that was discussed
briefly in Dallas.   Volunteers?

> This is written in framework ID without reference to RFC 2476.

Yes, and that should be corrected.  I'll try to put some draft
text into a possible revision of that document.

> Does 'smtpext' document need to describe Submission ?

Either it or some other document.  If it doesn't describe
Submission, it should probably explicitly note that it does not
and point to whatever document does.  In either case, it should
(I believe must) note that the extension can be used with
Message Submission (see section 7 of RFC 4409).

> Does 'downgrade' document need to describe Submission ?

Something needs to describe Submission-time downgrading (and
maybe upgrading, again following the Dallas discussions).  Again
based on Dallas discussions, I think we need to clearly separate

	(i) Downgrading and maybe upgrading at submission time
	
	(ii) Downgrading during SMTP transport/ relaying
	
	(iii) Downgrading and maybe upgrading after final
	delivery.

For the first, which is what is at issue here, it seems to me
that we might want to discuss the issues without specifying
particular behavior.  If that is the case, the discussion could
be placed in the framework document (to avoid yet more
documents), but suggested text would be appreciated.  If, on the
other hand, there is specific behavior to be specified, the text
should go either into the downgrade document or yet another
additional document.

A question that might clarify whether we want to specify
behavior or not: At present, a 4409 server would be expected to
reject a message that contained UTF-8 headers on the principle
that one of the jobs of a message submission server is to be
forward only SMTP-valid messages into the SMTP environment (see
the last paragraph of  Section 8, which, in retrospect, might
have been a little more carefully written with regard to this
extension).  Would we like to give explicit permission for a
4409 server to do an explicit UTF-8 check and, if UTF-8 is
found, invoke the extension, add extra headers as needed, etc.?
Since that check is still heuristic and since, even with the
extension, UTF-8 in some header locations would still violate
RFC 2822, don't answer without thinking about it first -- my
first reaction was "of course", but I'm no longer sure.

     john