From: Meng Weng Wong
Sent: Tuesday, November 09, 2004 1:16 PM
On Tue, Nov 09, 2004 at 07:13:47PM +0100, David wrote:
|
| I also think SES provides better solution to the forwarding problem than
| SRS. It could work alone and, if ses modifiers are published in spf
| records and understood by SPF implementations it will be even better.
| I also have no idea why people are still working on or promoting srs.
The reason I'm promoting SRS, flawed though it is, is
because it's less total work.
This is something that reasonable people can disagree on.
Plan A: Senders publish SPF records. Forwarders do SRS.
Plan B: Senders publish SPF records and do SES. Forwarders
do nothing.
While plan B is more elegant, my intuition tells me that the
total work in plan A is less.
Work under A: (Senders*SPF + Forwarders*SRS)
Work under B: (Senders*(SPF+SES) + Forwarders*0)
It is my opinion that A < B. Others may, of course, disagree.
Here's why I see this one differently: it's not an apples-to-apples
comparison. Senders are also recipients, and want end-to-end validation and
forged bounce protection. SPF+SRS doesn't have those properties but SPF+SES
does.
They could wait for DK, but they still don't get forged bounce protection,
so they need to implement something else for that. Then the solution looks
like SPF+BATV+DK or SPF+SES+DK. That's a lot of work, and gives the
implementer no better authentication than SPF+SES alone.
SPF can work very well with crypto schemes, especially they make explicit
provisions for it, as SES does, because SPF can short-circuit the crypto
evaluation for single-hop message delivery. This is the majority of
incoming messages.
--
Seth Goodman