Talk:Challenge–response spam filtering

message: I'd think that NPOV would require that the article first describe C/R systems.  Later in the article criticisms and responses could appear.  A good exercise for the anti-C/R folks would be to properly present the NPOV case for C/R.
Minasbeede 15:47, 26 June 2006 (UTC)
replies: text:  Sounds like a great idea.  I myself use a C/R system, although I wrote it myself because I am against all existing systems [known to me].  So I'm not sure that I fall clearly into either of these camps.  You're welcome to add the parts you suggest!  Megacz 17:49, 27 June 2006 (UTC)
replies: text:  A number of the problems I see cited are not ones I understand to be common, such as loops between fighting C/R systems, and common challenge to properly classified mailing list mail with a Precendence header.  It would be good to see citations of which systems had these bugs.  --Bradtem 22:49, 28 October 2006 (UTC)
thread_title:  That seems backwards (compendium of all the objections to C/R) 

message: "the inconsiderate burden their beloved C/R systems place on innocent bystanders" ?
: This could be fixed by removing "inconsiderate", and "beloved", couldn't it?ConditionalZenith 10:58, 8 September 2006 (UTC)
replies: text: No reponse and original complainer didn't leave details.  Making changes as specified and removing POV template.ConditionalZenith 11:02, 11 September 2006 (UTC)
thread_title:  NPOV 

message: In the comment on this edit Megacz claims replies are passed through by all sane CR systems. only UNREQUESTED emails are challenged.
I agree: a "sane" C/R system would not challenge requested email, but Megacz fails to show that such C/R systems exist. If C/R systems could determine requested email, they wouldn't need to challenge. Erik Warmelink 19:11, 2 June 2007 (UTC)
replies: text: My own C/R system has this property; it uses the fact that the Message-ID of an email is propagated into the In-Reply-To and References headers of replies to that email.  Moreover, the "requested" you mention refers to the challenge, not the original message.  The challenge is requested by the original message. Megacz 01:18, 6 June 2007 (UTC)
thread_title:  requested e-mail 

message: The article says:
: If the message was sent to an address which forwards to the C/R user's address, an extra message will be generated. Alternatively, one could employ C/R on the forwarding machine and then unconditionally accept messages which pass through it.
I am not convinced that the "alternative" would be a major problem of using SMTP response codes. A better alternative is using spam defences on the forwarding machines, instead of aiding a Denial-of-service attack. Erik Warmelink 20:52, 7 June 2007 (UTC)
replies: text:  Unfortunately, there are no "spam defences" which can be employed that are both effective and do not cause false positives (which are far more harmful than spam or blowback). Megacz 19:20, 8 June 2007 (UTC)
replies: text: Since challenges look like spam (IMHO, they are spam), sending challenges does not eliminate false positives: a reasonable spam filter will reject them. Anyway, you didn't answer the question why depending on the spam defences of the forwarder (or depending on its challenges, if you insist) would be a major problem of using SMTP response codes. Erik Warmelink 20:17, 9 June 2007 (UTC)
thread_title:  Forwarders 

message: C/R isn't an anti-spam technique, it sends spam. It can't guarantuee zero false positives, because if the challenges get filtered (and challenges are unsolicited bulk e-mail) non-spam will be refused.
If one really believes both assumptions, one can easily remove all spam defences. That does guarantuee zero false positives (assuming unlimited bandwith and disk space) and spam was considered less harmfull than false positives anyway. Erik Warmelink 20:43, 9 June 2007 (UTC)
replies: text: Those false positives are the result of decisions by other machines which fail to check the In-Reply-To and References headers.  Those decisions are not decisions which are made by the C/R system, and therefore the C/R has not "falsely made a positive identification of spam". Megacz 03:49, 13 June 2007 (UTC)
replies: text: Rejecting unsolicited bulk e-mail before inspecting the body isn't a failure, it is a feature. Erik Warmelink 03:26, 14 June 2007 (UTC)
replies: text:  You are referring to the situation in which the original sender wanted to send an email to the CR user.  In that situation, a reply was solicited by the original sender.  Therefore the message which was rejected was not "unsolicited". Megacz 16:13, 14 June 2007 (UTC)
replies: text: A challenge isn't the kind of reply which was solicited. Anyway, whether you like it or not, challenges do get filtered. Sometimes because the machine sending them, has already been determined to be a spam source. Erik Warmelink 12:10, 16 June 2007 (UTC)

text: C-R systems do not send spam. The challenge that is sent might be unsolicited, but is definitely not bulk e-mail. Every incoming e-mail would receive maximum one challenging reply. OldCar 16:26, 18 June 2007 (UTC)
replies: text:  Challenges are e-mail. Since they are sent by automated systems and are substantively identical, they are bulk. Erik Warmelink 00:17, 6 July 2007 (UTC)
replies: text:  That would make all auto-responders, like the very useful 'change-of-address' notices intended to inform the sender of a message that the recipient addres he used is obsolete and that a different address should be used instead  qualify as bulk e-mail. And, following the same reasoning as above, qualify as spam. In the definition for spam the word 'bulk' means that 'numerous recipients' are involved and it's obvious that 'numerous' there means more that only the recipients that send me an e-mail. I comments in the article referring to challenges as 'spam'. OldCar 17:32, 30 July 2007 (UTC)
replies: text: All 'change-of-address' auto-responders written after RFC 821 (which documented the reply code 551 User not local; please try <forward-path>) are spambots. Of course that RFC was written only 25 years ago, so perhaps you have not heard of it yet. Erik Warmelink 00:18, 31 July 2007 (UTC)
replies: text:  Could you (or someone) please give some sound proof of that bold statement? And could you please explain then why currently the IETF is proposing RFC  3834 as a standard on 'Automatic Responses to Electronic Mail' if auto-responders would generally be considered spambots? OldCar 07:07, 31 July 2007 (UTC)
replies: text: They are spambots because they are automatted systems (bots) which send unsolicited bulk e-mail (spam). RFC 3834 has a section labelled 6. Security Considerations. Erik Warmelink 20:47, 3 August 2007 (UTC)
thread_title:  Basic Assumptions 

message: I've tuned up some of these descriptions and added dates to the reference articles, organizing them chronologically. Some C-R applications take many steps before sending a challenge with the goal of minimizing challenges. Pjbrockmann 01:23, 18 July 2007 (UTC)
thread_title:  Tune up 

message: What's best? 'C/R' or 'C-R' systems? If 'C/R' is better, shouldn't the topic be changed to 'Challenge/response spam filtering'? OldCar 17:37, 30 July 2007 (UTC)
replies: text: IMHO, C/R is the accepted usage, but I suspect there's a problem including a slash in a title ... richi 20:49, 30 July 2007 (UTC)
thread_title:  C/R or C-R 

message: I tried to give this section a bit more NPOV and tried to 'clean it up' a little so it would read nicer. I removed the following paragraph for the reason that it is (currently) a completely impractical suggestion and probably too technical to bother an average reader with this early in the article. It might be better to swap this section with the 'Critisisms' section and let this section be some kind of 'recommendations' on (the use and implementation) of C/R systems following from the critisisms. OldCar 06:51, 1 August 2007 (UTC)
thread_title:  Best practices 

message: C-R for Mails doesn't meet RFC822, because they don't bounce.
Also the mails are, by law in most countries (for example Germany) delivered as soon as the mailserver accepts it. Either its bouncing, or be responsible for recieving the mail (which you might not finally recieve at all) --217.151.145.186 (talk) 13:16, 26 August 2015 (UTC)
thread_title:  Doesn't meet criteria of RFC822.