On Sep 16, 2007, at 4:58 PM, Michael Kaplan wrote:
I propose a method of rapidly achieving a near comprehensive SPF
database. The core of this concept is that questionable
unauthenticated email will be bounced; the return of this bounce
authenticates the domain. This domain and the MTA listed in the
return path of the resent bounce is now entered into a shared
database. All future emails from this previously unauthenticated
domain sent via this MTA will now be authenticated after consulting
this newly established database.
Existing SPF cannot authenticate forwarded email. My proposal
employees multiple mechanisms to transparently overcome this other
major flaw with SPF so that even forwarded email is authenticated.
Existing authentication schemes are dependent on the participation
of the senders of email. My proposal allows for the receiver to
initiate the process of authentication. I therefore call this
proposal Receiver Initiated Authentication (RIA). The process is
detailed at:
http://spamfizzle.com
It does seem to combine most of the worst anti-spam ideas of the past
decade - it's got challenge-response, it's got "have to install new
software in all MUAs to make it not suck", it's got graphical
captchas in auto responses, it's got "each correspondent should use a
different tagged address", it's got "you have to be able to read HTML
email to make the captchas work".
The end result doesn't look as bad as you'd expect from combining all
those things. There's not requirement to use a web browser (just a
mail client that can handle html, images and possibly forms).
I argue that RIA will authenticate all questionable incoming
email. Innocent third parties will be relatively unaffected by
erroneous bounces. I also demonstrate how RIA is orders of
magnitude superior to C/R.
That's a big claim.
It looks like the core of your approach is this:
1. If Spamassassin (or whatever tech) thinks the inbound mail to a
tagged address is spam, permanently disable that tagged address and
send a challenge-response to the From address, including a newly
generated tagged address. Similarly for mail sent to a non-tagged
address.
2. If the sender responds to the challenge, whitelist the IP
address / domain combination. (Your description of this is very
confusing, and seems to be badly misusing the term SPF to refer to
something completely unrelated, so I may be missing something there).
3. Install software in all end users MUAs to automatically intercept
inbound challenges and respond to them.
4. For some domains ("suspicious domains") use a different approach,
incompatible with the universally distributed software in (3) and
require the recipient to manually resend the message, after answering
a graphical captcha embedded in the challenge. This will require an
MUA to handle HTML and render images within the client.
It seems that it will send unwanted email to strangers. It also seems
to be more concerned with spam than with handling mail you actually
want to receive. For example, the usual use of a tagged email address
is to allow some entity to send you mail and avoid a lot of your
normal content-based filters as only legitimate mail is expected to
be sent to that tagged address. Terminating a compromised tagged
address is something that'll happen very rarely, while having content
that may trigger a content based filter sent to that tagged address
may be fairly common in some cases. Your approach seems to consider
only the rare case of a compromised tagged address, not the common
case of a non-compromised tagged address.
Your use of the terms "SPF" and "bounce" in your description seem to
differ widely from accepted usage, so you may want to clean up some
of the descriptions if you're looking for broader feedback. You'll
also want to discuss why you believe this will not impact legitimate
bulk email, such as mailing lists, as that's not clear from your
current discussion.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg