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