In <792DE28E91F6EA42B4663AE761C41C2A0260F2FF(_at_)cliff(_dot_)bai(_dot_)org>
"Ryan Malayter" <rmalayter(_at_)bai(_dot_)org> writes:
However, the following additions to SPF could kill my implementation:
- XML (will libspf-alt support this?)
Well, if it's part of the SPF standard, libspf-alt will eventually
support it, right?
I have publicly stated that I'm opposed to the SPF encoded in XML.
However, I will also publicly state that if the deployment of SPF
encoded in XML becomes significant, I will add support for it to
libspf-alt. By "significant", I mean something along the lines of
"there are too many to just easily use the SPF "override" facility".
Having searched 1.3 million email domain names, I could find only
three domains that send non-trivial amounts of email that publish XML
exclusively. Those are: hotmail.com, microsoft.com and
exchange.microsoft.com. It would be much easier to just add a copy
of overrides for those three domains.
Note that the merged SPF and Caller-ID proposal requires more changes
than just adding XML parsing. We will also need to create code that
processes the email headers using the Caller-ID algorithm and
correctly extracts the right domain name. There is also the RFROM
parameter that needs to be supported.
Even if libspf-alt doesn't support it for some
reason, you're writing a windows event sink, you can probably link to
the MSXML DLLs at runtime, which are present on every server that's
Win2k or newer.
Also, since libspf-alt is open source, anyone can fork it at any time.
-wayne