› Home › Overview › Status › Download › Documentation › Support › FAQ
Validate the XHTML and CSS of this page.

Should I implement SRS?

Yes, if you are forwarding mail from one domain to another. If you do not implement SRS, then there is a risk that the receiving domain will reject your mail according to the SPF policy of the original sender. See Meng Wong's page on SRS for more details.

Should I implement SPF?

Yes. An SPF implementation is available from http://www.libspf2.org/.

What if I don't use SPF?

A lot of other people do. Furthermore, a lot of other people use ad-hoc SPF-like systems which aren't actually SPF. SRS has been designed to permit all of these source-checking schemes to operate correctly. You should use SRS if you forward email.

What about performance or overhead?

libsrs2 is extremely high performance and should not introduce any measurable CPU or memory overhead into your mail system. Simple tests on a desktop PC indicate that libsrs2 can perform nearly over 800 million forwards per hour, or 4 microseconds per forward. This level of overhead should be acceptable for anyone.

Do you support my MTA?

See the MTA patches section in the download page. If we do not yet support your MTA, please send a patch to srs [ta] anarres.org.

Do you support my operating system?

libsrs2 uses GNU autoconf and is known to compile on BSD, Linux, Solaris, OS/X and Windows. If it does not compile on your operating system, please send error messages or a patch to srs [ta] anarres.org.

What are the requirements for SRS?

No external libraries are required. The cryptography is now performed internally, and so the requirement for openssl has been removed.

Can I use libsrs2 in my [commercial] product?

Probably. libsrs2 is released under the union of the GPL version 2 and the BSD licenses. You may choose which license to use with this software. If neither of these licenses is adequate for your needs, plesae contact Shevek at srs [ta] anarres.org to ask for alternative licensing terms and support.

Is libsrs2 compatible with other SRS implementations?

The purpose of compatibility between implementations is to permit a system administrator to replace his MTA or SRS implementation without invalidating any currently valid SRS addresses temporarily stored on remote systems. The SRS standard requires that all implementations output the same rewritten address given the same input. The Mail::SRS Perl implementation is the reference implementation of SRS and should be used as a basis for testing.

libsrs2 is fully compliant with the Mail::SRS reference implementation. and includes a testsuite for checking compatibility against Mail::SRS. The use of this testsuite is described on the documentation page. There are some implementations which are known not to be strictly compliant with the standard; the use of these implementations is not recommended.

What about the 64 character limit on local-part?

Several other mailing list systems, such as VERP, have been using local-parts greater than 64 characters for several years with minimal impact. This limit is not currently a problem and should be removed in a future RFC. The systems known to enforce this limit are listed here: