Subject: re: [ietf-dkim] the more reliable signature fallacy

From: [email-masked]
Date: Thu, 24 Jan 2008 09:40:16 -0500

John L wrote:

>> This is the exact problem for PRA in the SIDF implementation.

> Quite right.  What would be the point in inventing yet another
> authentication scheme that fails in all the same places that
> SIDF and SPF do?

This constant barrage of ANTI-SSP rhetoric masked as ANTI-SPF rhetoric has
become redundantly tiresome.

--
Sincerely,

Hector Santos, CTO
http://www.santronics.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked]
Date: Thu, 24 Jan 2008 10:06:40 -0500

>> Wietse Venema wrote:
>>
>> Or is it?
>>
>> If all SSP were doing was to re-invent SPF at a
>> different OSI layer, then no progress would be
>> made; we would only squander the opportunity for
>> better accountability that DKIM makes possible.

> Michael Thomas Responded:
>
> Maybe. But maybe not. With SPF you had the lure of doing all of
> your work at the 2821 layer. That is, reject things before you've
> read the message. With SSP you have to read the message so you
> might as well run SSP and the rest of your filtering and just
> incorporate SSP as *one* datapoint of potentially many to
> determine the delivery disposition. This seems a lot more
> sensible and prudent to me as you're not elevating SSP to Silver
> Bullet status which is always suspect.

Side point: SENDERID is a 2822 based version of SPF.

Ideally, you want SPF to remain at 2821 to avoid the potential Bounce
Attack problems. If you collect the DATA and perform a consolidated
filtering before responding to the DATA command, then there a risk of a
high payload DoS attack.  So you want as much filtering as possible at 2821
before reading the payload.

But sure, SSP is a 2822 technology as well as SENDERID, so these would need
to be performed once the payload is obtained, if it gets to that state.

--
Sincerely,

Hector Santos, CTO