Mailing List Archive

Re: libspf C header file
I took a quick look at your header file, and a couple of things spring out:

* There seem to be a lot of functions there. I suspect that many of them
are used only internally to the library, and hence shouldn't be in the
exported header file.

* The fuctions do not all live in the same namespace -- some start with
UTIL, some with SPF, MTA, ERROR, MACRO. It is much more preferable to
have all the externally visible functions start with the same prefix.

* the SPF_PREFIX enum has a bogus ,T in it

* It is typically bad practice to have an initialized array in a header
file (unless the use is very carefully controlled).

* in your peer_info_t, it is not clear that all the fields have the
correct length. As I recall, domain names can be up to 256 characters.

Philip

James Couzens wrote:
> http://libspf.org/files/spf.h
>
> Here is the header from our alpha release.
>
> If you are running Qmail, and you are willing to test the alpha version
> drop me a line and I'll see you get a copy. Currently there are memory
> problems in the macro parsing functions so parsing records of those
> nature currently are handled by a stub function that simply allocates
> memory equal to the passed "macro" and returns it to the calling
> function.
>
> Cheers,
>
> James
>
> On Tue, 2004-01-20 at 08:16, Terence Way wrote:
>
>>If you guys are feeling, er, critical:
>>
>>Attached is SPF.H, a proposed API into an asynchronous, nonblocking SPF
>>implementation.
>>If the attachment doesn't go through, download it at
>>http://www.wayforward.net/spf/spf.h
>>
>>The only implementation I have behind this is throw-away code that
>>checks if this API works with both libresolv and adns.
>>
>>Summary:
>>spf_init()
>> called once at program startup (might call res_init, for instance)
>>
>>spf_open()
>> create a context for an asynchronous query, context contains DNS
>>queries for the user to perform.
>>
>>spf_txt()
>>spf_a()
>>spf_ptr()
>>spf_mx()
>> called for each answer/additional-info record in a DNS response.
>>Example: two MX records with corresponding A records in the
>>additional-info would result in spf_mx(), spf_mx(), spf_a(), spf_a().
>>
>>spf_check()
>> Steps through the SPF checker, returns spf_incomplete if there are
>>more DNS queries for the user to perform, or returns one of spf_fail,
>>spf_pass, spf_unknown, spf_error.
>>
>>spf_close()
>> Free up the SPF context.
>>
>>There is a high-level function:
>>spf_query()
>> which uses a built-in DNS library and blocks until the SPF query is
>>complete.
>>
>>Design notes:
>>spf_open() will merely allocate necessary storage.
>>
>>The spf_query structure returned by spf_open() and used by the other
>>functions keeps a miniature DNS cache of all DNS records fetched by the
>>user. The functions spf_txt(), spf_a(), spf_ptr(), and spf_mx() merely
>>add information to that cache.
>>
>>The real work is done by spf_check(). Its pseudo-code:
>> if already done:
>> return previous result
>> if no SPF text:
>> look in cache for TXT record
>> if not found
>> return spf_unknown
>> find 'v=spf1'
>> if none, or more than one,
>> return spf_unknown
>> tokenize text
>> set current token pointer to first token
>> while we have more tokens:
>> examine current token pointer
>> if we have information in DNS cache:
>> do check
>> if match, return match status
>> otherwise advance current token pointer
>> else
>> set up for DNS query
>> return spf_incomplete
>>
>>The cache records all DNS results, and pays no attention to TTL.
>>
>>More later.
>>T. Way
>>terry@wayforward.net
>>
>>--
>>To unsubscribe, change your address, or temporarily deactivate your subscription,
>>please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: libspf C header file [ In reply to ]
On Tue, 2004-01-20 at 18:22, philip-spf@gladstonefamily.net wrote:
> I took a quick look at your header file, and a couple of things spring out:
>
> * There seem to be a lot of functions there. I suspect that many of them
> are used only internally to the library, and hence shouldn't be in the
> exported header file.

Yep, this isn't the header that one would use to implement its use, but
I figured of value nevertheless, I should have prefaced my email with
that, my apologies. There is an internal header not supplied which is
at the moment subbed spf_head.h which is destined to be the header file
actually used by someone implementing the library. However at this time
we have not progressed forward enough such that this has been
completed. As may be obvious we're in that last mile or 99% range and
its now almost cleanup time.

> * The fuctions do not all live in the same namespace -- some start with
> UTIL, some with SPF, MTA, ERROR, MACRO. It is much more preferable to
> have all the externally visible functions start with the same prefix.

As you state however, thats mostly a matter of preference, but it is my
goal that the exported functions will all be prefaced with SPF_ much as
you would find MySQL.

> * the SPF_PREFIX enum has a bogus ,T in it

Not any more ;)

> * It is typically bad practice to have an initialized array in a header
> file (unless the use is very carefully controlled).

It is, and its also part of the internal library.

> * in your peer_info_t, it is not clear that all the fields have the
> correct length. As I recall, domain names can be up to 256 characters.

Yes some fields do not have the correct length and have assigned values
only suitable to storing the test values I was working with. The
released library will have all of these things up to snuff.

Thanks for your feedback Philip, I look forward to hearing more when you
have a chance to review the library its self.

Cheers,

James
--
James Couzens,
Programmer

obscurity.org
libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com