Most cars are available in a base-model configuration: you get a manual transmission and a radio. But most buyers consider automatic transmission a must-have; other "standard extras" include power windows, air conditioning, a CD player, and a sunroof.

Similarly, the SPF specification defines the protocol and sets a few minimum requirements for interoperability. But when people talk about "an SPF implementation" they generally expect to see a number of features beyond the base model.

The number of SPF implementations is rapidly increasing. Developers are strongly advised to include the following features. For further details, developers should review the reference Mail::SPF::Query library.

The mailing list for SPF developers is spf-devel; archives are visible to subscribers.

• trusted-forwarder.org is a whitelist of well-known forwarding services. If the regular SPF result is FAIL, SPF implementations SHOULD proceed to evaluate the mechanism "include:spf.trusted-forwarder.org". If it returns a PASS, that should override a FAIL result. Trusted-forwarder.org is intended to ease the transition toward SRS compliance and will stay around for a few years, but not forever.

• If a sender domain has no SPF record, but you want to pretend it has one, you should be able to define a fallback value for its SPF record. Fallbacks are only brought into play when sender domains lack an SPF record. Commonly forged domains are expected to publish SPF records in the coming months, but some laggard or poorly administered domains may be slow to publish; in such cases, you can use "fallback" to help them out. The moment they start publishing, the fallback will not be used. Generally accepted fallback values for major domains will be made available. The syntax for fallbacks should look something like:

    yahoo.com    ptr -all
  *.yahoo.com    ptr:yahoo.com -all

  with the domain (and subdomain glob) on the LHS, and the SPF record on the RHS.

• A comprehensive testing suite is available, with over 350 tests to confirm compliance with the base specification and with these standard extra features. As of April 26 2004, Wayne is the official testing coordinator.

  He has started a website at http://www.midwestcs.com/spf/tests/ with some documentation.

• Support for accreditation is very helpful when SPF is used as a component of an antispam policy engine. If a sender domain publishes an "accredit" modifier, your SPF module should return details of the accreditation to the calling application. The calling application will probably evaluate the accreditation in the context of its reputation engine.

• Support for a best-guess feature will become useful as the world transitions toward SPF compliance. Smaller domains may never publish SPF, but we have observed that those domains tend to pass the rule "a/24 mx/24 ptr". One day, that rule may become an implicit default for all non-publishing domains. When that day comes, it could be implemented as a fallback for the domain glob "*.".

  If your implementation supports best-guess, it should store the lookup result in the header X-SPF-Guess, with a similar syntax to Received-SPF.

The above features were intentionally left out of the SPF specification, because they fall into the domain of local policy. Still, it helps when the majority of receivers operate with the same local policy. SPF deployments will find these extra features very useful, and any implementation that does not provide those features should strongly consider adding them.