>> 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
