Open Issue: Stored strings vs. queries.

[Marc Mutz]

Hi!

An interesting issue is what is to be considered stored local-parts and
what is a queried local-part.

Obvious stored local-parts:
- MTA config
- address books (e.g. LDAP)

Obvious queries:
- address lookups (e.g. LDAP queries)
- SMTP commands

Non-obvious:
- Mail headers

One might very well say that a mail header is a request (in that the
user enters it and the SMTP server for the given domain needs to look
it up to return success or failure), so that it's slots would fall into
the "query" category. And naturally, one would like to have the content
of the message headers and that of the smtp commands be subject to the
same rules, now that 282{1,2} agree on the mailbox definition.

However, the POV that the message is stored and it's addresses will be
subject to queries (e.g. by user filtering or searching) isn't way off,
too. There's also the argument that what the server looks up is the
argument given to SMTP's RCPT TO command, not what's in the header
fields.

So the main question I see is whether header field slots (and,
consequently[1], SMTP command slots) are queries or stored.

Marc

[1] I think that the whatever category those belong to, they should both
belong to the same class.

[Paul Hoffman / IMC]

Post by Marc Mutz
One might very well say that a mail header is a request (in that the
user enters it and the SMTP server for the given domain needs to look
it up to return success or failure), so that it's slots would fall into
the "query" category. And naturally, one would like to have the content
of the message headers and that of the smtp commands be subject to the
same rules, now that 282{1,2} agree on the mailbox definition.
However, the POV that the message is stored and it's addresses will be
subject to queries (e.g. by user filtering or searching) isn't way off,
too. There's also the argument that what the server looks up is the
argument given to SMTP's RCPT TO command, not what's in the header
fields.

This doesn't match the general definition of queries and stored in
Stringprep. I cannot see how a header would be considered a query. It
isn't asking for anything, it is a part of the message.

--Paul Hoffman, Director
--Internet Mail Consortium

[Marc Mutz]

On Thursday 13 February 2003 22:04, Paul Hoffman / IMC wrote:
<snip>

Post by Paul Hoffman / IMC
I cannot see how a header would be considered a query.

<snip>

OK, let's do a Gedankenexperiment:

I think we agree that the smtp slots have to be queries. (Else, a single
intermediate MTA running oldVersion will break the transport of a
newVersion-MUA-composed message to a newVersion-mailbox.

Consider the case of stored mail header field slots.

I want to send a message with an oldVersion MUA to a newVersion mailbox
whose local-part contains a code point from the set
U(oldVersion) \cap AO(newVersion)

My MUA will rfc2822-serialize the message, thereby checking that any
to/cc/bcc address meets the requirements of oldVersion-stored
addresses. The address for the newVersion mailbox will fail that step,
since it contains a code point from oldVersion of the U set.

This way, only addresses meeting the requirements of stored addresses
are permitted. This doesn't even change if the MUA keeps track of the
user-entered address separately of the rfc2822 serialization (for later
use in the smtp rcpt to command), since it is simply not permitted to
put the address into the rfc2822 serialization.

The only option for the MUA would be to leave out any address that fails
the stored requirements test, but not the query requirements test[1]
from the rfc2822 serialization, but use the address in the RCPT TO
command. Well, that's what spammers do...

Consider OTOH the case of query mail header field slots.

My MUA will detect that the mailbox meets the requirements of a query
mailbox, and happily put the mailbox together with the others (if any)
into both the rfc2822 serialization slots, as well as the SMTP slots.
Sending succeeds.

Conclusion: If we want oldVersion MUAs to be able to send mails to
newVersion mailboxes (ie. a mailbox whose address contains newly
assigned code points), then rfc2822 slots need to be queries or - if we
insist they are stored - MUAs be required to omit the newVersion
mailbox from the message, but give it in smtp rcpt to.

Since the latter option isn't really an option (all mails from
oldVersion MUA users would appear to be bcc'ed to me, with the BCC
header stripped), the question boils down to:

Do we want oldVersion MUAs to be able to send messages to newVersion
mailboxes?

My answer would be "Yes", since that's what I understand IDNA works hard
to achieve for DNS (an oldVersion browser can still do a dns lookup of
a newVersion IDN).

Marc

[1] If both fail, the address should be rejected.

[Claus Färber]

Post by Marc Mutz
An interesting issue is what is to be considered stored local-parts and
what is a queried local-part.
- MTA config
- address books (e.g. LDAP)

There are two types of address books:
. Authorative address books, which are run by the same authority as the
MTA config files. These are cleraly ``stored''.
. Personal address books, which contain queries (because they are used
to match against addresses _created_ elsewhere). Otherwise, you could
not enter an address that was created by someone using a newer version
of the profile.

Post by Marc Mutz
- address lookups (e.g. LDAP queries)
- SMTP commands
- Mail headers

Again, clearly a ``query''. It makes use of names created elswhere.
Otherwise, you could not send mail to an address that was created by
someone using a newer version of the profile.

The distinction between ``stored'' and ``query'' is an application of
the Robustness Principle: Don't generate names with unassigned code
points (=> ``stored'') but allow them if someone insists that such an
address exists (=> ``query'').
The terms ``stored'' and ``query'' are confusing if used for anything
else than DNS (where the servers ``store'' the authorative list of names
and everyone else ``queries'' these servers).

Claus

[Marc Mutz]

Let's wrap at least this issue up ;-)

Post by Claus Färber

Post by Marc Mutz
An interesting issue is what is to be considered stored local-parts
and what is a queried local-part.
- MTA config
- address books (e.g. LDAP)

. Authorative address books, which are run by the same authority as
the MTA config files. These are cleraly ``stored''.
. Personal address books, which contain queries (because they are
used to match against addresses _created_ elsewhere). Otherwise, you
could not enter an address that was created by someone using a newer
version of the profile.

Post by Marc Mutz
- address lookups (e.g. LDAP queries)
- SMTP commands
- Mail headers

Again, clearly a ``query''. It makes use of names created elswhere.
Otherwise, you could not send mail to an address that was created by
someone using a newer version of the profile.

<snip>

I agree. I think there's a need to spell out when to use the
AllowUnassigned flag in IMAA. So, keeping the "stored" vs. "query"
terms for IDNA compat's sake, we currently have:

Only unset AllowUnassigned for authorative address books.

...for a certain definition of "authorative address book" (AABs). What's
that definition? AABs certainly include the config database/files of
final delivery MTAs. What about MUA identities? Queries, I'd say. What
about a company's LDAP server that contains the addresses of employees
and is administered by the same authority that configures the company's
MTAs? Query? Stored? According to your reply, you'd see them as stored.
Where to draw the line? And as important: How to spell that out?

Proposed text (cf. rfc2821, 2.3.10, last sentence):
The AllowUnassigned flag MUST be set except in the following case.
When the result of the ToAscii operation is to be used as part of the
MTA configuration on the host specified in the domain part of the
address, the AllowUnassigned flag MUST NOT be set.

IOW, only the delivery SMTP server responsible for the mailboxes on the
host specified by the domain part of the address should disallow
unassigned code points in the part of it's configuration that is used
to determine the valid local-parts.

What other "authorative address books" are there and need to be
considered? The LDAP directory that contains the email addresses for
the employees? There are two scenarios:
1. The MTA reads it's config from LDAP, so the MUST NOT set
AllowUnassigned is in effect (since the string stored in LDAP is part
of the MTAs config)
2. The LDAP and the MTA config are fed independently or from a common
source. In this case, the LDAP tree will contain the same addresses as
the MTA config, since the addresses have to match for the LDAP
directory to be useful. So again, the MUST NOT from the MTA config
implicitly carries over to the LDAP strings.

Fine. However, I think the text could more precisely define what part of
the MTA config the clause refers to (like adding a "to determine the
valid local-parts" somewhere in the text). Native speakers?

Marc