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
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html