Subject: Re: Last Call: 'Message Submission' to Draft Standard

From: Bruce Lilly <[email-masked]>
Date: Fri, 11 Feb 2005 20:48:15 -0500

>  Date: 2005-02-10 19:09
>  From: Randall Gellens <[email-masked]>
  
> At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:

> >  There are some differences between what the draft says and that
> >  description:
> >  1. the draft explicitly permits operation on port 25
> >  2. the draft section 4.3 doesn't mention port.
> >
> >  Specifically regarding the 4.3 MUST quoted above and the reply code,
> >  and the necessary two independent implementations required for
> >  advancement to Draft Standard status, do the implementations supporting
> >  the request to advance to Draft in fact unconditionally require
> >  authorization (i.e. independent of whether port 25 or 587 is used, and
> >  regardless of administrative configuration other than specifying that the
> >  implementation is to act as an MSA), and reply with code 530 (unspecified
> >  extended response code) if authorization is lacking?
> 
> Both the draft and RFC 2476 allow submission to use 25 instead of 
> 587, but state that "normally" 587 is used, and allow 25 to be used 
> in order to accommodate implementations that are hard to configure. 
> Both say that port 587 is reserved for submission.  So, 587 is the 
> normal case for submission, and 25 is an exceptional case.

But as written, section 4.3 specifies that when acting as an MSA,
authentication MUST (emphasis in original) be used, regardless of
port.

> Please see the implementation report for the details, but I believe 
> most implementations had various configuration options that allowed 
> them to require authentication or not.

Again, "or not" is not allowed by the draft as written; implementations
with an "or not" provision would fail to comply with the "MUST" (they
would comply with a "SHOULD", however).

Aside: based on my understanding of the implementation report, there
are no two implementations which simultaneously comply with all of
the draft (or 2476) provisions, failing the "two independent
implementations" test for advancement to Draft Standard status.

> >  On another matter, admittedly unchanged since RFC 2476, there seem to
> >  be some undesirable discrepancies between submission and non-submission
> >  ESMTP regarding extended response codes.  Draft section 3.4 states that
> >  extended status code 5.6.2 means "Bad domain or address", whereas
> >  RFC 3463 assigns that code the semantics "Conversion required and
> >  prohibited" [RFC 3463 section 3.7].  The corresponding RFC 3463
> >  extended response code for domain/address issues would be in the
> >  5.1.XXX range [RFC 3463 section 3.2].  The draft specifies (sect. 5.1) use
> >  of 5.6.2 with 554 for message header field address issues when an error
> >  is reported after DATA.  SMTP (RFC 2821) does not require examination
> >  of message header address field content except in the particular case
> >  of a gateway [RFC 2821 section 3.8].  If the intent is that MSAs are
> >  always to be considered to be gateways, then the draft should explicitly
> >  say so (the term "gateway" does not appear anywhere in the draft).
> >  [that would be a novel use of the term "gateway" in Internet mail; a
> >  gateway usually has one side in a non-SMTP environment]
> >  Conversely, if MSAs are not always to be considered as gateways, then
> >  returning errors in response to message content is:
> >  1. explicitly counter to the SHOULD NOT of RFC 2821 section 3.4 (bottom of
> >     page 18)
> >  2. inappropriately associated with "conversion" semantics where no
> >     conversion is in fact required (indeed, other than adding trace fields,
> >     tinkering with message data by non-gateway SMTP receivers is disallowed
> >     [RFC 2821 section 2.3.8]).
> 
> It is not the intent of either this draft or RFC 2476 to say that 
> MSAs are always gateways; rather, the intent in both is to recognize 
> the reality that organizations sometimes see a need to examine and 
> potentially modify messages submitted using their servers, and to 
> make a clear distinction between this case, and the 
> examination/modification of messages being relayed.

Well, there's an unresolved incompatibility with RFC 2821.

Following up on a disturbing sense of déja vu, I checked my records
and found the following commentary on RFC 2476 -- I believe that the
issues remain largely unaddressed by the draft:
---------------------
Date: Sat, 17 Apr 2004 22:54:44 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
X-Accept-Language: en-us
MIME-Version: 1.0
To: John C Klensin <[email-masked]>,
 [email-masked]
Subject: Comments on RFC 2476 (Submission protocol)
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain;
  charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UID: 407
X-Length: 3072

Hello,

First, the reason that I'm sending this directly rather than to ietf-submit is that
I'm not subscribed to that list and in a few hours I'll be on an airplane on a
business trip, and I may be incommunicado for a week or so.  By all means feel free
to forward my comments to the list and/or to Chris Newman (whom I see has made some
list contributions about a month ago; unfortunately the list archive on the IMC web
sit only displays "Chris Newman <Chris.Newman@xxxxxxx>" and the corresponding
mailto link is the useless "mailto:[email-masked]").

Following are my comments, in the order as presented in the RFC:

section 3.2, last NOTE:

Of course the MSA, in order to "properly handle delayed bounces" will have to be
able to accurately determine the source, which s probably only possible is some
authentication mechanism is used.

section 3.4 enhanced status codes:

This is the biggest problem that I see: the basis is RFC 1893 (superseded by RFC
3463) status codes, which specifically address only issues related to hard errors
in delivery.  For example, there is no standardized extended status code to address
the situation where an email address is not valid but a forwarding address is
available.  3463 does address the situation where such a forwarding address is NOT
available (5.1.6), but not the situation corresponding to SMTP response 251.
2.1.6 might be an appropriate extended status code, but RFC 3463 specifically
states that X.1.6 " is only useful for permanent failures", i.e. 5.1.6.

One might hope that some unified set of extended status codes might be developed
that could be used for multiple protocols.  Unfortunately, there seems to be an
inconsistency even within the mail protocols. RFC 2476 lists extended status code
5.6.2 as "Bad domain or address", whereas RFC 3463 (and 1893) list that code as
"Conversion required and prohibited". That is very confusing, since RFC 3463
provides a range of extended codes (x.1.0 through x.1.8) for address/domain
errors.

It is also notable that RFC 2476 (e.g. section 4.1) provides no extended status
codes for transient failures or for success; only class 5 -- permanent failure.

Another example of the extended status issue shows up in RFC 2476 section 5.1,
which again addresses only permanent failures, not temporary failures (e.g.
DNS transient failures). It also doesn't distinguish between syntax errors
and address semantic errors.

Best regards,
  Bruce Lilly
----------------------------------

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

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 11 Feb 2005 21:02:34 -0500

>  Date: 2005-02-11 12:55
>  From: "John Loughney" <[email-masked]>

> SMS's for some languages are indeed in unicode, often one message is sent in a multipart message - i.e. - in more than one message. Even in various Nordic languages that have strange things like ä, ö, å ... SMS's are sent in unicode.
> 
> Some cell phones sport pen input, but also support Asian text input via a stroke system via the normal digit keypad.

> From: "Harald Tveit Alvestrand" <[email-masked]>
> Time: 02/10/2005 10:21 pm
> 
> 
> 
> --On torsdag, februar 10, 2005 10:49:50 -0500 Bruce Lilly 
> <[email-masked]> wrote:
> 
> > 1. I have in mind a keyboard on a certain device which has
> >    support for protocols which use domain names (HTTP, SMTP/
> >    Internet Message Format, VPIM).  It has a keyboard which
> >    is at best inconvenient for entry of ASCII text. Unicode
> >    "text" (see below for an explanation of the scare quotes)
> >    is unthinkable.  That device is a cell phone.
> 
> Note that the SMS service is popular in Asia too - and there, the 
> characters sent are definitely not ASCII.
> 
> No, I have no idea how they type them - but they do.

While I do not dispute that some mobile devices might use some subset
of some version of Unicode for text in some languages, my point was,
in response to John Klensin's "Until and unless every one of us has a
keyboard that permits easy input of every Unicode character", that not
only do I not expect to have a keyboard permitting *easy* entry (no,
that doesn't mean "Grafiti" or "Decuma") of *every* Unicode character
any time soon, I don't expect it *ever*, because the Unicode code space
is expanding (in contradiction to the original Unicode Design Principles)
faster than the available memory space on low-power, compact, mobile
devices.

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Feb 2005 09:00:09 -0500

--On Friday, 11 February, 2005 21:02 -0500 Bruce Lilly
<[email-masked]> wrote:

> While I do not dispute that some mobile devices might use some
> subset of some version of Unicode for text in some languages,
> my point was, in response to John Klensin's "Until and unless
> every one of us has a keyboard that permits easy input of
> every Unicode character", that not only do I not expect to
> have a keyboard permitting *easy* entry (no, that doesn't mean
> "Grafiti" or "Decuma") of *every* Unicode character any time
> soon, I don't expect it *ever*, because the Unicode code space
> is expanding (in contradiction to the original Unicode Design
> Principles) faster than the available memory space on
> low-power, compact, mobile devices.

Bruce (and others),

You can argue and pick at this interminably, but I think you are
missing the key point.

There is, IMO, an extremely strong argument for saying 

	"Look, DNS names, and DNs as used in X.509 certs, are
	ultimately protocol identifiers.  Safe and stable
	operation of the Internet requires that protocol
	identifiers be written in a small, restricted, generally
	recognized, and easily distinguishable, set of
	characters.  And everyone who has studied which
	characters to use when the principles of "protocol
	identifiers" and " statements are applied, including our
	very internationalization-conscious friends at the ITU,
	have concluded that the right characters are a subset of
	those in the Roman-based script family.  The subset seem
	to always be "without the embellishments of diacritical
	marks or other embellishments".  It is almost always
	defined in terms of case-independent matching rules or
	in terms of only a single case being permitted -- more
	often upper historically, although there are some
	substantive arguments for lower. "

The choice of Roman characters is ultimately based on the
observation that, while there are several _languages_ that are
more  widespread than English, nothing in the above says
anything about English.  Those Roman-based characters are, for
one reason or another, used, either as a primary or a secondary
script, by more languages and people than everything else in the
world put together.  That contributes significantly to
"recognizable", which is an important criterion.

And neither the "protocol parameter" argument, nor the argument
that more characters would lead to more opportunities for
confusion, did not come as a surprise to the IETF community
within the last week or two.  Both arguments were raised,
passionately and at great length, when the IDN effort was first
coming together.  They were raised on the IETF list, on more
than one WG list, in BOFs, etc.  

There is a second argument that can be made with equal strength.
People like to write their names correctly.  Inability to do
that is a profound source of irritation (at least) and was
important enough, even in the 60s, to influence the way
characters are handled in important operating systems to this
day.  More generally, people prefer that the identifiers they
pick have mnemonic value to them, and that means the ability to
pick those identifiers based on their languages and scripts.
Please note that argument applies at the geek interface level;
we don't need to get up to the user interface one to make it.
When we do get to the user interface and start worrying about
non-expert would-be users of the Internet, we immediately
encounter some very passionate, and almost certainly correct,
arguments that users should be able to deal with, and navigate,
the Internet and do so completely in their own languages and
scripts.  

The problems with that argument, including opportunities for
deliberate or accidental confusion among similar-looking
characters, also come as no surprise to the IETF.  Like the
"protocol parameter" position, they were discussed openly and at
great length, with examples, many years ago.

With both of those arguments in hand, and with the problems with
each at least moderately well understood, the IETF (or at least
everyone who could be persuaded to pay attention) made a
decision.  That decision was made years ago and under
considerable marketplace pressure, that, for the particular set
of issue areas that included DNS names, the second set of
arguments -- that accessibility in "native scripts" (and Unicode
in particular) were more important than the "protocol
identifier" argument-- were the dominant ones and that we needed
to do this.   By implication at least, we decided that we would
need to accept and understand the problems that decision caused
and deal with them.

There were another group of questions, which are the more
complicated piece of the issue.  The obvious way to get the
right functionality is not necessarily the best one.  There is a
nasty tradeoff between techniques that can, at least in theory,
be deployed quickly and ones that are likely to take longer but
might be more satisfactory in the long term.   There is another
nasty tradeoff between making something work well for the people
who know that they need it and are willing to make an investment
in conversion and upgrading of systems to get it versus making
it work reasonably well (and perhaps more quickly) for everyone.

Again, the IETF made decisions on those points.  My personal
view is that some of those decisions were not especially
well-informed and may even have been wrong, but they were
decisions made in the community and made after the dissenting
views were strongly expressed.

So, today, we've got IDNs and IDNA.   Even if one believes that
the _only_ reason for standardizing them is to provide a common,
interoperable, way of doing something that people will clearly
do somehow, the standards seem justified.  (For the record, I do
not subscribe to the "that is the only reason for a standard"
position in this case.)   I see no way to go back, even if we
wanted to, and reestablish the "protocol parameter" argument for
the DNS.

So we are down to some serious and important questions --  but,
again, ones that are neither new nor surprising.   In
particular, since you and others have picked up bits from my
earlier notes and interpreted them (I'm sure unintentionally)
differently from what I intended:

(i) The observation about YAH00 versus yah00 wasn't intended to
say that a lower case test would solve very many problems.  It
was only to point out that the particular YAH00 example wasn't a
particularly good one, since it could be detected by the most
trivial of tests.  I agree that test is not likely to be
effective against a determined attacker or more clever examples.

(ii) I have never argued that the "one label one script"
requirement that Mark Davis and others have suggested is without
value.  My comment was only that a requirement of that type was
going to be a little harder to apply --in many cases and
consistently-- than a casual reader might assume.  None of this
is easy.  Life is hard.

(iii) The observation about "...easy input of every Unicode
character" is not, in any respect, an attempt to get us back to
protocol identifiers.  It was, instead, about one of the more
subtle questions associated with the IDNA story.  IDNA's most
passionate advocates are convinced that, once a sufficient
deployment level is achieved, no one will need to look at the
internal, "punycode" form of IDNs, but will see only the "native
character" form.  Others of us are convinced that user-visible
punycode will be around forever, just as user-visible URLs will
be.  We believe that will be driven partially by security
concerns (I can more accurately compare two punycode strings by
eyeball than I can a pair of arbitrary "native character"
strings).  We believe that the difficulties you might have
reading an IRI that contains an unfamiliar script out of a
printed article or sign and typing it into a computer will cause
you to wish that the punycode representation were readily
available, because "recognize the character and then figure out
how to key it in" is likely to be an insurmountable pair of
problems.   The issue isn't one of  the expansion of Unicode or
how many keystrokes are needed: if you can identify the
character, any BMP Unicode character can be keyed in a little
over four keystrokes, and non-BMP characters don't take many
more (the "little" is determined by whatever you need to do to
indicate that characters are being specified by offset.  The
issue is recognizing the character accurately in the first
place.  The cell phone story is equally unimportant because the
first step in that story is identifying the right language so as
to permit you to pick up the right phone (or switch it into the
right state).  Language identification may or may not be harder
than character identification, but it isn't likely to be easy in
the general case.  Without language identification, you are back
to character identification and four (or five or six) digit
offsets.

(iv) The TLD managers worldwide are not crying "please protect
us from IDNs" and this latest "discovery" is unlikely to change
that.  What they are saying is "we want and need to implement
IDNs, please help us understand how to do that safely".   The
answer to that question doesn't require "regulation" from on
high.  It does require getting and sharing a much more subtle
understanding of the issues, options, and tools than we have so
far been successful in communicating.  IMO, the IETF should be
putting energy into those issues and tools --and to alternatives
to the use of DNS names (with IDNA) when that is appropriate.
But efforts to move in those directions have gotten zero
traction.   _That_ is, IMO, our problem, not whether we can turn
back the clock and make a "protocol parameter" decision (or turn
it back even further and reduce the number of scripts and
characters in the world be several orders of magnitude).

This isn't easy.  It is never going to be easy.  It poses
opportunities for various nasty behavior that are harder to
detect and defeat in a hostname/LDH-only world. The easiest way
to get ourselves into trouble is probably to pretend it is easy
and ignore the hard, risky, or edge cases.  We need to learn to
cope: wishing for an easier and more homogeneous world or easier
times generally, or wishing that an irreversible decision be
reversed, won't get us much of anywhere, no matter how
passionately those wishes are made.  And, like it or not, we are
at as least as much risk of fragmenting the Internet by
appearing to say "no" to some languages or scripts as we are
from confusion among characters in well-thought-out
internationalization efforts.

     john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 12 Feb 2005 23:03:21 +0100

John,
May be some analysis to structure the debate. Lingual digital relations are 
supported through three layers: (1) computer interoperability, (2) human 
interintelligibility,(3) human interface.

- at layer 2 relations are brain to brain and support interintelligibility 
in using written languages. The scripts of these languages are supported 
through the Unicode system and are to be tagged for computer recognition.
- at layer  1 relations are end to end and support interoperability in 
using protocols with various digital, hexa, 7 or 8 bits coding and 
parameter systems registered with the IANA.

One of these protocol is the DNS which uses a "-.0Z" numbering plan within 
the 7 bits area, simplifying its human utilization by reference to Arab 0-9 
universally used characters and internationally used Roman A-Z characters. 
This also permits an easy bridging with other plans restricted to 0-9, O-B, 
or 0-F and the direct support of telephone numeric names. It has a direct 
total or partial mnemonic capacity for persons having English, Latin or 
Latin scripted languages.

Internationalization, at end to end layer, permits (punycode in the DNS 
case, not defined in the email LHS) to support a multilingualization at 
brain to brain layer and to provide the same mnemonic capacity to people 
having other languages. Vernacularization is the process which permits 
human interfaces and applications processes to fully take advantage of 
multilingualization, in usage cases ranging from language menus or combos 
to full IRI support.

A common problem is to overlook the multilingualization layer because it is 
transparent in English (an ASCII string is not affected by punycode). This 
layer violation creates the discussed security violation. This layer 
violation is the Verisign's disrespect of the ICANN requirements (at 
multilingualization layer) requiring the registration of IDNs using codes 
from a single language Table.

This common overlook of the multilingualization layer is aggravated by the 
proposition of a unique internationalization layer langtag (independent 
from IDN language Tables) where it does not belong: to describe all the 
vernacular views of a language.

IMHO, a correct generalized approach of multilingualism in the Internet 
consists in structurally acknowledging the three layers permitting to 
clearly tell the users in which exact context they are. This should be 
based upon a five constructors language tag (lang5tag):

- three internationalization layer descriptors.  They are used to register 
the IDN Tables: the language, the script and the domain of use. The RFC 
3066 define the use of ISO 639 codes for the language. RFC 3066bis proposes 
to use the codes of ISO 3166 for national domains and ISO 15924 for the 
scripts. This is a basic correct proposition, there are more general and 
more precise sources if needed.

- a multilingualization layer descriptor: the authoritative reference for 
the considered view of the language.

- a vernacularization layer descriptor: the style, that is the environment 
of the considered application (protocol, administrative, familial, formal, 
commercial, SMS, adult, etc.)

This lang5tag should be part of the IRI description, and supported by an 
icon to be shown in the browser bar. An example: if you send a mail your 
boss secretary will print and present in his daily folder, you may want him 
to know you sent it from a Chinese mobile instead of from your English text 
processor. An ISO 7000 conformant glyph system can probably be designed.

jfc

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Feb 2005 15:28:03 -0800

>  authentication MUST (emphasis in original) be used, regardless of

Section 4.3 says "unless it has already 
independently established authentication or 
authorization (such as being within a protected 
subnetwork)."  It's not uncommon for 
organizations to deploy MSAs that treat all 
internal connections as authenticated, even if 
they allow travellers to connect in using port 
587 and in that case require authentication.

>  would comply with a "SHOULD", however).

My understanding is that implementations are 
permitted to have configuration options that 
allow sites to deploy them in ways that violate 
the RFCs, as long as they can be operated in a 
conforming manner.  For example, it is not 
uncommon for POP implementations to have options 
to have timeouts shorter than mandated, or to 
enter UPDATE state on abort.

There are several implementations which have 
default configurations which do comply with 4.3, 
even if they have non-default configurations 
which do not comply.  Likewise, there are other 
implementations which have a default 
configuration which does not comply, but can be 
configured to comply.

>  implementations" test for advancement to Draft Standard status.

From my understanding of the requirements, there 
are multiple implementations which comply.  This 
is based on two points: (1) implementations can 
be compliant even if they have options which 
permit non-conformance; and (2) there must be at 
least two implementations for each feature, but 
it is not required that any individual 
implementation meet every SHOULD.  I believe 
Message Submission meets the criteria on the 
basis of either of these points; the fact that it 
meets it on both is nice but not required.

>  First, the reason that I'm sending this 
> directly rather than to ietf-submit is that
>  list contributions about a month ago; 
> unfortunately the list archive on the IMC web
>  in delivery.  For example, there is no 
> standardized extended status code to address

There does seem to be a disconnect between the 
meaning of 5.6.2 in the Message Submission 
documents and the Extended Status Codes 
documents, and this should be fixed in this 
revision, perhaps by deleting specific extended 
response codes from this revision, at least those 
that overlap or conflict with those already 
specified elsewhere.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
All generalizations are false, including this one.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Feb 2005 01:14:46 -0500

Bruce,

Let me make a few observations, largely, in support of my
esteemed co-author...

--On Tuesday, 15 February, 2005 15:28 -0800 Randall Gellens
<[email-masked]> wrote:

>>>  >  Specifically regarding the 4.3 MUST quoted above and the
>>>  >  reply code, and the necessary two independent
>>>  >  implementations required for advancement to Draft
>>>  >  Standard status, do the implementations supporting the
>>>  >  request to advance to Draft in fact unconditionally
>>>  >  require authorization (i.e. independent of whether port
>>>  >  25 or 587 is used, and regardless of administrative
>>>  >  configuration other than specifying that the
>>>  >  implementation is to act as an MSA), and reply with code
>>>  >  530 (unspecified extended response code) if
>>>  >  authorization is lacking?
>>> 
>>>  Both the draft and RFC 2476 allow submission to use 25
>>>  instead of 587, but state that "normally" 587 is used, and
>>>  allow 25 to be used in order to accommodate implementations
>>>  that are hard to configure. Both say that port 587 is
>>>  reserved for submission.  So, 587 is the normal case for
>>>  submission, and 25 is an exceptional case.
>> 
>>  But as written, section 4.3 specifies that when acting as an
>>  MSA, authentication MUST (emphasis in original) be used,
>>  regardless of port.
> 
> Section 4.3 says "unless it has already independently
> established authentication or authorization (such as being
> within a protected subnetwork)."  It's not uncommon for
> organizations to deploy MSAs that treat all internal
> connections as authenticated, even if they allow travellers to
> connect in using port 587 and in that case require
> authentication.

Bruce, if I understand your concern (I may not), let's back up a
bit and look at a bit of history and the usage case.  The notion
of a separate submission protocol arose in part out of a problem
that became clear when we were doing 2821.  There were a whole
series of things that we would really prefer that MTAs not do
--things that violated the "don't mess with the message"
meta-principle for MTAs but were necessary because clients
weren't able to supply all of the information needed for a valid
2822/822 message, or weren't able to supply it in a form that
would be security-acceptable.  So, to face the reality of the
fact that these MTA-fixes were being applied (and were
necessary), 2821 contains a loophole for submission servers to
fix messages up.

That loophole is, however, somewhat bad news, since it doesn't
involve explicit client authorization for message-tampering and
there is no real way to permit such authorization even if one
wanted to do it (similarities to some of the OPES issues here
are not coincidental).  "Message Submission" ("Submit" below) is
obviously different: we allowed for extensions to be used with
Submit that are not specified for SMTP (even though no one has
done that -- the mechanism has been shown to work with
extensions that are also specified for SMTP) and the mere fact
of using the Submit protocol says "this is a submission agent,
not a general MTA, and hence gets to use those features".

Now the intent is that Submit be used on its own port, for all
of the obvious reasons.  But (i) nothing really prevents it from
being run on _any_ port; such is the nature of IETF applications
protocols and (ii) in particular, it can, explicitly, be run on
Port 25.   But, if it is run on port 25, the question
immediately arises as to how you tell it from SMTP, since the
two are deliberately quite similar in their handshakes.   The
answer is "administrative or policy decision, reflected in
configurations".  No other answer really makes sense.  And, if
you get that far, then you need to ask the question of whether
one would want to permit a host whose port 25 is being used to
support Submit to also support SMTP.   And the answer is that
the question is meaningless if you are not either using Submit
extensions that are not defined for SMTP (or vice versa) and a
really dumb idea if you are and feel like mixing the two and
distinguishing heuristically, halfway through the protocol
transaction.  Such a concurrent implementation on the same port
would actually probably violate both specs, since it would have
to advertise extensions that were not defined for the protocol
that the client was expecting (not that doing so would make a
lot of difference).

So...

>>  Again, "or not" is not allowed by the draft as written;
>>  implementations with an "or not" provision would fail to
>>  comply with the "MUST" (they would comply with a "SHOULD",
>>  however).
> 
> My understanding is that implementations are permitted to have
> configuration options that allow sites to deploy them in ways
> that violate the RFCs, as long as they can be operated in a
> conforming manner.  For example, it is not uncommon for POP
> implementations to have options to have timeouts shorter than
> mandated, or to enter UPDATE state on abort.

This has always been the rule, at least since we decided that
specifications, to advance to draft, must exhibit implementation
of all of the features.  We don't do code review to verify
conformance and spot possibly-non-conforming capabilities.  The
rule is that the implementations must be able to demonstrate
that they can be configured in a way that conforms to the spec.
Nothing else counts as it is, by definition, outside the
specification.

>...
> From my understanding of the requirements, there are multiple
> implementations which comply.  This is based on two points:
> (1) implementations can be compliant even if they have options
> which permit non-conformance; and (2) there must be at least
> two implementations for each feature, but it is not required
> that any individual implementation meet every SHOULD.  I
> believe Message Submission meets the criteria on the basis of
> either of these points; the fact that it meets it on both is
> nice but not required.

Under other circumstances, I might actually quibble about (2),
but (1) is the important point.

>>>  >  On another matter, admittedly unchanged since RFC 2476,
>>>  >  there seem to be some undesirable discrepancies between
>>>  >  submission and non-submission ESMTP regarding extended
>>>  >  response codes.  Draft section 3.4 states that extended
>>>  >  status code 5.6.2 means "Bad domain or address", whereas
>>>  >  RFC 3463 assigns that code the semantics "Conversion
>>>  >  required and prohibited" [RFC 3463 section 3.7].  The
>>   > >  corresponding RFC 3463 extended response code for
>>>  >  domain/address issues would be in the 5.1.XXX range [RFC
>>>  >...

To the extent to which this is an issue, it is an issue with RFC
3463 and not with this draft.  A real problem would arise only
in the "both protocols, same machine, port 25" case described
above.  But I agree with Randy -- the right action is to delete
the specific codes from this specification and leave that to
1893, 3463, and their successors.

>>>  >  the draft should explicitly say so (the term "gateway"
>>>  >  does not appear anywhere in the draft). [that would be a
>>>  >  novel use of the term "gateway" in Internet mail; a

Actually, we discovered in working on RFC 2821 that life wasn't
that easy.  First, it has never been the definition, "usually"
or otherwise:  at the time 821 was written, the concept of a
mail gateway applied when either one side was in a non-SMTP
environment or when one side was in a non-TCP environment,
whether SMTP was being used or not (or, indeed, when the two
sides didn't share underlying transports, whether either one was
TCP or not).
While I would prefer that "one side in non-SMTP or different
transport" definition, one runs into real-world problems when
the addressing structures differ, whether SMTP and TCP are on
both sides or not.  For example, assume that one has a
submission client on a private network using 1918 space.  It
submits the message to an MSA which lies at the NAT boundary
between that network and the public Internet.  To meet the
requirements of 2821, the MSA (or submission MTA) should modify
or supplement addresses and internal names so that they reflect
public names and addresses.  That moves it into gateway
territory, and 2821 was written to permit that case (doesn't
make that I, or the DRUMS WG, liked the case very much, but it
reflects reality).

>>>  >  Conversely, if MSAs are not always to be considered as
>>>  >  gateways, then returning errors in response to message
>>>  >  content is: 1. explicitly counter to the SHOULD NOT of 
>>> RFC 2821 section 3.4 (bottom of
>>>  >     page 18)
>>>  >  2. inappropriately associated with "conversion"
>>>  >  semantics where no conversion is in fact required
>>>  >     (indeed, 
>>> other than adding trace fields,
>>>  It is not the intent of either this draft or RFC 2476 to
>>>  say that MSAs are always gateways; rather, the intent in
>>>  both is to recognize the reality that organizations
>>>  sometimes see a need to examine and potentially modify
>>>  messages submitted using their servers, and to make a clear
>>>  distinction between this case, and the

Bruce, you are assuming, I think, that every MSA must be
conformant to the MTA requirements of 2821 (gateway or not).
That was never intended to be the case.  Indeed, that is part of
the reason why this is a separate protocol (i.e., the "clear
distinction" to which Randy refers to above).

best,
   john

---

From: Martin Duerst <[email-masked]>
Date: Fri, 18 Feb 2005 14:51:46 +0900

>faster than the available memory space on low-power, compact, mobile

Bruce - Would you care to supply some sources for the argument above?
Computer power, including mobile devices, is still pretty much
increasing exponentially. Unicode space allocation has never
increased exponentially, and is slowing down.

Regards,    Martin.