On 9/17/07, Michael Kaplan <michaelkaplanasrg(_at_)gmail(_dot_)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.
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg