|
»
Passive Spam Revocation
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
Passive Spam Revocation
by Yao Ziyuan
::
Rate this Message:
Passive Spam Revocation (PSR)
Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam filter, which can drop good and important messages. I propose an optional feature for current mail systems. The main idea is if a message is considered spam, this spam status can be tracked by the sender (but not sent to him directly, as the From field can be faked). The message can be re-marked as "not spam" if the sender can solve a CAPTCHA. STEP 1: A is going to send B a message. A's mail client generates a random code and puts it in a custom field in the outgoing message's header: PSR-Code: <random code> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code> This page displays one of these possible "spam statuses": * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) * MESSAGE CONSIDERED NOT SPAM. * PENDING. PLEASE TRY AGAIN LATER. * All other responses mean B's mail system doesn't support this feature. In the first case, A's mail client will report the status and the CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message is not spam. Like the idea? Here is the official Google group for it: http://groups.google.com/group/passive-spam-revocation Regards, Yao Ziyuan http://sites.google.com/site/yaoziyuan/ _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Ale2008
::
Rate this Message:
Yao Ziyuan wrote:
> I propose an optional feature for current mail systems. The main idea > is if a message is considered spam, this spam status can be tracked by > the sender (but not sent to him directly, as the From field can be > faked). The message can be re-marked as "not spam" if the sender can > solve a CAPTCHA. The mailing system described below is equivalent to direct-to-MX mailing, except for the fact that the message is pre-fetched via regular SMTP, which may be regarded as a compatibility hack. In facts, the client connects directly to the recipient's server in order to formalize the submission. Direct-to-MX delivery has been discussed previously on this list. Bill pointed out that funneling email through MSA systems run by providers had been conceived for the very purpose of authenticating authors and introduce domain-level accountability. See http://www.ietf.org/mail-archive/web/asrg/current/msg15593.html Allowing direct-to-MX delivery is likely to introduce more spam. The requirement of human interaction would only raise the entry level for leveraging such opportunity. CAPTCHAs can be solved by low cost personnel, as it is currently done, e.g., by http://decaptcher.com/ at 0.002 USD per solved CAPTCHA. Although those micro-payments might be considered similar to e-postage, that money would flow toward the wrong ranks. In addition, letting senders monitor whether their messages have been marked as spam may turn out to be an advantage for those senders who can tweak their messages until they cannot be discerned. That's the reason why several servers drop spam rather than rejecting it. Finally, if widely adopted, PSR would hinder any form of mass mailing, even legit. > STEP 1: A is going to send B a message. A's mail client generates a > random code and puts it in a custom field in the outgoing message's > header: > PSR-Code: <random code> > STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: > https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code> > This page displays one of these possible "spam statuses": > * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) > * MESSAGE CONSIDERED NOT SPAM. > * PENDING. PLEASE TRY AGAIN LATER. > * All other responses mean B's mail system doesn't support this feature. > In the first case, A's mail client will report the status and the > CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message > is not spam. _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Claudio Telmon
::
Rate this Message:
Yao Ziyuan wrote:
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: > https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code> > This page displays one of these possible "spam statuses": > * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) > * MESSAGE CONSIDERED NOT SPAM. A possibile problem is that a spammer can send a few test messages, check which one is not considered spam and flood with the same kind of message for a while, then check again and change format if required, thus increasing spam effectiveness. It doesn't need to solve the captcha for this. -- Claudio Telmon claudio@... http://www.telmon.org _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Yao Ziyuan
::
Rate this Message:
On Mon, Oct 26, 2009 at 12:45 PM, Yao Ziyuan <yaoziyuan@...> wrote:
> Passive Spam Revocation (PSR) > > Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam > filter, which can drop good and important messages. > > I propose an optional feature for current mail systems. The main idea > is if a message is considered spam, this spam status can be tracked by > the sender (but not sent to him directly, as the From field can be > faked). The message can be re-marked as "not spam" if the sender can > solve a CAPTCHA. > > STEP 1: A is going to send B a message. A's mail client generates a > random code and puts it in a custom field in the outgoing message's > header: > PSR-Code: <random code> > STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: > https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code> > This page displays one of these possible "spam statuses": > * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) > * MESSAGE CONSIDERED NOT SPAM. > * PENDING. PLEASE TRY AGAIN LATER. > * All other responses mean B's mail system doesn't support this feature. > In the first case, A's mail client will report the status and the > CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message > is not spam. Showing a message's spam status to the sender can be bad, if he is really a spammer. So the page can also return: * SPAM STATUS HIDDEN. (A CAPTCHA is also presented below.) This means the sender can solve the CAPTCHA to see the status and change it to NOT SPAM. > > Like the idea? Here is the official Google group for it: > http://groups.google.com/group/passive-spam-revocation > > Regards, > Yao Ziyuan > http://sites.google.com/site/yaoziyuan/ > _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Rich Kulawiec
::
Rate this Message:
On Mon, Oct 26, 2009 at 12:45:12PM +0800, Yao Ziyuan wrote:
> The main idea is if a message is considered spam, this spam status > can be tracked by the sender (but not sent to him directly, as the From > field can be faked). Providing useful intelligence about (a particular site's) spam filters to spammers is a seriously bad idea. ---Rsk _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Jose-Marcio Martins da Cruz-3
::
Rate this Message:
Rich Kulawiec wrote:
> On Mon, Oct 26, 2009 at 12:45:12PM +0800, Yao Ziyuan wrote: >> The main idea is if a message is considered spam, this spam status >> can be tracked by the sender (but not sent to him directly, as the From >> field can be faked). > > Providing useful intelligence about (a particular site's) spam filters > to spammers is a seriously bad idea. On the other hand, consider valid the hypothesis that spammers don't know what kind of filter is being used (by some particular site) is also a bad idea. JM -- _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Claudio Telmon
::
Rate this Message:
Yao Ziyuan wrote:
> Showing a message's spam status to the sender can be bad, if he is > really a spammer. So the page can also return: > * SPAM STATUS HIDDEN. (A CAPTCHA is also presented below.) > This means the sender can solve the CAPTCHA to see the status and > change it to NOT SPAM. This would solve the problem of spammers testing the filters without solving the captchas. However, any automated mailing system would be unable to take advantage of the system. If the goal is just to provide an additional mean for people to check if their messages have been delivered, this wouldn't be a problem, but it would require some changes: - it would be useless to automatically check for the message status (which would be HIDDEN anyway), unless you expect people to be willing to solve captchas for every message they send - message status should be availabe for a long time, since people would use this opportunity only if they somehow suspect that the message has not been delivered -- Claudio Telmon claudio@... http://www.telmon.org _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Rich Kulawiec
::
Rate this Message:
On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz wrote:
> On the other hand, consider valid the hypothesis that spammers don't > know what kind of filter is being used (by some particular site) is also > a bad idea. Oh, I agree. It's long been known that [some] spammers have taken pains to track the characteristics of target sites/systems/networks/etc. And some of those sites are (in various ways) "announcing" details of their configuration to the outside world, which makes that task easier. ---Rsk _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Pars Mutaf-2
::
Rate this Message:
What if the CAPTCHA needs to be solved before the status can be seen?
That would work? pars On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote:
_______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Yao Ziyuan
::
Rate this Message:
On Mon, Oct 26, 2009 at 9:26 PM, Pars Mutaf <pars.mutaf@...> wrote:
> What if the CAPTCHA needs to be solved before the status can be seen? > That would work? Right. The sender can set a "wait period" for every outgoing message -- if the wait period is over and there is no reply, his mail client can remind him to solve the CAPTCHA to see and fix the status. > > pars > > On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote: >> >> On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz >> wrote: >> > On the other hand, consider valid the hypothesis that spammers don't >> > know what kind of filter is being used (by some particular site) is also >> > a bad idea. >> >> Oh, I agree. It's long been known that [some] spammers have taken pains >> to track the characteristics of target sites/systems/networks/etc. And >> some of those sites are (in various ways) "announcing" details of their >> configuration to the outside world, which makes that task easier. >> >> ---Rsk >> _______________________________________________ >> Asrg mailing list >> Asrg@... >> http://www.irtf.org/mailman/listinfo/asrg > > > _______________________________________________ > Asrg mailing list > Asrg@... > http://www.irtf.org/mailman/listinfo/asrg > > Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Yao Ziyuan
::
Rate this Message:
On Tue, Oct 27, 2009 at 2:35 AM, Yao Ziyuan <yaoziyuan@...> wrote:
> On Mon, Oct 26, 2009 at 9:26 PM, Pars Mutaf <pars.mutaf@...> wrote: >> What if the CAPTCHA needs to be solved before the status can be seen? >> That would work? > > Right. The sender can set a "wait period" for every outgoing message for important messages > -- if the wait period is over and there is no reply, his mail client > can remind him to solve the CAPTCHA to see and fix the status. > >> >> pars >> >> On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote: >>> >>> On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz >>> wrote: >>> > On the other hand, consider valid the hypothesis that spammers don't >>> > know what kind of filter is being used (by some particular site) is also >>> > a bad idea. >>> >>> Oh, I agree. It's long been known that [some] spammers have taken pains >>> to track the characteristics of target sites/systems/networks/etc. And >>> some of those sites are (in various ways) "announcing" details of their >>> configuration to the outside world, which makes that task easier. >>> >>> ---Rsk >>> _______________________________________________ >>> Asrg mailing list >>> Asrg@... >>> http://www.irtf.org/mailman/listinfo/asrg >> >> >> _______________________________________________ >> Asrg mailing list >> Asrg@... >> http://www.irtf.org/mailman/listinfo/asrg >> >> > Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
Re: Passive Spam Revocation
by Rich Kulawiec
::
Rate this Message:
On Mon, Oct 26, 2009 at 03:26:40PM +0200, Pars Mutaf wrote:
> What if the CAPTCHA needs to be solved before the status can be seen? > That would work? Nope. (Let me pause to note that there are a number of other problems with this idea as well, I just didn't articulate those.) The gap between "captcha which is difficult enough to defeat a program" and "captcha which is easy enough to be solved by a human" has already closed -- and even if it hadn't, spammers have numerous other techniques available to them that scale reasonably well, including (a) captcha replay and (b) mass cheap labor. So I think it's reasonable that if it becomes advantageous to spammers to solve captchas en masse, they will. ---Rsk _______________________________________________ Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
|
|
|
|
|
Re: Passive Spam Revocation
by Yao Ziyuan
::
Rate this Message:
On Tue, Oct 27, 2009 at 11:34 PM, Danny Angus <danny.angus@...> wrote:
> Hi Yao Ziyuan, > I see you also posted this to the asrg. I'm shamelessly cross posting > my reply, sorry in advance to *both* lists! > > My response is in two parts: > > a) I like the fact that the recipient can set up a test which must be > passed by the sender. I also like the fact that the test would be > passive protection when protecting against, for example spam viruses. > In other words the recipient can set up a test, but the test itself > only generates load when the sender considers it worthwhile to take > the test. > > However I would prefer to see the test administered by the mail > system, rather then via another channel. > Solving the problem of spam by invoking a channel not currently > involved in mail transport is not really a solution, it is both > delegating the problem to another arena, and changing the nature of > email. > > There's nothing inherently wrong with this, but if we are to consider > changing the nature of email and channels involved we assume that we > could design out the problem from the outset by introducing a strong > concept of identity to the process. > > If we anticipate a design which uses the mail transport the passivity > advantage breaks down as the sender must be notified that a test > exists. In this case it would fail the criteria for not introducing > *more* load (email) in response to spam. > > The goal is to find a solution which reduces the load as it becomes > successful, even if faced with increased demand. What I mean is that a > true solution would be completely passive when confronted with spam, > and in reducing the spam transported would result in a net decrease in > demand. > > A passive test that meets the criteria would be one in which a test is > published in advance at low cost (perhaps by a third party), and for > which the solution is encapsulated in the message when it is sent. A sender may not think it's necessary to solve a test when sending a message, but changes his mind later, when he realizes the message is important and a reply is expected but doesn't arrive in time. > > For example the test may be for the sender to publish SPF records, or > use a mark similar to the habeus warrant mark. A recipient domain can > publish the test in the their T's & C's. > > If you want to consider CAPTCHA, perhaps the test would be to > pre-solve a CAPTCHA, send the UID of the puzzle and its solution in > the mail headers, but CAPTCHA is not really low cost, and is still > another channel. > > > b) the idea of using a CAPTCHA is flawed and has already been > discussed at length by the asrg. > > In essence CAPTCHA works where there is less value in solving the > puzzle than it costs to solve. > If you introduce a strong commercial incentive you will start an arms > race which will see people compete to develop systems which can solve > puzzles at a lower cost, and others compete to develop more complex > puzzles. > We must assume that this will happen unless you can describe a test > which can be reasoned to be unable to be solved by a machine. > The fact that CAPTCHA are impractical to solve with current technology > doesn't imply that they are impossible to solve. > > This ties in with point a) because it suggests that in operation the > incentive is there for spammers to now not only send spam but also > create additional work for the CAPTCHA component and the quarantine > components. > > Even if spammers use systems which can only achieve a low sucess rate > at the test, there is an incentive to attempt the test every time. > This generates additional demand. > > d. > > > On Mon, Oct 26, 2009 at 12:16 AM, Yao Ziyuan <yaoziyuan@...> wrote: >> Passive Spam Revocation (PSR) >> >> Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam >> filter, which can drop good and important messages. >> >> I propose an optional feature for current mail systems. The main idea >> is if a message is considered spam, this spam status can be tracked by >> the sender (but not sent to him directly, as the From field can be >> faked). The message can be re-marked as "not spam" if the sender can >> solve a CAPTCHA. >> >> STEP 1: A is going to send B a message. A's mail client generates a >> random code and puts it in a custom field in the outgoing message's >> header: >> Code: <random code> >> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits: >> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<Code> >> This page displays one of these possible "spam statuses": >> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.) >> * MESSAGE CONSIDERED NOT SPAM. >> * PENDING. PLEASE TRY AGAIN LATER. >> * All other responses mean B's mail system doesn't support this feature. >> In the first case, A's mail client will report the status and the >> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message >> is not spam. >> >> Like the idea? Here is the official Google group for it: >> http://groups.google.com/group/passive-spam-revocation >> >> Regards, >> Yao Ziyuan >> http://sites.google.com/site/yaoziyuan/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-dev-unsubscribe@... >> For additional commands, e-mail: server-dev-help@... >> >> > _______________________________________________ > Asrg mailing list > Asrg@... > http://www.irtf.org/mailman/listinfo/asrg > Asrg mailing list Asrg@... http://www.irtf.org/mailman/listinfo/asrg |
| Free embeddable forum powered by Nabble | Forum Help |
