[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-03-05 15:58:34

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

> This isn't about any of that. This is about the operations an SMTP
> server is allowed to perform on the addresses associated with other
> domains that appear in MAIL FROM and header fields. RFC 5321 says
> the only thing you can do with such address is copy them around
> untouched. But the reality is these addresses are *compared*.

Excuse me if I am not following you, but the compares are implementation specific. Like Finch pointed out, Sieve doesn't care. What you are saying, I think, you know of a procedure that does care what the input is. Right?

> we're not talking about any sort of modification - with
> other addresses in ways which, like it or not, assign
> specific semantics to local parts. And RFC 5321 says that's
> not allowed.

I am not reading it that way. I am reading it should not ASSUME a case for the purpose of some unknown or out of scope process. Preservation is the best policy.

I have a perfect example. Due the age of our software, there could be versions out there that export mail and SMTP reads and sends mail out:

    MAIL FROM:<first(_dot_)last(_at_)example(_dot_)com>
    MAIL FROM:<FIRST(_dot_)LAST(_at_)example(_dot_)com>
    MAIL FROM:<FIRST(_dot_)LAST(_at_)EXAMPLE(_dot_)COM>

What is the receiver system to assume here?

   Should it lower, upper, keep case before passing it to
   should avs, shim, script, acl queue?

I think SMTP is saying to KEEP is the best policy.

I'm not sure what you are getting too but consider the alternative:

    - rule that states its one case over another and that all systems
      MUST compare, store and render displays in one case?

No, I'm not saying anything like that. I want systems to have the freedom to perform whatever comparison operation they believe are
> appropriate, including ones that assume case sensitivity, or
> insensitivity, or which attempt to strip common subaddress forms,
> and so on. Right now they are prohited from doing any of that.

Man, I really wish I understand you because I see no such prohibition at all. All it is saying is don't force it way way or another, keep as is and hopefully before the entire process is complete.

Preservation - leaving it alone is the base way to handle this, even
if you not modifying.

Here's the difference:


The first one opens the door to having a single storage where the case
has been modified (ie. you need to pass a copy to preserve it).

These are implementation details. Sure, if you implement comparison operations incorrectly you'll end up modifying the addresses, which
> would be bad. But hopefully coders can manage to make a copy of the
> field they're interesting in comparing before
> performing canonicalization operatioions on it.

I believe SMTP is closely modeling #2. It is not going to force the case for SIEVE or any other shim process to work. mail bot developers SHOULD NOT presume their input will be pre-pre-prepared one way or another. In fact, I would state these mail bots should make it clear that they might need originality to be preserve. Sieve apparently does. Most similar systems today are case insensitive operations. But SMTP is helping this part by telling SMTP developers to please preserve it regardless of what the input is.


Hector Santos

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