With permission, I'll repost most of Stuart's comments back to the
list where original post came from, my comments below are for
On Wed, 24 Jan 2007, Stuart D. Gathman wrote:
On Wed, 24 Jan 2007, william(at)elan.net wrote:
What's the current status of the SRS efforts? Are any of the big sites
signed up to do it?
SRS is not actually needed except as a work around for recipients
that don't provide whitelisting. (e.g. you want to forward mail to your
A lot of recipients are unable (for various reasons) to setup
per-receipent whitelisting or per-receipient SPF checking
(i.e. site does SPF checking for all incoming email for all users).
My view is that they probably should not forward to account
like this, but lets be clear - SPF does break forwarding and
nobody is disputing it, the question is more often if its a
good thing or not.
Ideally, a forwarder would have an SPF record for their domain, and
their recipients would list that domain in trusted forwarders.
Listing all forwarders in central repository is against practice of
decentralization of email system. Wayne who set it up can correct
me but my understanding is that its always been only a temporary
thing and only for few largest and most used forwarders.
Incoming mail from that domain (according to the SPF record *regardless*
of MAIL FROM) should not be SPF checked. Hopefully, the forwarder does
If a forwarder uses SRS, then all forwarded mail will pass SPF, and
appear to come from the forwarder. However, if the recipient tracks
reputation, by IP or domain, then any spam forwarded may result in the
forwarder getting blocked.
With or without SPF, forwarding is dangerous without some kind of
whitelisting arrangement with the recipient. A real life example
that I have had to deal with many times is a user that forwards
their mailbox to an AOL account "because the spam filter is easier".
Then, they begin flagging forwarded mail as "spam" (including memos from their
own office they'd rather not deal with). Soon, everyone at their
company is blocked from sending to AOL.
It seems like a good idea to me, but then I found the FAQ at:
But don't worry, we're working on providing SRS
patches for the four major opensource MTAs, so that
when you upgrade to an SPF-aware version, this
problem will be solved also.
This has been going on long enough that I'd expect code to be available by
now, but maybe my clock is off.
I have updated that FAQ (which was quick and dirty translated during the
SRS is actually more useful as a variation on BATV to reject bounces of
your forged domain.
Lets call it appropriately as its BATV that came as variation of
SES which came out of work on SRS. For SPF Community it would be
good to release their own documents/text-draft that describes
SES close to its original concept (without RFC2822 additions
and only done as encrypted MAIL FROM with optional dns server
to answer if the crypted id is ok or not) and work on the
implimentations to be listed on the website. Same goes for SRS
as there is no good (recent/updated) text standard either.
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735