Back when Out of Office (OoO) replies first started, the problem was getting stuck in an auto-reply loop. The OoO user would reply back to someone but that someone also had OoO enabled or it was a listserver for, say, a newsletter that would reply that it didn’t understand the command sent in the body of an e-mail that it received. So it sent back a reply. The OoO user’s e-mail client/server sent back another reply, the original OoO user or listserver would send back another reply, the OoO user sent back another reply, and the two kept bouncing replies back and forth as fast as they could. The user would return to find their mailbox filled with thousands of these auto-generated replies and their IT folks ■■■■■■ off at them for all the e-mail traffic. I believe the cure was to have the OoO client or server remember who sent e-mail and add them to a list and only send a single OoO generated reply to that sender. This required the e-mail client or server to remember every sender for every received e-mail to that account while OoO was active. There is an RFC regarding auto-responders but, as I recall, it doesn’t actually address this infinite bouncing between a couple of Out Of Office responders but discusses the problem in general (I can’t remember that RFC’s number right now).
I’m wondering how Comodo AntiSpam (CAS) handles getting back auto-generated replies. Say CAS sends out its challenge to a sender. Like with OoO, does it send out only 1 challenge per sender to ensure that if that user is also using a challenge-response (C-R) system that CAS doesn’t send out another challenge? If CAS is also maintaining its own list of senders to whom it will send a challenge, supposedly that sender gets removed when they get whitelisted. If CAS is maintaining this list, like in a pending queue, is there a maximum number in this list of pending queue for which CAS can track those senders?
I don’t want to end up using a C-R product that gets stuck in an ever-bouncing loop between it and another C-R user, or between it and a listserver that accepts commands via email (but will obviously reject challenges since those aren’t commands to the listserver).
As far as I yet know, there is no RFC that specifies how challenge-response systems are supposed to operated. I remember seeing a very rough draft for an RFC several years ago but I don’t think it went anywhere (its author wasn’t willing to take the pains in getting an RFC debated, thrashed out, modified, and then ratified). There is the other RFC that I mention regarding auto-generated responses but, as I recall, it did not specifically address C-R systems. With different C-R systems using their own method of employing C-R and with them possibly connecting to each other (i.e., a C-R user sending a challenge to another C-R user), I’m concerned about the bounce loop.
Also, do you know of anyone that is trying to get C-R standardized in an RFC or if all C-R schemes are relying on an existing RFC to define how they should behave and how to cooperate with each other?