On Tue, 5 Jul 2005, Hector Santos wrote:
If SRS is important for SPF near or "complete" solution, then they should be
a consideration to make it official, not necessarily required part of SPF,
but submitted as a IETF draft in the same way SUBMITTER draft is used for
SENDERID/PRA draft.
Based on over a years experience implementing SPF both sending and
receiving, I would not recommend SRS to deal with forwarders configured
by receivers. (I use SRS to block bogus bounces, and just finished an SES
implementation which I am testing to replace it.)
Instead, I would recommend that receivers whitelist their forwarders
using the SPF record of the domain the forwarder sends from. Some
forwarders may not even know what this is, but it is the domain
they would use in MAIL FROM if they rewrite the MAIL FROM like they should.
MAIL FROM rewriting, including SRS, is most useful for web sites that
send mail on behalf of a user (e.g. greeting card sites). I.e., a sender
configured "forwarder". It is only needed if the web site wants to
pass any DSNs on to the user (not always a good idea).
Anyway, where can I get the "official" SRS specification so I can take
another look at it?
Currently, www.libsrs2.org has the original Perl reference implementation,
and a C library implementation.
I use pysrs at http://bmsi.com/python/pysrs.html
and the latest CVS (introducing SES) is on
http://sourceforge.net/projects/pymilter/
Note, that the "specification" is not needed for interoperability.
It avoids reinventing the wheel, and allows admins to swap implementations
smoothly. If you like reinventing the wheel and don't care if DSNs
don't get delivered for a few days when you try a new library, then
it doesn't much matter how you do the rewriting.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.