On Sat, 2004-07-31 at 10:16, Scott Kitterman wrote:
"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."
As Roger Moser kindly pointed out, this is how both his Windows library,
and and libSPF handle domain names. As previously mentioned
"libspf-alt" aka "libspf2"* is simply a young library, and is usually
the case its suffering from growing pains such as mistakes like this.
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.
And you would be correct.
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.
libSPF was written without consultation of the Mail::SPF::Query
interestingly enough. This is why in the version that in the near
future be 1.0 STABLE, will be vacant of the "features" that IMHO taint
MSQ and "libspf-alt" aka "libspf2" libraries.
I have been careful to simply try to implement only what the RFC states
is mandatory (you MUST), and using common sense when implementing the
non-mandatory (you MAY or you SHOULD) sections, using the RFC as a guide
rather than someone else's implementation. If you are to implement the
RFC to the letter, one certainly can't be shown in a bad light for
following the letter of the law, but following the behaviour of
preceding libraries is not best practise. I would not even recommend
that you would look only at my library when attempting to implement, not
with a copy of the RFC in "your other hand" so to speak.
All of the goodies and other features will be available in distributions
subsequent to a STABLE available library, this is the MOST important
focus since without reliable software no matter how sound the protocol
is, its doomed to suffer on one scale or another.
* In spite of the name change to "libspf2" I would liken this library to
an adolescent attempting to purchase liquor as a minor using the
identification belonging to another. Well... if the shoe fits...
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part