"Michael Kaplan" <mkaplansolution(_at_)lycos(_dot_)com> wrote:
Innocent people will be sent bounces at maybe 0.1% of the frequency
they will be sent spam,
That is, you're increasing my spam load. Why should you be treated
differently from anybody else who increases my spam load?
If the only way the C/R part is implemented is rejecting rather than
sending a challenge, then that's fine with me (though some senders
will be unable to handle it).
I envision my system as being ideal for the typical large consumer
ISP user.
Is that because you think the "typical large consumer ISP" is too big
to block? They aren't.
No innocent user will ever get an erroneous bounce if a few of the
large consumer ISP adopt the system;
Explain how I will never get an erroneous bounce if someone else
adopts the system, and a spammer forges my email address as a sender.
If your first checking pass will always reject the spam and not send
me the challenge, then you never need to send challenges. Or do you
merely mean that other users of the system will never see those
bounces, because the system will somehow reply automatically? (Note
that there's no way to tell whether a message was legitimately sent if
the user forges his own email address when using a different
mailserver.)
Oh, another issue: What return address will the challenge use? If it
doesn't use that of the recipient, then whitelisting systems (that
automatically list addresses they send to) will never see it. If it
does, a nasty person can send a message with a Reply-To of a mailing
list that the recipient is subscribed to.
If anything I am merely suffering from a severe lack of insight as I
am still unable to appreciate why the residual flaws are severe
enough to disregard a proposed system that could theoretically
conveniently eliminate spam for so many consumer level email users.
Eliminating spam for someone else at the cost of increasing it for me
is not an acceptable tradeoff, and I will take action to ensure that
the costs of implementing such a system rebound to the dis-benefit of
the implementer.
Seth
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg