On Wed, 2004-11-10 at 08:45, Meng Weng Wong wrote:
fair enough; i'm going to define the whole product as
SPF+SES+SRS+DK and work to get that into MTAs and distributions.
Cool.
I'm guessing that this SPF+SES+SRS+DK would imply per-user whitelisting.
That redefinition reinforces the potential of a viable Plan C, which is
merely a slight marketing repositioning of requirements and suggestions,
(admittedly in a way that's been said before):
Plan C: Senders publish SPF records.
Receivers who check SPF do SRS and allow per-user whitelisting.
Plan C implications:
If your forwarders check SPF, you won't have to whitelist them.
If your Sending ISP does SES, your messages will pass SPF tests
even after being forwarded.
Plan C doesn't *require* the forwarder to do anything, rather it only
requires people who do checks to do a bit more than checking--and if the
technical ability to do the checking implies the technical ability to do
a bit more, it's not a big deal since you're already making those types
of checks and changes.
It's just a slight marketing shift that means we won't seem to be as
antagonistic towards forwarders as we seem now with the comparative
"forwarders must do SRS" position, or antagonistic towards Senders with
any sort of "if you publish SPF, you had better be doing SES also, or
else" position. (I admit I'm wording those positions in an antagonistic
way.)
Since forwarders are going to want to do SPF checks anyway, as they do
so, they'll tend to be doing SRS of their own accord.
As far as SES goes, although this wording doesn't *require* SES, it just
shows that things work better with SES--and doesn't step on the toes of,
but would merely reinforce, any SES-oriented marketing or promotion.
So all parties have reasons to implement different things for the
advantages it gives them, with less of a feel of being browbeaten into
it.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com