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:
1 - SMTP.ADDRESS -> FORCECASE(SMTP.ADDRESS) -> SHIM -> COMPARE
2 - SMTP.ADDRESS -> SHIM -> FORCECASE(LOCAL STACK ADDRESS) -> COMPARE
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.
--
Sincerely
Hector Santos
http://www.santronics.com