thanks Danny. Nobody has spoken up about the IMAP stuff, so I think I'll take a poke at it.
Your point is well taken. One of the biggest problems with smtp relays is that they can be used to find valid users on a local box. I'll submit a server for testing to maps and see what happens. I have some friends there. I'm fairly sure that the tests will result in the smtp server being added to the rbl. I agree with all your points on that subject. Perhaps we can find some way of interfacing with the rbl and/or orbs (and the others) that will deal with this problem without opening james up to the public. Obviously, a user could configure james to relay if they so desired, so testing for james itself isn't good enough. Perhaps we can build some mechanism to deal with this problem without active smtp sessions. Cheers, Craig -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 3:16 PM To: James Developers List Subject: RE: dev questions > Hello fellow developers. Hi Craig.. > 1) The way in which james accepts mail and them makes decisions > around mail routing may lead projects such as orbz and > RBL(maps) to believe that james is an open relay. I'll do my bit > and study the code on that, but can somebody give me a > high level view of why james operates in this way? Actually there are three points here, a) these blacklists are aware that simply accepting all mail doesn't, alone, make you an open relay (see http://jakarta.apache.org/james/FAQ.html#2 ) and we haven't (yet?) heard of any instance where anyone has had James blacklisted for this reason. b) We have been discussing implementing active SMTP sessions primarily so that James can return 550 errors, but also because implementing a mailet (or suchlike) container at this point in the process adds to the extensibility of James, and properly done could provide support for pluggable ESMTP command processors. Unfortunately none of us seem to have the time, currently, to dedicate to major development effort at the moment (where's the recession gone?!) so that is on the pending pile like a number of other planned features. c) Personally I believe that the use of the 550 error code for undeliverable mail is flawed, and that James' approach, the blackhole, is a better deterrent to spam. Why? because I was spammed the other day with a mail offering me a piece of software which would harvest addresses, I tried it out, it worked on the simple principle of running hundreds, thousands, or millions of SMTP "RCPT TO:<recipient>" commands against a mailserver and logging the ones which got a 2** (ok) response. Now the software I downloaded worked on a purely alphabetical sequence, so it could take thousands of trys before it encoutered any real addresses on a quiet server, but a busy domain (like yahoo or hotmail) would result in many fewer tests per hit, and a more sophisticated programme could use lists of names and phonetics to make better initial guesses. This software works on servers which pass the non-relaying test with flying colours, but *not* on James..... > 2) Is anyone looking into IMAP support at all? Do you have > interested parties for taking the alpha stuff all the way? If > not, does anybody object to me taking a swing at it? (no, I won't > use swing). I'll let someone else answer that. > 3) How serious and committed is this development group to seeing > james become a serious replacement for sendmail/qmail? > (It's not far off, but it does need some more functions). We've certainly had a lot of people interested in using James as a sendmail replacement, and I would like to too, any proposals that would help advance this would be welcome. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
