On Jan 31, 2008, at 3:00 AM, Alessandro Vesely wrote:
Douglas Otis wrote:
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.
Still, from the limited point of view of running my own MTA, I find
SPF checks cheaper than content filtering and verifying signatures,
as the latter can only be done after the message body has been
received. DNSBLs work much like it, but are one order of magnitude
more efficient, for the time being.
DDoS attack damages may run into the millions per event. The concept
of "cheaper" should be weight against this _very_ serious risk.
Content filter is doomed, as bad actors always have the advantage.
Something like CSV is far safer and likely just as effective.
Adopting RFC 3464 would help with DSN as well, especially where
original message content is redacted.
That looks exactly like the kind of criticism I have been looking
for, thanks! However, I don't think I've got it quite rightly
(perhaps because I missed the movie.) I imagine a local forwarding
policy as a database keyed on <forwarder, envelope recipient> pairs;
where "forwarder" is either the IP address or its FQDN, provided it
got an SPF "pass".
Expecting a pass will be problematic. A translation process will need
to qualify DSNs, not the message being forwarded. BATV is an example
of how this might be done, but this imposes a requirement that the
domain's email uses a common Return Path protection strategy. That,
in it self, can be a problem.
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.
The spammer probably won't sign its return-path. A forwarder
advertising the ability to sign its return-paths could get
authorizations more easily, though.
The concept was to improve the integrity of email's delivery process
that is currently suffering due to a high loss of DSNs. DKIM in
conjunction with TPA-SSP would allow signatures to be associated with
the desired RFC 2821 MailFrom. TPA-SSP allows this association to be
made autonomously by just email-domain owner. DKIM key exchanges
would be far more complex, costly, and risky.
It seems rather ironic SPF's intended purpose was to direct
culpability to the provider's customer (the email-address owner).
I don't want to delve into the discussion you had with Frank while I
was sleeping. I just want to note that provider and customer must
trust each other.
Agreed. But trusted implies specific expectations as well.
Using DKIM, a provider might sign email with a domain of
"authenicated.provider.com" where any of their
"authenticated" (control of the associated mailbox has been verified
for example), could then autonomously use TPA-SSP to specifically
authorize "authenicated.provider.com". The provider could sign all
their customers using a common signature, and apply the same criteria
for all those permitted to access that specific domain. The
provider's own domain might authorize both
"authenticated.provider.com" "not-authenticated.provider.com" and
select the signing domain based upon the "authentication" status of
the message.
Fatigue and "market" forces rather than accomplishment might be an
epitaph for waning interest in ASRG.
We'll never have a better world if we don't try and design it...
Agreed. But there are also market forces that stand in the way of a
good design.
At least John Levine's contributions to this noble cause can still
be found elsewhere.
Any specific pointer? I just read some of his posts on the CircleId.
Here is one.
http://mipassoc.org/batv/draft-levine-batv-03.txt
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg