On Tue, 7 Dec 2004, David Woodhouse wrote:
On Tue, 2004-12-07 at 09:04 -0600, Daniel Taylor wrote:
BING! Give the man a cookie, he begins to get it!
You're missing the point. I said "your proposed solution". There are
other solutions to the problem, which _can_ tell the difference between
forged mail and valid mail which has undergone normal forwarding.
(IP connect reverse lookup to forwarding host.example.org)
MAIL FROM: host.example.com
OK, forged or not?
It could be a perfectly "valid" email really from A(_at_)example(_dot_)net
sent by the mail server at example.com and forwarded through
Or, it could be all be made up except for the part about this
hop originating from forwarder.example.org.
Since there is no way to tell how careful forwarder.example.org
is about accepting mail for forwarding, there is no way to tell.
THIS is why forgery-based forwarding is broken.
It is the type of forwarding that is indistinguishable from forgery
that is the only type effected by SPF.
SPF is trying to _stop_ people from effecting this kind of forwarding.
You seem to be particularly confused today.
SPF is trying to stop forgery.
If you forge MAIL FROM when forwarding e-mail you are engaging
Therefore, SPF prevents this type of forgery^H^H^H^Hwarding.
Contrary to your assertion here, I have yet to see a solution
to the forgery problem that combines the utility and usability
of SPF in one solution. The sorts of hack necessary to prevent
up front forgery while allowing forgery-based forwarding inherently
reduce the usability and transparency of the system.
Be specific. Perhaps when you've sobered up?
No need to be insulting you misbegotten sack of dung.
Daniel Taylor VP Operations Vocal Laboratories, Inc.