Mailing List Archive

Developer-friendly specifications?
We develop anti-spam software, and have been asked to provide support for
SPF. After a few hours browsing the site, mailing archives, downloads, we
find the theory / implementation useful in helping lowering spam. While a
lot of info for administrators is available, what I did not find were
"friendly" guidelines on what developers need to do to implement SPS in our
existing applications. Being told to "review the reference Mail::SPF::Query
library" and finding myself plowing thru perl code is not exactly what I was
looking for... Nor is going thru the RFC and translating it into code.

If more info is already available, as flow charts, abstracted code snippets,
more-modern-than-perl code samples, I apologize, but was not able to find
them. If they are not available, I would suggest the community that is
trying to push SPF to be more widely supported by existing anti-spam and
mail server softwares to make them available, as there are developers ready
to implement the standard, but are slowed down by the lack of supporting
materials necessary for a smoother integration.

Roberto Franceschetti
roberto@netwide.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Developer-friendly specifications? [ In reply to ]
In <20040603040619719.AAA670@miseno.netwide.net@38.129.202.68.cfl.rr.com> "Roberto Franceschetti" <roberto@logsat.com> writes:

> We develop anti-spam software, and have been asked to provide support for
> SPF.

Cool!


> [...] Being told to "review the reference Mail::SPF::Query
> library" and finding myself plowing thru perl code is not exactly what I was
> looking for... Nor is going thru the RFC and translating it into code.
>
> If more info is already available, as flow charts, abstracted code snippets,
> more-modern-than-perl code samples, I apologize, but was not able to find
> them. If they are not available, I would suggest the community that is
> trying to push SPF to be more widely supported by existing anti-spam and
> mail server softwares to make them available, as there are developers ready
> to implement the standard, but are slowed down by the lack of supporting
> materials necessary for a smoother integration.

For better or worse, the SPF community is mostly just a bunch of
volunteers that are trying hard to help. Very Few of us have been
paid anything to write the documentation or the implementations, and
those that have been paid, have generally not released their code or
published any new documentation.

Sorry.

If you would like to help out, it would be greatly appreciated.


I doubt that you will consider my libspf-alt C implementation to be
"more modern than perl", but I have written up some documentation on
an API that has been implemented. This API matches the functionality
of several other implementations, so it might be useful for you.

In particular, you might want to check out the "documentation" section
in:
http://www.midwestcs.com/spf/libspf-alt/index.html


For testing purposes, you might also find the following useful:
http://www.midwestcs.com/spf/tests/index.html


Since most people are domain owners or mail admins rather than
developers, the developer info is not on the front page. You have
said that you have looked around on the spf.pobox.com website, so this
maybe stuff you have already seen, but in case you haven't, here are
some pointers.

The site index (http://spf.pobox.com/site-index.html) does have a link
to the Developer's Guide (http://spf.pobox.com/developers-guide.html).
Also, there is quite a bit of stuff on the downloads webpage
(http://spf.pobox.com/downloads.html).

I'm not sure if there is a link to it, but you might also find
http://spf.pobox.com/slides/ to contain some general flowcharts and
such.


I realize that you said you don't want to read the RFC, but I'm afraid
that if you want to create a new SPF implementation, there is no royal
road to learning. You will almost certainly need to read the RFC
several times and to use the SPF test suite to make sure you have
implemented your code correctly.


If you have more specific questions, please let us know.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Developer-friendly specifications? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Torsdag den 3. juni 2004 06:06 skrev Roberto Franceschetti:
> Being told to "review the reference Mail::SPF::Query
> library" and finding myself plowing thru perl code is not exactly
> what I was looking for... Nor is going thru the RFC and translating
> it into code.

If you want to implement something, then read the specs (RFC) or use
the code someone else wrote unmodified... in my world there is no
other choice.

If you don't know the specs, your home-made programming won't work
correctly. It's that simple.

Lars.

- --

Mobil: 20331241
Evt.: 70201241
Fax.: 70201242

My public GnuPG key: http://dybdahl.dk/lars/gpg/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvsRz54sHDEeNGSIRAocyAJ9S9zHELA10afKLc0YUdYuOquN0dACfQjpx
o/c+sKMRBJHqb0qygGdGz4Y=
=KkBx
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Developer-friendly specifications? [ In reply to ]
Hi, Roberto

> We develop anti-spam software, and have been asked to provide support for
> SPF. After a few hours browsing the site, mailing archives, downloads, we
> find the theory / implementation useful in helping lowering spam. While a
> lot of info for administrators is available, what I did not find were
> "friendly" guidelines on what developers need to do to implement SPS in our
> existing applications. Being told to "review the reference Mail::SPF::Query
> library" and finding myself plowing thru perl code is not exactly what I was
> looking for... Nor is going thru the RFC and translating it into code.

I see that your SPAMFilter software is for Windows.

One of my company's customers has requested that we build a .NET
component for SPF. We're very well suited to the task because we
already have DNS and email-related components for COM and .NET (the
.NET versions are in beta right now). Our business is essentially
built around making simple building blocks for complex network
functions.

The problem is that we don't know if there's enough of a market for a
commercial COM/.NET component given that SPF is extremely young,
changing, and surrounded by free, open-source implementations. We
either have to do it as a custom job or find enough customers to
cover the development costs of doing it as a commercial component.

We've given a proposal to the customer who made the request, and he's
still considering it. If you're interested, we may be able to work
something out with you, too.

Benefits of the proposed solution:
- Easy integration into Windows software -- COM or .NET
- Documentation and sample code showing exactly how to use it
- Responsive tech support that will answer your questions and fix
problems instead of just referring you to the RFC
- Insulation from many of the gory details and ongoing changes of SPF

If you (or anyone else on this list) would be interested in a COM or
.NET implementation for Windows, send me an email off-list.

Thanks,
Gavin

--
Gavin Williams, technical director
Hexillion Technologies
gavin@hexillion.com http://www.hexillion.com/

Validate and investigate email addresses with the Email Dossier
http://CentralOps.net/


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Developer-friendly specifications? [ In reply to ]
Hi, Roberto

> We develop anti-spam software, and have been asked to provide support for
> SPF. After a few hours browsing the site, mailing archives, downloads, we
> find the theory / implementation useful in helping lowering spam. While a
> lot of info for administrators is available, what I did not find were
> "friendly" guidelines on what developers need to do to implement SPS in our
> existing applications. Being told to "review the reference Mail::SPF::Query
> library" and finding myself plowing thru perl code is not exactly what I was
> looking for... Nor is going thru the RFC and translating it into code.

I see that your SPAMFilter software is for Windows.

One of my company's customers has requested that we build a .NET
component for SPF. We're very well suited to the task because we
already have DNS and email-related components for COM and .NET (the
.NET versions are in beta right now). Our business is essentially
built around making simple building blocks for complex network
functions.

The problem is that we don't know if there's enough of a market for a
commercial COM/.NET component given that SPF is extremely young,
changing, and surrounded by free, open-source implementations. We
either have to do it as a custom job or find enough customers to
cover the development costs of doing it as a commercial component.

We've given a proposal to the customer who made the request, and he's
still considering it. If you're interested, we may be able to work
something out with you, too.

Benefits of the proposed solution:
- Easy integration into Windows software -- COM or .NET
- Documentation and sample code showing exactly how to use it
- Responsive tech support that will answer your questions and fix
problems instead of just referring you to the RFC
- Insulation from many of the gory details and ongoing changes of SPF

If you (or anyone else on this list) would be interested in a COM or
.NET implementation for Windows, send me an email off-list.

Thanks,
Gavin

--
Gavin Williams, technical director
Hexillion Technologies
gavin@hexillion.com http://www.hexillion.com/

Validate and investigate email addresses with the Email Dossier
http://CentralOps.net/


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com