On Thu, 30 Jul 2015, Reindl Harald wrote:
Am 30.07.2015 um 01:53 schrieb Bill Cole:
Does this text look at all familiar?
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part (SMTP
Extensions may explicitly specify case-sensitive elements). That is,
a command verb, an argument value other than a mailbox local-part,
and free form text MAY be encoded in upper case, lower case, or any
mixture of upper and lower case with no impact on its meaning. The
local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts.
and then comes the real world.........
* no mailserver on this world treats the local part case-sensitive
* you sell "ha...@example.com" is a different person than
"ha...@example.com"?
* well, how do you handle half of your users just for fun
using caps in their mail client and the other half don't
I ONCE made the mistake of disabling case-squashing while setting up a new
mail server (the delivery part, not the transport part) and got my butt
chewed when the users went balistic. So for a little while there WAS a mail
server which treated the local part case-sensitive. ;)
(Note in my original post I did say "and most systems are too WRT the email
ID").
It's good for the official RFC specs to demand case-preserving in the transport
system, but at the delivery endpoint MOST systems are case-insensitive.
As we're talking about mail scoring/filtering which -usually- happens at or near
the end point, the admins probably know if their systems are case-insensitive or
not.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
