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.
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.
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".
The receiving MTA already has a database of recipients, and deploying this
technique is going to multiply that by a number of forwarders. Likewise,
the sending MTA must have a similar database, and a forwarding directive
attached to the address that triggered the relay. That looks manageable to
me, if not flooded by spammers.
A spammer can pretend to forward a message. If the receiving MTA does not
limit which hosts can receive an authorization for being whitelisted, the
spammer can succeed. That is not much different than directly sending the
spam, except that it adds one record to the local policy. If the receiving
MTA can determine that the spammer is spamming directly rather than
relying spam, then it may put a blacklist flag on that record, thereby
nullifying the spammer's attempt to set up an acknowledged relay. However,
it is not easy for the receiving MTA to make that determination. Is that
the abuse problem you mean?
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.
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.
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...
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg