Randahl, > One could argue that it should > be made hard for a spammer to figure out whether his spamming attempt > succeeded,
This is a very compelling argument when you consider the two main technical activities of spammers; a) to identify valid recipient addresses b) to identify open relays. In the case of a) rejecting mail based upon recipient address is a useful aid to spammers as it allows them to harvest valid addresses from servers. In the case of b) I manage a handful of James installations and all of them receive a number of "probing" emails daily. Usually sent between hotmail or yahoo accounts, they contain a serial number, no doubt used to log the identity of any MTA through which they succesfully pass. This is a system as sophisticated as the ordb check, and way more intelligent than the Spamlarts tests. Spammers aren't stupid, just a pain. > however, I think it is a waste of valuable clock cycles to > have them keep on trying. And in my observations I haven't found dealing with relay attempts to be a very significant portion of load, and I doubt that many individuals will repeatedly knock at the same closed door. > Also, if JAMES was more clear in its client > responses I would feel more certain that none of the on-line lists of > open relays would list a JAMES mail server by mistake. Here we have to assume, from comments and observation, that although some tests are naieve, none of the major blacklists are fooled by James' blackhole approach. > Again, I am aware that there might be some design reasons to why JAMES > responds the way it does There are, mainly that all of the mail handling after the initial receive is pluggable, highly extensible, and configurable, including even the most fundamental parts of the handling process such as remote & local delivery. To reject mail at the gate would compromise this flexibility and power. >- still, would it not be an advantage if it > worked differently? There are some benefits, and it has been an ongoing discussion, and will probably occur, that rejection of mail based upon RCPT TO and MAIL FROM is added as an option. But it is waiting for available developer cycles, or contributions. Like so much at apache, if a problem is really bad enough someone with a bad itch will write a patch to solve it, if its a more theoretical case it may rumble on for ages while everyone does something better with their time. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
