-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of
marc(_at_)alaia(_dot_)net
Sent: Saturday, July 31, 2004 12:06 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Case Sensitivity
Hey, everyone. A situation has come up on the SPF-Help list
where a receiver is rejecting inbound mail from a domain and it
turns out that the problem is case sensitivity. A test using
libspf2 verified that libspf2, at least, is case sensitive.
Is this an implementation issue or a spec issue, or not an issue
at all? What I mean is:
- Are all DNS-related issues supposed to be case-insensitive, so
this does not need to be in the spec, but certain implementations
have implemented it wrong?
- Are all DNS-related issues not specified, so the SPF spec needs to say?
- Or do people need to be aware that case may cause their mail to
be rejected?
Here's what I could find in the RFCs (not an RFC expert, so I could have
missed something):
http://www.ietf.org/rfc.html
1034 Domain names - concepts and facilities. P.V. Mockapetris.
Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882,
RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982,
RFC2065, RFC2181, RFC2308, RFC2535) (Also STD0013) (Status: STANDARD)
- RFC 1034 Domain Concepts and Facilities November 1987
"By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit. This means that you are free to create a node with
label "A" or a node with label "a", but not both as brothers; you could
refer to either using "a" or "A". When you receive a domain name or
label, you should preserve its case. The rationale for this choice is
that we may someday need to add full binary domain names for new
services; existing services would not be changed."
1035 Domain names - implementation and specification. P.V.
Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes
RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181,
RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658) (Also STD0013)
(Status: STANDARD)
- RFC 1035 Domain Implementation and Specification November 1987
"2.3.3. Character Case
For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner. At present, this rule is in
force throughout the domain system without exception. However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided.
When data enters the domain system, its original case should be
preserved whenever possible. In certain circumstances this cannot be
done. For example, if two RRs are stored in a database, one at x.y and
one at X.Y, they are actually stored at the same place in the database,
and hence only one casing would be preserved. The basic rule is that
case can be discarded only when data is used to define structure in a
database, and two names are identical when compared in a case
insensitive manner.
Loss of case sensitive data must be minimized. Thus while data for x.y
and X.Y may both be stored under a single location x.y or X.Y, data for
a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
general, this preserves the case of the first label of a domain name,
but forces standardization of interior node labels.
Systems administrators who enter data into the domain database should
take care to represent the data they supply to the domain system in a
case-consistent manner if their system is case-sensitive. The data
distribution system in the domain system will ensure that consistent
representations are preserved."
I checked the later RFCs that modify these and they do not change this
guidance. Where character case is mentioned at all, it is assumed that
processing is case insensitive.
Bottom line is that I think the SPF (and I would imagine MARID) specs look
to be ok. It appears to me that (assuming the analysis that this is a case
sensitivity issue is correct) this is best described as an implementation
defect wrt support of RFC 1034 and 1035. Given that many of the SPF
libraries share a common heritage to some degree, they probably all ought to
be checked for this.
Scott Kitterman