Order confirmations, billing statements and delivery notices from online shopping systems are usually sent via automated systems. Email challenges sent to such systems can be lost, and legitimate mail sent by these systems may not reach the C/R system user. Advocates of C/R systems argue that, though it takes extra effort, solutions for these problems exist if the end-user behind the C/R system does these simple things: Whitelist a mailinglist address manually as soon as one subscribes to it. Note: for many email groups, the new member won't know the group's address until after receipt of the "welcome" email, thus making this recommendation unworkable. Use 'tagged email addresses' for mailinglists or automated mailers like the above, that can be recognized and cleared automatically by the C/R system. Manually inspect the message queue and overriding the C/R process in case where the C/R system holds an expected message from an automated mailer. False positives C/R advocates claim that such systems have a lower rate of false positives than other systems for automatically filtering unsolicited bulk email. Critics argue that typical users of C/R systems still need to review their challenged mail regularly, looking for non-bulk mail or solicited bulk email for which the sender has not responded to the challenge. This issue is particularly notable with newsletters, transactional messages, and other solicited bulk email, as such senders do not usually check for challenges to their mail. However, if the bulk email in question was solicited, then the C/R user could be expected to have added it to the whitelist. If the bulk email was not solicited, then by definition it is spam, and is filtered by the C/R system. Implementations Tagged Message Delivery Agent Channel email <- Just wants a reply, doesn't actually try to determine if the user is human (thus getting rid of the spammers that don't use legitimate emails and doesn't require costly processing). FairUCE ("Fair use of Unsolicited Commercial Email"), developed by IBM, tried to find a relationship connecting the envelope sender's domain name and the IP address of the client delivering the mail, using a series of cached DNS look-ups. If a relationship could be found, FairUCE checked the recipient's whitelist and blacklist, as well as the domain's reputation, to determine whether to accept, reject, challenge on reputation, or present the user with a set of whitelist/blacklist options. As of 2010, the project is listed as