Re: [Asrg] Receiver Initiated Authentication

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.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related ietf.org Links asrg imrg Request more information about Pantek

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