Ned Freed wrote:
RIght, and that's exactly the point. Right now RFC 5321 says they can't be.
Like Finch pointed out, Sieve doesn't care.
That's wasn't Tony's point. His point was that Sieve breaks the RFC 5321
rule by allowing scripts to assign whatever semantics they like to local
parts of external addresses.
This is so odd.
Sieve can be case-sensitive or case-insensitive (the
latter is the default) and even has an extension for
> extracting subaddress information from arbitrary addresses.
All of which would not be possible if SMTP did not preserve the
address case.
What you are saying, I think, you know of a procedure that does care
what the input is. Right?
Nope. I'm saying that there's all sorts of stuff out there busily
comparing the local parts of addresses they don't own using all sorts
> of different rules.
Again, all of which would not be possible if SMTP did not preserve the
address case.
And that stuff is in clear violation of RFC 5321.
If SMTP did touch it, then it would be in violation or it might cause
problems for software that may WISH to look at the case.
So I am really having a hard time understanding what you are talking
about - or rather what you are proposing to see happen.
The word "case" isn't even mentioned in the text in question, so I fail
to see how you can possible get such a reading out of it.
Come on Ned, see section 2.4.
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?
Well, you'd better hope it doesn't follow RFC 5321 rules, because
> that would imply a case-sensitive comparison be done against any
> stored authorized address list. And that's going to cause at least
> one of these to fail no matter what's on the authorized list.
But thats presuming there are significant # of mail-bots are still
looking for specific case.
Would you should this the the norm? passe?
I will venture most systems have learn not to do case sensitive
compares, including us.
In practice, of course, pretty much every autoforwarder, list server,
and so on out there does a case-insensitive comparison.
I fail to see the conflict then. But you do make implementation
assumptions that should be out of scope. What if there are
auto-forwarders, list servers that do case sensitive compare? You are
probably right, low chance. But SMTP should not be assuming one way or
another in order to fix those that may be working with lower or upper
case or not doing case-insensitive compares. It should not be SMTP
concern.
I can only begin to better understand your point better if you are
suggesting SMTP should be forcing a case - maybe to the common
dominator of lower case addresses.
> And it isn't at all uncommmon to ignore subaddresses too.
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.
Of course it should keep the case. Again, modification of the address isn't
at issue.
Right, what is at issue is how you wish SMTP semantics to be changed
to one that probably isn't very realistic.
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.
Well, all I can say is that I sure see such actions as prohibited by the
current language. And it seems that most other people who have weighed
in on this at least agree it can be interpreted that way. You choose not to, and
that's certainly your perogative, but if it can be interpreted in a way
that causes various common operations to be considered incompliant I see that
as a problem.
Ned, I'm grown tired of this attacks. Its funny that I could of
blabbed the same thing about you. So you beat me to it (although I
wasn't planning to) and labeled me the odd ball here. Fine, its par
for the course here.
But we are handling it right and that is all that matters - we are
preserving it - at the SMTP level. So whether you believe 5321 is
incorrect, as it was yesterday 2821 and today 5321, we are compliant.
What you have yet to explain is why it is important or broken for some
specific auto-forwarder?
The reality is as clear you implied:
Most systems do a case-insensitive compare
so its really a practical moot point.
It sounds like you are assuming all auto-forwarders with some "access
controls" (whatever that means and doesn't matter) behave with the
same logic and you know that is not true.
So this is an implementation issue, not an architectural issue and to
assume that it is, is to presume that the entire network is operating
under some specific constant level - which is not reality.
The architectural recommendation is preservation. That has always
been the best policy across the board.
That does not mean you have to do case [in]sensitive compares. Thats
out of scope and up to you.
Anyway, I don't see a problem with 5321 wrt to this issue.
So -1 on changing it.
-
Sincerely
Hector Santos
http://www.santronics.com