Re: [Asrg] Receiver Initiated Authentication

It does seem to combine most of the worst anti-spam ideas of the past
> decade - it's got challenge-response,

Section 12 details how this system is orders of magnitude better than C/R

it's got "have to install new
> software in all MUAs to make it not suck"

Even without a very simple (section 5.2) upgrade to MUAs the system will be unseen by almost every legitimate sender.

, it's got graphical
> captchas in auto responses,

As referenced at the top of section six this will likely only be sent bulk senders with less-than-ideal sending practices. Other senders whose domains are under spammer control will also be receive graphical CAPTCHA (I guess it depends on how much sympathy you have for a compromised sender with a server sending a thousand ham a day along with a million spam).

it's got "each correspondent should use a
> different tagged address"

They should, but they certainly don't have to. How is this a problem

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's got "you have to be able to read HTML
> email to make the captchas work".

Again, this only applies to an extremely small segment of senders with poor reputations. It's 2007, most clients can handle this.

> 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.

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).

No, you don't whitelist the IP. You add the IP and the sending domain from the resent bounce (the resent bounce has authenticated the domain) into a database. This database works just like SPF. Let us assume that the sender now emails a a third party. This third party can look at the sender's domain and sending IP. The third party then accesses this new database and is able to authenticate the sender. The sender only had to resend one bounce, and now the entire world can authenticate every future email sent from the senders domain via that IP.

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.

Clients will only need a one time update, and they don't even need that. The bounce from Figure three is only sent to senders that despite authentication are still suspicious, but yes - the client will need to be able to display images.

It seems that it will send unwanted email to strangers.

Do you need more 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

Section 9

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.

I used sub-addresses is completely unique way. A non-compromised sub-address will effectively guarantee successful delivery of ham. I'm not entirely sure what aspect of my use of sub-addresses you are concerned about.

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.

It uses the same principle as SPF (a database connecting domains to sending MTAs) but yes, it is not literally SPF since only the administrators of the sending domains generate the real SPF database.

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.

Legitamate bulk email senders who maintain good reputations will continue to have their email delivered directly to the inbox. This system will actually enhance delivery of legitimate bulk email; current filters simply junk much of the email from these senders, but my system will allow for their delivery (see section 12 item 3 and the related info in that section to see how RIA will perform in comparison to convention filtering).

Thank you for your feedback,

Can we help you?
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

Michael