Re: [Asrg] Re: Receiver Initiated Authentication

On 9/17/07, Michael Kaplan <michaelkaplanasrg@gmail.com> wrote:
> >
> > I am concerned about forwarded email. Once the Receiver Generated SPF
> > database is established then most of the unauthenticated ham will come
> via
> > forwarders who already accepted the original email. I'm open to any
> > suggestions on how to work around this, otherwise I still argue that
> highly
> > selective bounces are only mildly evil.
>
> Quarantine (or soft-fail) and query the recipient. Parse the headers in
> the
> forwarded message; if a spf-good appears earlier, offer the addressee the
> option of whitelisting the final relay.

It is good if addressees whitelisted the final relay; this would be good for all mail systems, not just RIA. If, however, mail comes via an forwarder than does not have an established reputation then I would bounce the email. If you don't then you will need to constantly expose the receiver to unauthenticated spam; RIA is supposed to make the sending of unauthenticated spam absolutely futile. Receipt of the resent bounce will prove the legitimacy of the original forwarding server so now the addressee can have this forwarding server automatically whitelisted.

The addressee has signed up for the
> protection, knowing there may be a touch of configuration. Integrate with
> reputation systems (and refer to documentation strongly suggesting using
> a SPF-compliant RFC 821 "SRS" envelope instead of a simplified one) in
> the 450 rejection) and statistical analysis in deciding how to dispose of
> such messages.

RIA will do all of this, but at the end of it a very small amount of unauthenticated 'unsure' email will remain and require bouncing.

As this is a research group, it's good to see new proposals like
> yours. Your proposal, like a few others, revolves around
> Challenge/Response. Once we start meddling with bounces, we make
> that feature even more unreliable.
>

I argue that this is an excellent way to use bounces (even if a small number are misdirected). I'm not sure what "unreliable" refers to

Near universal distribution of Auto-Resend software is not as easy as
> it sounds. If you cannot get the administrators to update their
> systems, then you won't get hundred times more people upgrading their
> software. The cost will be much more if you upgrade the client software.
>

Section 5.2 outlines how surprisingly simple it is to distribute Auto-Resend to most of the population, and the last bullet point of section 11 details how unnecessary Auto-Resend is. A routine Windows Update patch would take care of most of the Outlooks out there.
With passage of enough time people will inevitably upgrade their computers and software, thus gradual near-perfect of Auto-Resend is inevitable. Contrast this to the current SPF database; in 10 years it will still be woefully incomplete.

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

CAPTCHA has been circumvented. Getting users to a website to solve a
> CAPTCHA is not that difficult. If spammers did not get more than an
> insignificant number of people to visit their website, they would not
> have been in business.
>

 Section 6.2 details how CAPTCHA, as used by RIA, cannot be circumvented. A CAPTCHA guarding against web page registrations needs to be a thousand times more secure than a CAPTCHA that requires an non-spoofed email for every attempt at solving it.

CAPTCHA also has usability issues.
>

If RIA got rid of the CAPTCHA altogether then it would still be a system that would generate a near perfect SPF record and authenticate all questionable email. The purpose of the CAPTCHA is to challenge the extremely small number of emails that are 'unsure' despite authentication (see reference #1); again most of the unsure authenticated ham will come from bulk senders or senders with spambot compromised systems. The CAPTCHA, directed at this small population of senders, is needed to make the sending of spam completely futile. The CAPTCHA is only tolerable as so few legitamate senders will ever see it; answering the CAPTCHA will improve you reputation and help get you off of the suspicious list so in the future your emails won't bounce.

A Single Universal Receiver Generated SPF Database is like having a
> single worldwide authority responsible for email. This raises
> questions about control and cost.
>

This database will be based on preexisting proposals for a shared universal reputation system (Reference 13).

I suggest that you don't underestimate the technical prowless of spammers.
>

In section 7 I theorize a mechanism of spammer circumvention and how to neutralize it. If anyone else can think of how spammers can bypass this system then please let me know.

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

Regards,
> -sm
>

I can't help thinking that spammers will have a field day spamming
> themselves with forged, say, @hotmail.com, doing the captchas to
> "approve" bogus IPs, and then firehosing the world with what would now
> verify. The Nigerian 419 hordes would have fun.

I'm not sure what it is you are describing. Hotmail addresses cannot be spoofed as Hotmail has an SPF record. How would spammers control email accounts that are used by participants of RIA? (Other than what I describe in section 7). The Receiver Generated SPF database would be created by the information generated from trusted email accounts such as those held by AOL, Earthlink, Verizon, corporate customers, established trusted users of Hotmail and Gmail (someone who signed up for a webmail account 5 minutes ago probably won't be considered a trusted webmail user), etc. How is a 419 scammer going to corrupt the database (other than as described in section 7)?

Frankly, also, much as I'm not fond of SPF, I'd object to having our SPF
> policy subverted to lend additional credibility to entities that aren't
> under _our_ control.

This is not a policy; the Receiver Generated SPF database is a private database generated by all willing participants of RIA. I'd love to think that every major email entity would participate.

Thank you,
Michael