Hi Doug,
We've had last call on the requirements document. You seem to
me to be repeating a request that wasn't accepted, but I've
yet to track back the issue tracker to check that. I hope I
don't need to.
Our next step with the SSP requirements document is to push
it to the IESG (on Barry's to-do list I believe).
Stephen.
Douglas Otis wrote:
On May 23, 2007, at 8:07 AM, Stephen Farrell wrote:
Now we need to get SSP done.
An area not well addresses by the current SSP requirement is however
extremely important to the typical high volume email sender-
Ensuring the SMTP client obtains a reputation based upon a DKIM domain.
While DKIM signatures assure content, these signatures in many cases
will be unable to convey an assurance the SMTP client is associated with
the DKIM domain. In such cases, replay abuse may inhibit reliance upon
the DKIM signature as a basis of acceptance.
Unless the industry adopts a convention where SMTP clients ensure
host-names are within the DKIM signature domain, providing an
alternative scheme for this association may prove extremely helpful.
There should be grave concerns with respect to utilizing SPF as a means
for providing this function. The local-macro expansion feature of this
script-like scheme enables a _resource-free_ means to stage a DoS attack
while spamming! The many operations required to acquire SPF record sets
also makes this approach extremely dangerous in general, as this can
lead to _very_ high amplifications. Dissuading use of dangerous
existing libraries acquiring SPF records may actually require use of
+all, where only CIDR constructs are used for white-listing purposes.
SSP can provide a much safer and lower overhead alternative for
associating signatures with the SMTP client. The DKIM signing domain
would only need to publish a record with a hashed prefix of authorized
SMTP clients. These records at such locations ensure the DKIM signature
is not being replayed abusively. This would permit a simple means to
convey the reputation of the DKIM signature upon the SMTP client and
related IP address.
This can be done by using a convention hashing only upper labels of the
SMTP client host-name as a basis for this authorization. This would
then permit any host-name within this domain to be associated with the
DKIM signature. This would involve a _single_ query where either the
SMTP client is associated using this technique, or not. This would then
permit more stringent policies which may wish to differentiate those
SMTP clients not associated with the DKIM signature either directly or
indirectly using such an authorization scheme.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html