So, I'm not sure how whitelisting is supposed to work in an SRS world, at least using the envelope sender, which is what SPF is supposed to protect. I'm guessing the final answer is for SPF to protect the "From:" header too, and then use that for whitelisting purposes. I get the impression that's what might come out of the SPF/Microsoft-caller-id merge, judging by whipping through some presentations on caller id integration?
Perhaps this is the answer:
If a forwarder implements SRS, then they probably implement SPF too. In this case, any emails you receive from an SRS encoded address have hopefully been SPF checked and hence aren't spam.
So, simply accept any email from an SRS encoded address...
This can be implemented in TMDA today. Of course, you wouldn't be able to challenge people based on other local policy, but the likelihood of spam is much lower, so you probably don't need to.
Now, spammers could abuse this by sending email from an SRS encoded address (which could still pass your hosts SPF checks, since that only checks the domain part). In this case, you'd have to make your MTA, or some filter script, or TMDA, only accept SRS encoded from addresses from known trusted forwarders (i.e. have a list of domains which you've setup a forwarding account at).
I'm not sure how you'd implement this today. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
