On Sun, Nov 23, 2008 at 9:35 PM, Bart Schaefer
<schaefer(_at_)brasslantern(_dot_)com>wrote:
On Nov 23, 4:46pm, Al Iverson wrote:
}
} [Goodmail seems] to already have the whole per-message authenticated
} token thing worked out.. You buy the tokens, and once per message, a
} token is obtained from the token pool and applied to the message. That
} message gets special treatment at an ISP.
Yep. Hence my earlier analogy of sump pumps versus rubber rafts.
Messages in Goodmail's raft float above the flood, but it doesn't
reduce the amount of water.
In a closed, proprietary system, where the senders pay a fee to
Goodmail, which I assume is at least partially paid to the participating
ISP's. So essentially, the ISP's get paid for delivering what the
USPS calls "Bulk Business Mail"(BBM).
Now somebody needs to explain how the economics work. Pick whichever
framework you think is less burdensome and describe why you think an
ISP could extract enough value from it to actually bother building it.
Goodmail has already shown that tokens can work, and that the
economics can work. I think the question becomes, is the Goodmail
profit margin big enough that large ISP's would be interested in
transitioning
to an open, non-proprietary system where they can sell tokens to large
BBM senders directly (and keep Goodmail's cut of the action) ?
suggests a token pool like Goodmail's, but distributed among all the
recipients; everyone becomes their own little Goodmail, with an
auto-generated URL to contact the "imprinter" (to steal Goodmail's
name for it). I like my suggestion because it doesn't need any
"token pool" at all.
Excellent paraphrase of my idea. Adoption of an open standard
for token transport would allow recipients to continue using Goodmail
if they wanted, become their own "imprinter", or allow competing
service providers.
The same goes for SenderScoreCertified
and brandmailsolutions.com and all the other whitelisting schemes.
As long as it's cheaper to add rafts, no one will start pumping.
Can that go on forever? I don't know. It seems to me that the
current evolution of "e-mail" is going to closed systems, like "message
areas" in social networking sites.
} Also, I don't see how any sort of "Pay for email system" as (yet
} again) described on an anti-spam mailing list solves the issue that
} we all have to buy into your system before it'll work.
That's not true. Bart has it correct (notation below), it only takes two to
make it worthwhile for them with incremental benefit as more players
enter.
I say "almost" because as soon as any two cooperating entities get
on board, they've gotten at least as far as Goodmail has: email
between those two entities can float above the flood. A whole lot
more entities must be involved before the water starts to go down.
} And their system requires fewer fundamental changes to an ISP's
} backend than yours does.
Agreed again. On the other hand, that whole thing falls apart if
Goodmail doesn't succeed, and either way -- unless Goodmail manages
to convince everyone to pay them and becomes the universal solution,
so anything not processed by Goodmail can be outright rejected --
at the end there's still just as much spam as ever.
This time I disagree with both of you. My recommendation requires
three configuration changes and a franking script.
1. DNS entry for (TGHOST.domain.tld)
2. VHOST configuration on a (likely leveraged) web server for TGHOST
3. Franking script at TGURI
4. Token filter rule at MTA or MUA (depending on if ISP or end
user implementation)
It is true that in both cases, the sender has to pick a token and affix it,
so some program has to perform that function. I consider that the same
between systems.
The suggestion was to chop up the technical problem. Assume how the
money (or whatever) moves around is a black box, and instead describe
how to attach to an email the information about who moves it and how
much. OK, so I've described one way, and Gerald another.
End of that discussion unless somebody else is interested.
I have to admit that I find the idea of debiting a sender chargeback through
an
SMTP-extension to be an interesting idea. I don't currently understand
Bart's
intended process for sender authentication, and as we agreed, the money
movement should be viewed as "black box".
The reason I prefer a "token" system over an extension to MTA conversation
is that a token system can be implemented by a smart MUA without the
cooperation of their ISP.
Gerald
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg