On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote:
|
| This is going to be _entirely_ counterproductive in the long run. If you
| want true authentication, implement a true end-to-end scheme rather than
| a hop-by-hop scheme which cannot ever solve the problem. MARID has its
| place but this is _not_ it.
|
I plan to implement DomainKeys as soon as a plugin is
available for my MTA. Have you implemented it yet?
| We need to stop disingenuously selling SPF/SenderID as a real
| authentication scheme. Those who sell it like this are doing us _all_ a
| disservice because they're going to severely hurt adoption of whatever
| true authentication scheme is settled upon by those groups who are
| working on it as we speak.
|
| As for selling SPF as a method to stop bounces -- that's just bizarre.
| BATV/SES are a totally effective way of doing that, without requiring
| _anything_ of third parties for the 'publisher' to get the benefit.
I will try to clarify an important misunderstanding.
SPF Classic targets the practice of return-path spoofing.
The immediate benefit to publishers is that they will begin
to get fewer bounces.
But that is not the only benefit.
The total benefit is that return-path spoofing will be
reduced.
Part of the harm of return-path spoofing is that
undeliverable addresses generate cause bogus bounces.
But another part of the harm of return-path spoofing is that
deliverable addresses receive forgeries. A bounce may not
get generated, but harm is still done.
I agree that BATV/SES are the best solution to the
stop-bogus-bounces problem, better than SPF Classic because
they can be implemented unilaterally. The cost is only
slightly higher than SPF Classic: both require domains to
corral all their users into using the domain's approved
servers. In addition, BATV/SES sign outbound return-paths.
However, BATV/SES only limit the harm from the fraction of
the mail that does bounce. It does not address the fraction
of the mail that is delivered. SPF Classic and Sender ID do.
Therefore, the benefit of SPF Classic goes beyond reducing
bounces. Likewise, the purported benefit of Sender ID
addresses phishing, which for whatever reason is not being
addressed by true end-to-end methods today.
When banks start DomainKeys or S/MIME signing all outbound
mail, I promise to give up SPF and Sender ID. If you want
me to stop campaigning for SPF and Sender ID, I suggest you
focus your energies on the dependency.
To reiterate my position: if you believe you have the One
True Solution, please go and help make it happen. If you
believe that someone else's One True Solution is wrong, it
is more productive in the long run to work on your solution
than attack somebody else's.
Mathemeticians stand on each other's shoulders.
Computer scientists stand on each other's feet.
-- originally Richard Hamming, I think.