On Jan 29, 2008, at 10:34 PM, Alessandro Vesely wrote:
Hi all,
it is well known how SPF breaks forwarding. SPF is not itself an
anti-spam mechanism, but it would help cleaning up the mail
transport system by limiting domain abuse. If it were widely
employed, that is. Thus, this post is not off topic, although not
directly aimed at countering spam.
SPF's use of macros represents a serious security issue in itself.
This allows traffic to be generated from cached records triggered by
changes in a sender's email-address found within spam campaigns.
Processing SPF against unknown domains increases the magnitude of this
threat.
My tentative solution provides for a local forwarding policy. When a
message is being forwarded (i.e. it already has a Return-Path), the
mailer should look up the policy in order to determine what envelope
sender replacement, if any, it should use.
This reminds me of the Monty Python movie Jabberwocky central
character Dennis Cooper's suggestion "It would increase your
efficiency if you moved your box to here." It resulted in chaos. A
chain of hashed local-parts translated locally into an original return-
path address would need to include other elements of the message to
prevent abuse.
Another solution using this concept and not depending upon a dangerous
and unmanageable SPF path registration can be found here:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt
This allows the RFC 2821 MAIL FROM (return-path) to reference a Third-
Party Authorization against a specific domain in question. In this
case, it would be the signing domain. In essence, this strategy
overcomes the SPF forwarding issue and only require a single
transaction. SPF on the other hand might require orders of magnitude
more (which could also be new queries emanating from cached records).
It seems rather ironic SPF's intended purpose was to direct
culpability to the provider's customer (the email-address owner). By
limiting DKIM's delegation to being an exchange of keys, once again
the customer rather than the provider is again held culpable. The
exchange of DKIM keys, especially where a common key might sign for
thousands of different domains, creates a significant risk as well.
In addition, schemes directing culpability toward provider's customers
are in conflict with the general protection of personal privacy. Only
the provider should be able to determine a message source, and
therefore only the provider should be held responsible for controlling
abuse.
P.S.
While spam is increasing in volume, the life span of dedicated anti-
spam systems grow ever shorter, it seems pronouncements of "Mission
Accomplished" might be a bit premature. Nevertheless, it also
apparent those able to influence the structure of today's
communications are not interested in actually controlling abuse.
Rather interests are focused on deflecting complaints and establishing
elite services. In other words, the market's hidden hand ensures a
workable solution for controlling abuse remains unreachable. So close
the ASRG and cue the calliope, the circus rolls on. : )
Fatigue and "market" forces rather than accomplishment might be an
epitaph for waning interest in ASRG. At least John Levine's
contributions to this noble cause can still be found elsewhere.
Although we may not always agree about what is possible, practical, or
politically wise, John's perspective is always well worth
consideration. Thanks John.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg