sm@xxxxxxxxxxxx writes:
> If there isn't an authoritative reference and there are differences in
> semantics or syntax between the draft and RFC5321/5322 or future
> revisions of these documents, it can lead to serious issues.
> Standards Track documents are around years. The documents may be
> edited by different authors as they get updated. Errors can happen;
> the documents can diverge.
>
> In my opinion, it is better to clarify that now or else we will end up
> having discussions ten years from now to determine which
> interpretation is correct or which standard to follow.
So. RFC 3501 (page 50-51), says that the localpart of a From: address is
matched case-insensitively when IMAP servers process SEARCH or UID
SEARCH commands. RFC 5321 says that SMTP servers process localparts
case-sensitively. Both rules go back essentially unchanged to very old
RFCs.
But that's the problem - this is not what RFC 5321 says. It 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.
SMTP server do stuff like expand lists all the time. For those tests to be
done competently some amount of interpretation of local parts may be needed,
such as ignoring the possibility that the local part is case sensitive.
Now, if RFC 5321 instead said that interpretation of local parts MUST be
limited to comparison operations, and local parts MUST NOT be modified, the
problem mostly goes away. (There are probably still some odd corner cases left
for gateways, but after thinking about it some more I think we can ignore
those.)
Do we need to discuss which is correct or which standard to follow? I
fail to see any conflict.
I have to disagree. While there may not be any conflict between RFC 3501 and
RFC 5321 since they deal with separate components, the fact remains that
there's a conflict between what real world implementations do and what RFC 5321
says must not be done.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf