Ned Freed wrote:
> That's effectively what section 5.3.11 says:
>
> Consequently, and due to a
> long history of problems when intermediate hosts have attempted to
> optimize transport by modifying them, the local-part MUST be
> interpreted and assigned semantics only by the host specified in the
> domain part of the address.
>
> When you perform a case-insensitive or subaddress-stripped comparison
> with a stored address, you are assigning semantics to the local-part
> of that address. And you're not the host specified in the
> domain part.
I read that to mean to accept as it and decide how you need to use it.
I have no idea what you mean by this.
For example, there is no rule that email address formats MUST be
lowercase, therefore your down link software should not be assuming it
would all be lower case.
I fail to see the relevance.
But that might be exactly how it wants it which only your
implementation would know about because it would be your own
implementation detail.
You keep talking about the fact that local part handling is implementation
specific. That's completely true and only relevant in that it is this fact that
makes not modifying addresses so important.
But again, the issue here isn't how particular implementations structure their
handling of local parts. It is understood that they are free to be
case-sensitive or case-insensitive, or interpret various different characters
as subaddress delimiters, etc. etc.
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* - 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.
>> Its not just about compares, but rendering as well, as well as replies.
>
> Again, nobody is talkng about allowing addresses to be modified.
But that is what the statement implies.
No it isn't. The statement is about assigning semantics. Now, it goes without
saying that if you modify the local part you've assumed certain semantics. But
comparison operations also assume certain semantics.
Like I pointed out, we had a
history of forcing the freaking case when it was gated outside of
282x/532x so there would be no violation as you may to put it.
You're again talking about modifying addresses. THis is not the issue on the
table.
The problem was the reverse, reply system.
> The semantics you've chosen to define for your own addresses are
> irrelevant. We're talking about what sorts of interpretation you're
> allowed to make of addresses you do not own.
>
>> But on the inbound side, it is all preserved but all compares are case
>> in-sensitive.
>
> Which, if you're talking about foriegn addresses, puts you in voilation
> of RFC 5221.
But that is exactly the point of the comments. Preservation is the
recommendation, especially when it isn't your domain - like a reply
address.
You keep going round and round and round about things that would modify
addresses. I really don't know how to say it any plainer - this is NOT my
concern. I have no issue with saying that addresses not be modified. In fact I
would strongly object to any change that allowed modification of addresses in
domains you aren't responsible for.
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.
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.
Ned