Problem solved! I just got the green light from ordb.org:
"The host you submitted at ORDB.org (212.242.50.198), has been thoroughly checked, and does not seem to permit relaying." It turned out to be right what a couple of you suggested (thanks Serge and others): Using the wildcard 10.0.0.* was the root of the problem because as soon as I listed the exact IP-adresses, everything worked fine. I could not prove this from what I found in the log files, but it must have been a firewall issue. As Serge suggested maybe my firewall, which is at 10.0.0.1 made it look like people from the outside came from 10.0.0.1 which matches 10.0.0.*. So what I have done now is simply to list most of the PCs in this network in the list of PCs which should be allowed transmitting e-mails to the outer world. If I find the time, I will check up on this to see if can figure out a smarter solution. It was a hard problem to track down because I got confused about the different anti-relay measures in JAMES. Because JAMES has got several different checks it can sometimes be hard to figure out which check made it work or which check could maybe be configured in a wrong way. One of the things which surprised me was that if you have an IP address which is mentioned in RemoteAddrNotInNetwork you are allowed to do anything, it seems. As I recall you could even send an e-mail from a fake domain (spite the SenderInFakeDomain check). I also found that sometimes it was hard to find the logging information needed to hunt down the problem. There are several different log files, and you really have to have insight to know where to look. There might have been an earlier thread on the following issue, but tracking down configuration problems really says to me that JAMES could benefit from a Swing-like configuration wizard. It could be a simple tool which asks the user a few intelligent questions about his or her preferences and then spits out the proper configuration file. Such a visual interface would probably make JAMES more compelling to those users who do not wish to gain thorough insight into the inner workings of JAMES to make it work. To contradict myself, I must admit that for the APACHE web server I think most people use the configuration files directly rather than visual tools (which are probably available since apache as we all know is an old and mature product). I guess this depends on your individual needs. If you expect to just quickly setup JAMES and have it running without changing its configuration very often, a visual tool would be a great benefit since people tend to forget how to use the configuration files if they have not done so for a long time. Yours Randahl -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 00:35 To: James Users List Subject: RE: Relay prevention 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
