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