Re: Deprecate Mail.getSender/setSender
Noel J. Bergman wrote: I propose that we deprecate Mail.getSender/setSender in favor of unambiguous names that relate to the SMTP RFC: Mail.getReversePath/setReversePath. Works for me. +1. This would likely need to be applied only to the 3.0 branch though. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: subject prefix mailet or unaltered recipients in Redirect
Vincenzo Gianferrari Pini wrote: As you already said, Redirect suffers from the need of backward compatibility, that we must guarantee. We could in the future create a new mailet, with a different name (which name BTW?) following more consistently the conventions. This mailet has become a veritable swiss-army knife of confusion. :) It might benefit by having some mailets that extend this with options hardset and a more understandable name. I'm trying to think of a decent example, but am blanking... are there some typical usages of this that are useful? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving temporary failure handling in RemoteDelivery
Noel J. Bergman wrote: Serge, The particular error I received: 451 4.7.1 Please try again later Well, per your analysis of that response, you've got multiple conflicting rules. 451 says local error, 4.7.1 says could be either, the note on the error says try again later, and 4.7.1 says this should be a permanent error. I've got a nice shiny quarter here... you want to call heads or tails? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] implementation of getInitParameterNames in MailetConfigImpl.java
Soeren Hilmer wrote: This patch implements the getInitParameterNames method in MailetConfigImpl as required by the Mailet api contract. Applied. Thanks. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: DBCP status?]
Below is what I suggested to do for the DBCP project since the codebase itself (while widely used) is somewhat dead. Tomcat still recommends it first, and it's used in several packages. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ---BeginMessage--- Shapira, Yoav wrote: I wouldn't rush to declare DBCP dead. Database connection pooling is not exactly the most revolutionary development area right now: DBCP is good at what it does, is being used widely, and I personally am not aware of anything that required a DBCP release within the past year. That's somewhat encouraging about Tomcat using it (or at least mentions it first). Since James really does need a new connection pooler, and I'm stuck having to invest some time into making **some** database pooler more robust, is the DBCP project open to this? I'm not sure if there are any committers remaining, or what exactly is the next step. Basically I would make the following changes: - Allow the pool to optionally close a connection on a SQL exception (since that will often corrupt the transaction and/or indicate the connection is boofed). - Change some default values so it doesn't block indefinitely to open a connection out of the box. - Maybe support a connection factory constructor that can take a String for a driver name, rather than require you to do Class.forName() separately. - Maybe implement login timeout. - Maybe implement logging via commons logging so you can catch events rather than just use a writer. - Make a formal new release (either 1.1 or 2.0, I don't care), just so the examples, test code, and javadoc (in distro and website) all have working examples. Any feedback on these changes, or people I should talk to before heading down this road? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Emeritus status
Since the CVS server was compromised and rebuilt 2 years ago, it allows us to track who hasn't been around lately, and thus change access rights to emeritus status. As an emeritus committer, the person no longer has commit access, but can request it back without a vote. If they are still around and would rather not become emeritus, they're free to -1 this. This is the jakarta policy to my understanding, which I think is a good model to follow. I did a grep on the current CVS code, and these accounts have no activity: duncan, jon, bburns I proposing moving these 3 to emeritus status. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Removing Paul Hammant's temporary commit access
Many moons ago (May 2002), after one of my rants, Paul Hammant graciously offered to help James keep in step with Avalon's changes. He suggested giving him temporary commit rights to apply his changes rapidly and get everything working, and we voted and rights were granted. Since then, Paul's code updates are complete (thanks!). Also, Steve McConnell has largely taken over as the Avalon comitter with temporary James access. I propose we remove Paul's commit rights to James. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [jcifs] NTLM Documentation]
Thought this might be useful if anybody was thinking about doing this for James. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ---BeginMessage--- I have been putting together a (relatively) comprehensive documentation of NTLM and its use in various protocols; this is now up and available on the Davenport site at: http://davenport.sourceforge.net/ntlm.html Good rainy day reading ;) Eric ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Null sender
Vincenzo Gianferrari Pini wrote: This latter shoud be the case of Return-Path: This Return-Path header should get set based on the MAIL FROM: command during SMTP, so those should be the same IIRC. Anyhow, I'm fixing a bug in AbstractRedirect that was causing a NPE trying to build a new TO using the sender, that it turned out null in some cases (spam or virus). I'm going to do the following in such case: use the sender, if null use the return path, if null set it to . Can you have it just not set the TO? But I'm asking myself too on what James does if it tries to send a message to an empty list of recipients, because for example NotifySender processes a mail that has a null sender as said above. The original NotifySender was doing this way, and the new one too. Should I change it to something like the following: use the sender, if null use the return path, if null leave it null (or throw an exception)? Ideally the NotifySender should see the sender is null and not try to bounce to it. Separate from that, the LinearProcessor should see that there are no recipients anymore on a message, and end processing. I think the latter already happens, which is perhaps why the old code was just setting the recipient list empty. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving temporary failure handling in RemoteDelivery
Noel J. Bergman wrote: RemoteDelivery: Exception delivering message (Mailxxx) - 451 4.7.1 Please try again later What's the RFC say for 451? If it's authoritatively saying you should try later, then I think the behavior is currently correct. To fabricate a case that could justify current behavior, say I have a quota on Joe Smith's mailbox at 10 MB. His mailbox is at quota, so I don't want to accept more messages for Joe. Meanwhile, I have a remote backup server that accepts messages when the primary is down. Because it is remote, I can't check whether a mailbox is full, so I don't reject based on the quota. Right now our server would see that Joe is overquota, and try again later, until either Joe clears some messages or our retry fails. If you change it, you'll deliver to my remote server, thereby getting around my rejection on the quota basis. Yes, my remote server will ultimately figure this out, but I would have preferred Joe's sister never send those 10 additional 5 MB messages in the first place. Sorry the lengthiness, but it depends on whether 451 is a reply for the domain or for this server. I tried reading through the RFCs, and am only the worse for it. :) I don't see anything that says when you should move through the MX chain, just that you should and how. My feeling is if the server gives a response, that's enough for the domain. Dunno. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal IP blacklists
Noel J. Bergman wrote: It would be very simple to code a JDBC based block list matcher, but why don't you simply create a local DNS zone, and populate the zone file? I've already got the database open, so I'd rather keep all the relative info there. And actually, in the back of my mind, I've been thinking about how to make these personal blacklists sharable... kinda a napster-blacklist. But anyway, what it did lead me to was the idea of having the blacklist matcher point at the *message store*. As spam fills my spam folder, when it was something I wanted to blacklist, I would copy it from my spam store to my blacklist store. Then the matcher would look for any messages from the sending IP address in this blacklist store, and if so, would say leave me alone, you already sent me 4,230 messages on June 12th. This also preserves the evidence for why I blacklist them. Yes, I'm probably overthinking this, which was why I was wondering what people's experience was with blacklisting IP addresses in general. I also am finding that for certain spammers, they seem to have a full C-class available to them, so I end up just blocking that last octet. My blacklist store wouldn't handle that (just yet). -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal IP blacklists
Richard O. Hammer wrote: My dream SMTP server has a GUI reminiscent of the control room at a power plant, with gauges which show every parameter which might be important to the operator, and with valves to throttle or completely shut down any segment of the operation which seems to be getting out of hand. I'm thinking web-based, but yeah, that would be nice. Parameters such as the following would have both gauges (and/or warning lights and whistles) and values (operator-settable limits): total incoming messages/(unit time) 1. This can be a simple mailet... just log the size and time (other info?) of every message that comes through. Then have a reporting tool to pull over some time period. total incoming connections/(unit time) 2. Hmm, this would need to tweak the SMTPHandler to do this. total incoming bytes/(unit time) 3. Same as #1 total outgoing ... (the same three as above) 4. Perhaps just another mailet, this time though logging what goes through the outgoing spool. total volume of mail held in local mailboxes 5. This would have to be (an expensive) query done ad-hoc. I can't see maintaining that as meta data. total volume of mail held in local spools 6. Same as #5. ip addresses generating most of the traffic/(recent unit of time) 7. Relates to how #1 is logging and reporting. Shouldn't be too difficult. ip addresses generating most of the connections/(recent unit of time) 8. Same as #7. local addresses receiving large quantities of mail 9. Another type of mailet, this time in local delivery spool. local addresses sending large quantities of mail 10. Extra report on #9. Also, another approach, I would prefer to have the server return an error upon RCPT TO: unknownJoe, rather than accept the message as James does at present. I think Noel said there were plans to change this in an upcoming James. 11. Yes, I think that's something that's coming. Most of this is only 1 logging mailet that could get plugged into a number of spots in the different spools, and then you'd need a reporting tool to read those logs and give you nice data. Someone had talked about adopting a standard logging format for James, which might get much of this done just by relying on existing reporting tools that unstandard that log file format. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [no virus] [PATCH]On matcher/mailet exception handler
Vincenzo Gianferrari Pini wrote: Noel, here is a patch (only v2 for now) that implements the exception management handling at config.xml level using the attribute syntax. It is working fine. Thanks for all the patches! I would say though, hopefully any day now so you'll have the account to commit these changes yourself, so you can cut your teeth on some of these. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EL for matching
Here's something from way in left-field. I tend to agree with (name I forgot here...sorry) that XML shouldn't be used for scripting so much, and I'm not sure how you merge the configuration needed for mailets and matchers with a scripting section. BUT... what I was going to suggest is what about using EL (defined originally in JSTL and now available in commons) as a way to the scripting. This could be a bear to implement (which it already is, and needs to be improved), but this could immediate give us a somewhat-standard and much richer logic and evaluation. Matchers could get configured and be EL functions. Just as a way to improve the matching logic. Any thoughts? Tracking how things like Siege and procmail work, there is just a lot more a sysadmin can do with simple scripting. James can extend way beyond what those can do, but you are stuck with tough scripting or turning to Java code (which is what I originally wanted many years ago, and now think is bad). -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: New Committer, Mr. Vincenzo Gianferrari Pini
Danny Angus wrote: is this the vote? Noel is checking for objections first... he's a bit too nice at times. :) If so +1 I would like to propose Vincenzo as a James Committer. Yeah, me too if a committer nominates him. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer, Mr. Vincenzo Gianferrari Pini
Noel J. Bergman wrote: Moving ahead to the one-step process version ... :-) So far we have: Harmeet Bedi:+1 Danny Angus: +1 Noel J. Bergman: +1 I expect Serge will post an official +1, too. I can't speak for Darrell, Charles, Peter, et al, who haven't been around too much lately, but the measure will carry unless someone vetoes, which I don't expect. Noel, I must reset your expectations on this. The procedure is this: 1. An existing committer nominates a contributor, or the contributor can ask for it themselves. 2. Once nominated, all committers on the subproject will vote. You need at least 3 positive votes and no negative votes. Typically we give 48-72 for everyone to vote if they're going to. 3. If approved, we get them an account (if not already) and otherwise set them up as a committer. Right now we're at step 0, or rather, on some unofficial path that should be stopped in the interest of avoiding confusion. If you want to nominate Vincenzo, then great, we can have can start this process and take a vote. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer, Mr. Vincenzo Gianferrari Pini
Noel J. Bergman wrote: I did propose him. Harmeet and Danny both wanted to vote. You commented that I was being too nice by proposing first, so I posted it as a vote as you appeared to have requested. Noel, I'm sorry. I must not be sleeping or something. Here's what I think happened: You did (effectively) propose Vincenzo, but I was looking for: a) calling it a nomination. b) a call for a vote. So your email didn't set a flag off in me, and I didn't realize this from yesterday as the source of the confusion until just now. In light of the confusion, let's start counting 48 hours as of your message today at 12:57:13 -0400 that mentions a call to vote. With my +1, you've got 4 +1 and a passing nomination assuming nobody vetoes in the next 46 hours. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging in the new DNSServer service
Harmeet Bedi wrote: - Original Message - From: Chris Means [EMAIL PROTECTED] So suddenly, I'm worried that mail from apache.org isn't getting through... If there is no MX record, A record represents mail host. It is not an error to have no MX Records and neither is it necessary to recieve mail. We could do something like attached snippet inside DNSServer::findMXRecords. We should also change the logging to say INFO or WARN if not DEBUG for the above message. I'm not sure what's getting logged right now, but here's what I might expect at each level: DEBUG: all lookups INFO: no MX records WARN: ? ERROR: DNS server not responding -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fix for bug 20370
Noel J. Bergman wrote: I agree. The RFC doesn't say what *to* do with CR or LF. It just says that we cannot recognize them as a valid line terminator for a command, and that we must not emit them other than as CRLF. They are not valid characters within a command line. Therefore it seems to me that the presence of an invalid character is a 501. I don't think we should be failing on bad data if it's pretty clear how to handle it gracefully. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fix for bug 20370
Noel J. Bergman wrote: I understand your view, and all things being equal, I agree with it. The basic Be strict in what you send, lenient in what you accept philosophy espoused by the late Jon Postel. Right, this is a good way to state my thoughts as well. Could/shoud we add this quote to the website and documentation in general that this is the approach we've used to do? There are so many places where we've had to interpret, I think it would be good for developers to see what we meant (irrespective of how the code came out). This termination sequence is denoted as CRLF in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Gotcha. I would suggest to build on Postel by saying: - if the RFC says the [sender] MUST/MUST NOT [blah blah], we should strive to be lenient. - if the RFC says the [receiver] MUST/MUST NOT [blah blah], we should not be lenient. Thanks for the clarification on the RFCs. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fix for bug 20370
Gotcha. I would suggest to build on Postel by saying: - if the RFC says the [sender] MUST/MUST NOT [blah blah], we should strive to be lenient. - if the RFC says the [receiver] MUST/MUST NOT [blah blah], we should not be lenient. Do you have these reversed? strict with sending and lienient with receiving? No, just have my context poorly described. By sender I meant the remote machine and by receiver I meant James. Meaning, if the RFC says the remote machine MUST do something (or not something), James should still be lenient and not act like a policecop of the RFC. However, if the RFC says James MUST do something (or not something), then we must do something. Again though, I think it's a solid idea, but in practice over time it I think it hurts the product and RFC. I can't see how this hurts the product, and the RFC has already been destroyed many times over by real-world implementations. So relatively, I see any damage we're doing to the RFC at this point as inconsequential. :) At this point I'd weigh the behavior of sendmail, qmail, exchange, and a few others more highly than what the RFC states. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PreparedStatement and performance
typedef_lex wrote: Why did Serge use PreparedStatements in eg JDBCMailRepository.store(MailImpl mc)? Because you have to store binary data. Besides, prepared statements should be much faster assuming your driver does prepared statement pooling. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protocol Handler-based rejection
Noel J. Bergman wrote: Sorry, I didn't know of 421 and 554. Having read them, I don't know why we would support them. Because it isn't hard, and provides additional options to the e-mail admin? if you send these, you have to keep the connection open and continue to accept commands and return 503 until you get a QUIT. I'd thought of that, but it is easy to catch at the top of the loop. In my assumptions of why you would immediately not accept a connection before any communication (something based solely on IP address or excessive message rate delivery), very rarely did I care what tailored message I sent the user (not that they ever read those), and I would expect you'd want to kill the connections immediately, not wait for a QUIT. I find the fact that other mail servers do this rather than send 421 evidence that they agree with my use-cases, not that they are too lazy to provide useful error messages (although that argument could be made). Also, I read 421 as for a server that's shutting down. It's a valid alternative to the 220 greeting, but I read this more because it's valid at all states (no matter where you are in the protocol, you need to tell the remote connection you're shutting down). We might want to think about hooking the shutdown code into the SMTP handler to adopt this notion. What is the deal with this ProtocolResponse class name? These are two very different functions. One addresses a TCP connect request and one is a SMTP command reply. The ProtocolResponse class would be used for returning a [code, text]-tuple. It fills the role that you had referred to as a struct-like class. Sorry, was cranky with my note and understood your name. I meant I think you're trying to force fit some inappropriate API and as a result providing too much information and control in one situation, and not enough in the other. We're discussing these two stages, but you're naming and arguments suggest this is something we be able to insert in ANY protocol response. I believe you would find this unworkable by examining other cases, as to generalize to this extreme would be significantly less useful. I think the choices of where we support hooks are deliberate: - We want to accept/reject TCP connects because we have a remote server that's pounding us, it is not in the network we like, or is otherwise a specific user we want to block or allow. - We want to accept/reject RCPT specified email addresses because at this point we will know whether this is someone who is authenticated, and whether this is someone sending inside-inside, inside-outside, outside-inside, or outside-outside. Adding something at MAIL FROM would only tell us from inside or outside, not the flow. Adding something after DATA would a) not help us avoid message traffic b) lead to more complex processing that should be handled asynchronously (ie., mailets). SMTP AUTH should be extensible via a account mgmt interface, not via individual protocol response handlers. Other commands just get much less use and have less value to expose through an API. Because it would make writing these filters more complicated, and less modular? My preference is towards smaller bits of specific functionality. Instead of a very restricted API, why not just provide specific configuration options for the couple of expected restrictions? What is less modular about providing more information to this RCPT handler? Finally, I have to take back the suggested returns. It's much more complicated than that... - for accept/reject connections, you might have a specific spammer you want to always block, and you might have a static IP address DSL home user you want to always allow. You can't simply AND or OR a bunch of boolean responses together. - for accept/reject recipient address, you have similar notions as above... specific spammers you want to always block, email addresses you might always want to allow. Not sure what's the best way to handle these situations. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protocol Handler-based rejection
I would think these are two different interfaces:
- acceptConnection() could know nothing but an IP address. And I would
see it returning a boolean. This would happen between accepting the
connection and print the HELO/EHLO message.
- acceptRecipient() could know the remote IP address, the send email
address, the SMTP session authentication info (if available), and
whatever else that could be garnered from the SMTP session to date.
This would likely need to return both a error code (550 etc) and a text
message explaining why. What about a struct-like class with these 2
fields, and then a bunch of constant values. (OK is 200, 550 is a
stanard rejection, and whatever else). The user could then return
custom error message if wanted, but otherwise James would it. This
would happen between RCPT TO from the client and defines the message we
send back to the server.
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
Noel J. Bergman wrote:
What I have in mind is a ProtocolResponse class that looks like:
class ProtocolResponse {
int code;
String text;
}
The filter methods would return null if there is no error, or a
ProtocolResponse. That is ALL that we would permit. No mailets in the
protocol handler. This is strictly a means to handle protocol responses. I
had originally call the class ProtocolError, but it occurs to me that a
commandmap-based protocol handler could use this generally.
Two new methods would be:
- IP based service check
ProtocolResponse acceptConnection(String remoteIP);
this is probably the correct way to deal with DNSRBL
if you don't want to provide any service, rather than
reject RCPT TO commands, immediately provide a 554.
- RCPT TO checking
ProtocolResponse acceptRecipient(String recipient);
Those would complement the filtering we already support via internal
mechanisms:
- maximum message size
- IP based relay denied
- SMTP AUTH based relay denied
Again, this is not to replace the matcher/mailet pipeline. It is strictly a
means to control protocol response to protocol commands. If we like how
this approach turns out, then we can consider using it more generically in
later revisions to the handler, and in other protocol handlers.
Thoughts, suggestions, flames?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protocol Handler-based rejection
Noel J. Bergman wrote: Why would they be different? acceptConnection() could be backed by a DNSRBL, for example, and would want to return the TXT record explaining the reason for the block. At least that was my consideration. Here's where I said I expected these listeners would go as we don't seem to be on similar pages. a) acceptConnection() happens between accepting the socket and sending EHLO/HELO. This has to be a boolean because you either disconnect immediately or accept the connection and send EHLO/HELO. b) acceptRecipient() happens between receiving a RCPT TO command and sending the response. This has to be a int code and String message because that's what SMTP's protocol requires back. We might return a boolean, but it seems important to return the specific error code. We might return just an int error code, but it seems helpful to optionally let a developer give a more tailored error message. Your comments related to acceptRecipient are interesting. It sounds as if you interpreted it as being a single call that would handle all cases related to RCPT TO. I don't understand what you think I'm saying. :) To me this is an API where you can list classes that implement each of these handlers for each of these accept situations. As these events happen, these classes have the appropriate method called. For acceptRecipients, the results would be constants (for most cases), and as long as the result was positive, it would flow through to the next. The first non-positive response would get spit out to the connection and the RCPT TO command failed. I had figured that we already had code to check for everything except for evaluating the recipient string, so I was just supplementing what we already had, rather than replace doRCPT(). I don't believe that a single method for checking all conditions would be as flexible. Hmmm, from my perspective, this API would replace nothing we already do as we have historically had no fast-fail capabilities (aside from what's just been added). -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Protocol Handler-based rejection
Noel J. Bergman wrote: That approach doesn't allow the server to return a 421 or (more importantly) a 554 reply, e.g., 421 - SMTP service temporarily unavailable. 554 - SMTP service denied due to block list; see: text The 554 isn't in RFC 821; it was added in RFC 2821. In any event, that's why I'd thought to use a ProtocolResponse object, so that the failure reason could be reported. Sorry, I didn't know of 421 and 554. Having read them, I don't know why we would support them. Sendmail and other mail servers I'm familiar with just immediately disconnect with no output. Both commands are just listed as may be used. Once more, if you send these, you have to keep the connection open and continue to accept commands and return 503 until you get a QUIT. This seems counter to the point of this feature. I absolutely agree with this, which is why I had proposed the ProtocolResponse class, which would be the return value. What is the deal with this ProtocolResponse class name? These are two very different functions. One addresses a TCP connect request and one is a SMTP command reply. Right. I'm just not sure why acceptRecipient needs to know anything more than the address. For example, it isn't responsible for SMTP AUTH. That is something else. Err, why not? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 18726] New: - RemoteDelivery doesn't usethe SMTP bind address
Danny Angus wrote: This is normal behaviour.. a machine running httpd will bind to particular IP addresses but outgoing http client requests will use the default IP for the machine. Why would you want to change this behaviuour? There's never an expectation that an HTTP client would also have an HTTP server, but for SMTP you can often expect (or maybe require) that the SMTP client has an SMTP server running. SMTP servers are required to be able to accept email to [EMAIL PROTECTED], and if an SMTP client sends a message with Received headers, then it's pretty clear this is coming from an SMTP client and I should be able to connect back to it. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 18471
Soeren Hilmer wrote: As you said the easy part was the implementation. I have already done that (although on my recently downloaded James 2.1.2 source code). For the hard part: Updating of repositories. I assume the change is to be made on HEAD branch, and potentially backported, is this correct? How do I actually go about doing that? I guess that it is not generally possible for everybody to commit code. Migration documentation. Well you lost me there, what is this task precisely about. Are you saying that a new repository structure should be created? If so can you please explain, why that is necessary? Soren, Please email [EMAIL PROTECTED] This is a community project and I'm sure other people will have comments. As for your questions, yes commit rights are restricted. You can read about how to contribute at http://james.apache.org/contribute.html. As for migration, it could either be a document or code that can detect and automatically make the change. The reason it is necessary is to support people who already use James who want to upgrade. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 18471] New: - Attributes on Mail needed
[EMAIL PROTECTED] wrote: Attributes on Mail needed P.S. I will be implementing this, so I will be happy to contribute, if this proposal gets approved. Søren, This idea has been discussed in the past, and everyone likes it... if you want to volunteer to implement it, please feel free! Changes the API is the easy part, and then you'll have to update the repositories to handle this and document how to migrate from the older to newer repository structure. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the future of James
Christian Andersson wrote: I think I have seen this idea in here also that james should support more types of messages then just e-mails and news... Christian, I will join the community over there. I use open office at home and would love groupware available beyond Exchange again. I'll admit, I think turning James into a messaging platform is like saying we should change Apache HTTPD into a stateless connection platform. The more you generalize, the less functionality you can provide. If the community/industry picks a protocol and goes with it, then everyone benefits. That said, you can't *convince* everyone that SMTP (or your protocol dujour) is what everyone should use. This has to happen as a result of some fortunate series of events that prompt enough energy behind a single protocol to get groundwell there and hopefully a dominance. So to that extend, I'm happy to get out there and talk more with people about their messaging needs. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-james/src/java/org/apache/james/util ExtraDotOutputStream.java
[EMAIL PROTECTED] wrote:
+/*
+static public void main(String[] args) throws IOException
+{
+String data = .This is a test\r\nof the thing.\r\nWe should not have much
trouble.\r\n.doubled?\r\nor not?\n.doubled\nor not?\r\n\r\n\n\n\r\r\r\n;
+
+OutputStream os = new ExtraDotOutputStream(System.out);
+os.write(data.getBytes());
+}
+*/
+
You know we actually have junit tests for this... in fact I think this
is the only class that has it. :)
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed Mailet AP v3I change
Noel J. Bergman wrote: For Mailet API v3, I'd like to add: public InetAddress getRemoteAddress(); Both getRemoteHost() and getRemoteAddr() can be implemented based upon an InetAddress object, and when dealing with the IP address, having an InetAddress is faster than having to convert from the String form. Noel, This was pulled straight from the servlet spec, and the reason they give for the two methods is that a container may choose not to resolve the hostnames (to speed performance). If a container does this, then getRemoteHost() returns the same thing as getRemoteAddr(). I think James always needs to do this resolution, so I think it's fine to change this to getRemoteAddress(). -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-james/src/conf james-config.xml
[EMAIL PROTECTED] wrote: noel2003/02/14 20:29:24 Modified:src/java/org/apache/james/transport/mailets RemoteDelivery.java Are you setting sendpartial to default to false to be safe for now? It seems like this should default to true once we can be confident there aren't unexpected bugs. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving JDBC Spool responsiveness
Noel J. Bergman wrote: It consists in appending to the listMessagesSQL query from sqlResources.xml a LIMIT xxx. This way, MySQL does not send back a huge ResultSet which makes the JDBC connection to expire Good thought regarding LIMIT. There is code in JDBCSpoolRepository for limiting the number of messages loaded into an internal working set, but the SQL query still has to generate the large result set. There are two places where we use listMessageSQL: JDBCMailRepository.list() JDBCSpoolReposittory.loadPendingMessages() The former is only used by the POP3 handler when listing the contents of the user's mailbox. The latter is used internally to load the working set. I was thinking that perhaps it doesn't make sense to limit the list given to the POP3 handler, although it would simply require the user to clear out their messages before they could retrieve more of them. Or I could clone the listMessagesSQL to separate the queries, which is probably a good idea for other reasons. Another approach is to use Statement.setMaxRows(int max). Many JDBC drivers can then figure out how to execute this so you achieve the goal of not returning all the records. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James v2.1.1 Release
Noel J. Bergman wrote: Guys, I believe that James v2.1.1 is ready, and I'd like to vote on that release. After that, I'll try integrating the DNS, partial delivery, and other changes. +1 -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An interesting note about memory leaks (was Memory leaks in RemoteDeliverymailet?)
Jason Webb wrote: The good news is that I can still set mail.smtp.from and have no memory leaks. Therefore I'd move that the setting of mail.smtp.user be dropped as a) it causes problems and b) it's irrelevant. Sounds good... yeah, we definitely need to keep setting mail.smtp.from, so I'm glad that doesn't leak. Since we've upgraded to JavaMail 1.3, there are some other proerties we'd want to set... 1. mail.smpt.connectiontimeout (socket connection timeout value in milliseconds, default is infinite timeout) 2. mail.smtp.timeout (socket I/O timeout value in milliseconds, default is inifite) 3. mail.smtp.sendpartial (If set to true, and a message has some valid and some invalid addresses, send the message anyway, reporting the partial failure with a SendFailedException. If set to false (the default), the message is not sent to any of the recipients if there is an invalid recipient address.) Also maybe... 4. mail.smtp.localhost (Local host name. Defaults to InetAddress.getLocalHost().getHostName(). Should not normally need to be set if your JDK and your name service are configured properly.) Maybe have this based on something in config.xml? If possible, could try to set these as well and see if there are any memory leaks?... the 2 timeouts would be good to add to keep the delivery threads robust, as well as supporting partial message delivery (I can't believe people don't scream about this.) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v2.1.1 heads up
Noel J. Bergman wrote: I just posted v2.1.1a6 to the nightly build directories. If this looks good, I'd like to get a vote to release it as v2.1.1. The test build +1... looks good from user's feedback over the past couple of alpha builds. includes logkit v1.2 (not in CVS), but that won't go out unless Avalon votes to release it. I expect that to occur by the weekend. Logkit v1.2 fixes the log rotation defect I had reported to them. Aren't we already using an unreleased version? If this fixes the bug in the log rotation, what's the risk of upgrading from one unreleased to another? Meanwhile, I've updated the web site, so it should be up to date with the changelog, FAQ updates, XSL fixes, etc. Awesome, thanks! -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RemoteDelivery changes
Noel (and everyone), I just thought about the a6 release, and thought it would be good to get in the patches for RemoteDelivery to prevent the memory leak, provide timeouts, and allow for partial delivery. One fixes a reasonably significant bug, and the others are configuration that should just help (and hopefully not create a leak). Thoughts about including it in 2.1.1? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery.java
Jason Webb wrote: Fixes a problem whereby setting the mail.smtp.user property in a JavaMail session causes a memory leak. The mail.smtp.user property is ONLY required for SMTP AUTH and not for general use and therefore is NOT required for James. I've tested this and the headers etc seem to be well-formed and correct. Jason, Your patch didn't come through, but I assume this is just deleting the two lines that put the mail.smtp.user property, right? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An interesting note about memory leaks (was Memory leaks in RemoteDeliverymailet?)
Jason Webb wrote: I've tried the following settings: props.put(mail.smpt.connectiontimeout, 6000); Taken from Qmail - 60 second timeout is fine Great. props.put(mail.smtp.timeout, 120); Taken from Qmail - 20 minute timeout on I/O. This may be less than desirable. Someone may be sending you 1 byte every 19 minutes. This keeps the channel open and acts like a DOS attack. Good enough. props.put(mail.smtp.localhost, stockholm.inovem.com); Not sure this is useful. Doesn't cause any problems, but I think it doesn't add much either. Yeah, let's omit it for now. props.put(mail.smtp.sendpartial, true); This appears on the surface to be nice, but I don't think it is. I send a mail to 2 people, 1 address gives me a 5xx error (mail box full for example). Which one succeed? Do I try again later? Do I end up sending the same message many times (once per attempt) to the user who I can send to? You know this because the SendFailedException will enumerate the addresses that did not receive the message. Right now if I send an email to 14 hotmail accounts and one of them is bad, none of the recipients gets the message. That isn't very fun. I'm not sure, but I think this may be a bad idea. Yeah, possibly easy... I would agree to at least hold off until post 2.1.1. It also leaks memory slowly and persitantly. My current opinon with JavaMail's SMTP transport is to keep it simple. So I'd recommend NOT using it. Yeah, if it's leaking... In summary add the following: props.put(mail.smpt.connectiontimeout, 6000); props.put(mail.smtp.timeout, 120); Ok, will commit momentarily. We could think about making these configurable at some point in the futue. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail settings for RemoteDelivery (was about memory leaks)
Noel J. Bergman wrote: Seems to me that it makes sense to have defaults (NULL to not set the value) for each property, and configuration entries to override. If we set this to null, then the timeouts are infinite, which I don't think we want... I think if we try to deliver to a server that's too slow (doesn't respond to IO for 20 minutes), we want to disconnect and let that thread try to deliver someplace else. This might also explain why I see the # of active delivery threads go down over time... some socket gets corrupt and Java doesn't get a solid timeout/close, and that thread is stuck. I think you ALWAYS should have some timeout for a server app if you're tying resources to it. With respect to mail.smtp.sendpartial, I think that it is important to use it. See the API docs: If set to true, and a message has some valid and some invalid addresses, send the message anyway, reporting the partial failure with a SendFailedException. If set to false (the default), the message is not sent to any of the recipients if there is an invalid recipient address. RemoteDelivery already has the code for handling the SendFamiledException, and processing the getValidSentAddresses list. But, again, this can be a configuration setting. I just think that it should probably be true in most cases. I think this changes behavior, and the implication is not really tested. In theory this is a great improvement I'd like us to make, but for the 2.1.1 pending, I wouldn't include this. Most of our test structures can't really check this, so I think we'd need to release this into alpha use for a while and get feedback before committing to it in a release. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 16834] smtpserver.log doesn't show Message-ID
Noel J. Bergman wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16834 This change would need to be made in multiple components in order to be consistent. Right now we use Mail.getName() (typically a local time-based value) for logging. Should we use MimeMessage.getMessageID() instead? No because a single message with a given message ID... a) might be received multiple times (some servers send the same message with different recipients in different sessions) b) could get split into multiple queues, i.e., this message gets delivered to devtech.com and lokitech.com, so it gets stored in the outgoing spool twice, and we'd want to log that devtech.com wasn't working and not confuse it with the version that went to lokitech.com just fine. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution of jar files illegally?
[EMAIL PROTECTED] wrote: James currently includes JavaMail, Activation, dns-java and Junit non-Apache-jars without licenses in CVS. Dion, We have already made an inventory of what jars we have potential license conflicts with. We're aware of what conflicts we have, what we have permission from authors to use, and what is valid. There are some jars that we bundle because of running under Avalon, and we'll rely on Avalon sorting out and telling us what of those we should bundle. Incidentally, JUnit is considered the IBM license, which in the emails going around has been dictated as compatible with ASF policy. The only really at risk files right now are JavaMail and Activation, both which DO have license files in CVS, and once more, it's not completely settled as the discussion is still active. Certain board members has stated there is a problem, and so we've proactively reviewed the issues and are prepared to act when the foot drops. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution of jar files illegally?
[EMAIL PROTECTED] wrote: James currently includes JavaMail, Activation, dns-java and Junit non-Apache-jars without licenses in CVS. By the way, we're not governed by the Jakarta PMC anymore... if you want to send it to the James PMC, you can send it to [EMAIL PROTECTED] (private, PMC members only), or [EMAIL PROTECTED] (public, PMC-related issues). And please subscribe to these various lists before you send to them. Thanks. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Noel J. Bergman wrote: Serge, According to Alex's messages, he has spoken with Bill and there seems to be some willingness to address whatever issues Alex raised. We'll have to await details from Alex on those issues. In any event, my point about migration is simple. We won't preserve two implementations of the mail repository for the interim. But during initial development, we don't have to change the spool implementation, and we really don't need to change the ToRepository mailet, which is used to dump spam and error in the stock configuration. At the beginning, the only things that we HAVE to change are the LocalDelivery and POP3 handler components. 1. Change LocalDelivery and POP3 to use JavaMail stores. Use one of the existing JavaMail stores. 2. Test, tweak, test again. 3. Change ToRepository Mailet 4. After the spooler is replaced, we can remove the current mail repository interface. As I understand it, we also convert our implementations to JavaMail stores. This incremental development is intended to make sure that we have a working server throughout the entire process. Right, so basically just removing (and/or making abstract) the MailRepository interface, removing the definitions of MailRepository URLs in config.xml, and then fixing everything that uses that directly. I'm a bit leary we're missing something, but sounds like a plan. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Serge Sozonoff wrote: Hi Guys, I have been looking into this a little more and I have done some local testing (I now store mail through JavaMail (Maildir)) however there is something I am not sure about. What sort of a file based JavaMail Store are we thinking of using as the default for storing local James mail? Maildir is nice but it does not work under Windows. JProof Local Message Store should work but I am not sure what the license implications are. ICE MH JavaMail Provider (http://trustice.com/java/icemh/index.shtml) Others and as far as a JDBC Store goes, it looks like we might need to write our own Any thoughts on this? I'm thinking (at least for porting reasons), we'll want to implement a JavaMail Store to access the existing (legacy) file mail repository. This may also be a fast, non-portable implementation... whether we pick that long-term as the default implementation is another thing, but this is what I figured we'd do in the short-term. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks in RemoteDelivery mailet?
Jason Webb wrote: I've been doing some testing with 2.1 (jdk 1.4.1, Javamail 1.3) under Win2k. I've constructed a testing that sends 5 mails/sec into James. The messages are destined for another remote server (relay). Running the VM with -Xloggc on there is a slow and persitant memory leak. James is keeping up with the incoming mail volume quite easily. Even when I stop the incoming mail, the memory still persists (and is never freed). Lacing the code with periodic GC's never frees the memory either. Any suggestions? That isn't really detecting memory leaks... normal (non-leaking) Java code will gradually allocate more memory to the heap. The question is if there are incorrectly maintained references over time, and you'll have to use a profiling tool to determine that. I'm not saying there isn't a slow memory leak with any part of James, just that -Xloggc won't tell you either way. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
I'm pretty sure Bill (and the spec group in general) won't want to adjust the JavaMail API too much (I think this has been asked before). They've designed it for client use, and I think they're happy with those design approaches. But if you're talking just implementation and room for improvement, then they probably would be open for suggestions. Perhaps figure out what we want to change most, and then sort out how to address it. Noel J. Bergman wrote: For the internal migration, I propose we would only use JavaMail in LocalDelivery and the POP3 handler. That allows us to introduce JavaMail mail boxes without breaking the rest of James. At the appropriate point, we can change ToRepository and the rest of the code. Basically, it means that work can start on this process now. Are you suggesting we maintain two implementations of the mail repository during this interim? Can you go into a bit more what you mean by this interim migration step? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDI Mailet Configuration
Noel J. Bergman wrote: there seems to be a number of ways to achieve the per-mailet context thing. It you want, take a look at org.apache.naming (under the tomcat project). I think that you'll find that per-mailet would be a real complication, and not necessarily desireable. In Tomcat, the Servlet Specification specifies that resources are per-webapp, and each webapp has its own classloader. ref: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/ apache/naming/ There is another copy elsewhere, part of the TC5 CVS structure, but the one above may be the better place to start for now. We can ask Remy for advice. Actually, if we decide to adopt JNDI, I'll ask Remy if he could help us out a bit (org.apache.naming is under Tomcat, but is supposed to be independent, and available for all projects that might want it). I agree that per-mailet contexts are very difficult, and wouldn't want to take this to the degree Aaron has with having everything function through JNDI. The more I've thought about it, the more I like using JNDI for generic resources. Basically we can rely on the J2EE spec on how to do this, just as the servlet API does so. This would give a standard way to have access to logging, datasource, advanced app configuration, and other resources via JNDI. I agree with Stephen that the servlet API is perfect, but I do think it did achieve a good balance of simplicity vs. complexity and gives people a level of familiarity when getting into mailets. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Noel J. Bergman wrote: Serge suggested JavaMail as the message stores interface. I'm not sure what the performance is, but we do have the JavaMaildir author to help out, and I'm sure that he is familiar with the performance. Basically I mean to suggest that we take the existing file and database repositories, and rework/add necessary methods to make them implement the JavaMail javax.mail.Folder (maybe also implement javax.mail.Store). I think this is a good idea for the following reasons: 1. familiarity because it's a standard API 2. makes our store implementations more re-usable (our Store implementation could be bundled as a separate jar to let a servlet app access the database store) 3. makes it easier to drop in other mail store implementations and more importantly... 4. If you look at the functionality/methods we need to add to our existing mail repository interface to let it support NNTP and IMAP, you basically have javax.mail.Folder. Also, please note that we're not considering JavaMail for the spool. The spooler needs to be high performance, but it will only move the Mail object, which have a looser reference to the MimeMessage. The MimeMessage wouldn't move as much as it does in the current scheme, cutting down on that overhead. Agreed... spools require the Mail object, and there's the whole spooling logic itself which most mail repositories don't need, and there's the desire to have that implemented separately. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
Aaron Knauf wrote: I have no opinion on whether or not it is a good idea to treat the Mailet API as a distinct entity. If that is what others want (and I think it has already been decided that they do), I'll get on board. However, Mailet portability is a *must* if we are to do this. Aaron, You'll see in the Top-Level-Project proposal, one of the motivators to do this is to create subprojects, namely a project to house the separate mailet API/specification, and also a project to house mailet implementations. So yes, a big reason why we're james.apache.org is because we've decided we want the Mailet API as a distinct entity. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
Aaron Knauf wrote: I have no opinion on whether or not it is a good idea to treat the Mailet API as a distinct entity. If that is what others want (and I think it has already been decided that they do), I'll get on board. However, Mailet portability is a *must* if we are to do this. You'll see in the Top-Level-Project proposal, one of the motivators to do this is to create subprojects, namely a project to house the separate mailet API/specification, and also a project to house mailet implementations. So yes, a big reason why we're james.apache.org is because we've decided we want the Mailet API as a distinct entity. Yeah, I know this, Serge. The point that I am making (in the statement that you are replying to,) is that I am truly ambivalent about this decision, but quite happy to support it. The point the I was making in that post, was that (IMHO) there is no point in going down that road without achieving the degree of portability in Mailets as has been achieved in servlets. Sorry, I quoted the wrong part of your message, losing some context to your comment. Earlier in the message you had commented that you felt it was unclear whether this was decided, and that's what I meant to respond to. If nothing else, I wanted to clarify that it has been decided, since you indicated you were somewhat uncertain about that. So, we're glad to have you on board! :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
Nicola Ken Barozzi wrote: Mixing my views and the results of the James discussion, I have come to the personal conclusion that it would be cool to have: - mailet API indipendent on Avalon * very lightweight, no concerns about config, logging, etc * it makes possibly unportable mailets - mailet Avalon profile * mailets that are also Avalon components, thus gaining Avalon features * mailets can be more portable and feature rich 1 cent's worth... I like this and as I've understood the Avalon framework better, I think this is something we can do with James without a lot of sweat. Like Nicola said, we have Avalon independent mailets that function just like the API. Then we allow James to support mailets that implement the Composable, whatever-able interfaces of Avalon... James can pick up on these and call the appropriate methods on the mailet during the mailet lifecycle. I like this because.. - it keeps the mailet API lightweight, - it recognizes that the mailet API should not handle all needs of all mailets, - it allows Avalon-aware developers using James the ability to leverage Avalon, and - it spurs the creation (within James) of more advanced mailets (dependent on Avalon) that can then give more context and make further mailet API discussions more productive. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Subsystem (was Mailet Configuration)
Aaron Knauf wrote: I disagree, but rather than go into the why's and wherefore's here, I will finish off the UML that I am working on to ensure that we are not just misunderstanding each other. I will however, say this: I think that access to some form of structured config for mailets is important. Plugability of config implementations is not something that needs to be reflected directly in the Mailet API, but can be a value add for a particular container implementation. (Like ours!) Ok sure, just as long as it's not in the mailet API or specification, that's cool with me. Dynamic reconfiguration must be supported by the configuration subsystem if it is to exist at all. Someone listed this item on the wiki as being a desirable for V3. It is quite a lot simpler not to do it. Yes, I think dynamic reconfiguration is a must. IMHO, the key to doing this successfully is to provide a system that is simple by default, but powerful for those that wish to put in the effort and dig a little deeper. Log4J is an excellent example of this concept. It takes a 4 line config file and single line of code to get basic logging to work. However, if you want more, you can make your logs get up and make coffee! I agree, and I think your log4j reference is a good example of what I'm shooting for... let the application developer do whatever he or she wants using all the options available with Java. I'm just looking to provide rules for a mailet container, i.e., how you could write some Java to process email messages. This doesn't need to (and shouldn't IMHO) include much about logging, databases, configuration, etc... So I like to keep it lightweight and focused on the specific problem of email processing. Also when in doubt about the appropriate level of complexity, I tend to fall back on whatever the servlet API deemed appropriate. Servlet apps haven't shown much limitations with that API (either too advanced or too lightweight), and it's fostered numerous implementations. So for the sake of Mailet API and specification, if in doubt, leave it out. Then figure out a way how a specific mailet container like James could offer the necessary features on its own. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] v2.1.1 release
Noel J. Bergman wrote: I am withdrawing this vote due to a defect in the file system repository. I believe that I have a fix, which I am uploading as part of v2.1.1a5. This is kind of a silly question, but what happened to alphas 1 through 4? I guess you have been building them and I just hadn't noticed. Nice catch with the synchronization woes, btw. Since I have to do that, anyway, do we *want* to try the new dnsserver code? Is anyone using the DNS code checked into HEAD? I would like to since it promises to reduce the number of problems caused by people not configuring the DNS servers, but unfortunately can't commit to testing this in the next week. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP announcement
Noel J. Bergman wrote: So are you saying that you don't want me to send out the Press Release? You want me to just post it to you? I'm just saying it took many hours for our office manager to figure out who to send the press release to and send the announcement off to all these outlets, and we'd be happy to do the same when the 2.1.1 press release is ready to go out. I have a somewhat longer list than below, with either e-mail addresses or URLs. I'll post it to pmc@ (I don't feel like contributing to spam harvesters). I'll take the list you send to PMC and ask our office manager to research those as well and maybe retroactively send out a few more announcements about TLP. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mailet sub-packages
Noel J. Bergman wrote: Actually, I think so, but perhaps not the same way that you anticipate. I'd like to see us ensure that the base Mailet package is protocol neutral. Protocol neutral? What does that mean? I assume we keep it focused on spool processing (messaging in general) and MimeMessages. Are you suggesting we decouple from email addresses? What else would you change? The current package has started incrementally tying itself to SMTP and MIME. I'd like us to take a similar approach to the servlet and servlet.http packages. servlet and servlet.http? If this was done in the name of protocol neutrality, it has to rank up there as one of the worst design decision in the history of Java APIs. It's one of the most widely adopted APIs yet NOBODY has used with another protocol aside from http... -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TLP announcement
Noel J. Bergman wrote: Ouch! I hope she or he didn't have to replicate the effort I had already done (you could've asked :-)), and I very much appreciate the donation of your corporate resource. :-) Well, we also sent it to a lot of (more self-serving) announcements to business-ish magazines in our region. :) Thanks for the list too... we're getting the extra announcements out there. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] v2.1.1 release
Noel J. Bergman wrote: The [EMAIL PROTECTED] list IS open to everyone. We're talking about how best to use it, but my view is that it should be relatively light traffic, and used for most PMC and other project related, organizational, discussions. Like do we want a new mailing list for the MailetAPI. Like splitting the CVS repository into james-server, james-mailet and james-site, and the discussion of why. And, hence my aside, that is probably where Release Votes should take place. As I understand Danny Angus' position, that general@ be used for most PMC business so that it *is* out in the open, those are compatible views. Everyone seems in agreement that general@ is for open PMC-related discussions, and Noel's unearthed some Apache rules that has created confusion as to whether the PMC needs to be involved in the release, i.e., bless it for distribution on behalf of the Foundation. That said, even with the confusion over the PMC's involvement, it is still the committers who decide when to release and then seek PMC approval. Voting guidelines indicate all contributors are encouraged to participate and committers have the ultimate say in the decision. Also a committer casting a +1 vote indicates he/she is willing to support the release. Then per the sentence that's started the confusion... Once a release is approved by the Committers, the Project Management Committee can authorize its distribution on behalf of the Foundation. (again IMHO) Votes for releases should still be made by that sub-project's community/contributors, ergo on the appropriate dev list. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: IMPORTANT: Do not commit to v2.1 branch ...
Noel J. Bergman wrote: ... at least not until we talk about it, or v2.1.1 is tagged, whichever comes first. :-) I just committed Sergei's DNSServer changes to HEAD. I did *not* commit to v2 branch, because I think that we should vote to put out v2.1.1, and then I can apply Sergei's updates, and a couple of other fixes, to v2.1.2 for release in a few weeks. Do you think the latest round of DNSServer changes are significant enough to push into a next-release? We already have DNSServer changes between the 2.1 release and now, so moving from what we had to 1.3.1 vs. 1.3.2 doesn't seem that significant to me. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: IMPORTANT: Do not commit to v2.1 branch ...
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] But none of those DNS changes are in the v2.1 branch. None of them have been tested anywhere as far as I know, yet. Hence my thought to get out the v2.1 branch, with the already tested updates, such as JavaMail, JAF, NNTP, and log rotation, and put the DNS changes into the next drop. Thanks, I was reading the diff's on the changelog too quickly and thought the DNS server changes were in the 2.1 branch too. +1 from me for the freeze and release then. Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Subsystem (was Mailet Configuration)
- Original Message - From: Aaron Knauf [EMAIL PROTECTED] Hi Danny, The format you suggest certainly allows for multiple matchers and better matcher configuration. However, it still leaves us with unstructured name/value pairs. There have been a number of requests for structured mailet configuration. I don't think the level of configuration you're proposing needs to be included as part of the mailet container. IMO, the container should load an application, and if the application has complex configuration, the application should handle configuring itself. I think many of your suggestions unnecessarily raise the bar for mailet container implementations and is looking for more than just a container. I think name-value pairs are a good addition to matchers, and I think it would be good to have a way to reference files bundled with the mailet classes (as part of the application files), either with getResource() or maybe getRealPath(), something along those lines. Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Excalibur/Cornerstone/James woes
Stephen McConnell wrote: I now have two james builds locally on my machine: 1. James based on Peter's derivative of 2.1, CM/SM migration and Cornerstone candidates in place. This is working fine. Some problems were occuring in the test case but we finally narrowed this down to a bug in the test case (the test delete's the user before the spool completes its work, resulting in email in the spool that contain invalid reciipient addresses). 2. James based on HEAD + CM/SM migration + updates for Cornerstone candidates. This version is doing the 500 error on commands and getting itself into a loop. However, it's fully synced with the HEAD and can be committed. I suggest we go ahead and ties build (2) into head and sort of the loop/500 problem from there. Sounds great... this loop bug is one I introduced in HEAD and mean to sort out soon (was supposed to this weekend, but long story... it will be fixed soon). There is also the question of migration of excalibur-xxx packages to commons-. This has been taken care of for the pool package (commons-collection). There may be a coupe of other packages that require transition. Also, excalibur-cli (used in Phoenix and a couple of Excalibur projects) can/should/could be replaced by commons-cli. I would support migrating to commons libs as I'm more familiar with them and I think commons does a good job with release management. Especially if it means the Avalon community has less to worry about releasing in the short-term. Also, for DBCP we'll be bundling commons pool anyway, so one step there. i.e. Things are already looking comfortable - and within a few weeks we should be able to freeze the release targets and validate things across containers, applications and external projects followed by formal vote/release/publication. Great! Yep - its in progress. Some of the updated in Excalibur are used extensively in Cocoon and some of guys on working on the Avalon/Cocoon front in much the same we as I'm trying to get James/Avalon in sync. Sounds good. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Build process: was http://james.apache.org
Danny Angus wrote: I'd like to see a formal proposal, so we can have a synopsis of why we need to change things, debate the benefits and drawbacks of competing systems are, and, if we don't reach concensus, a vote. I'm susceptable to persuasion on all counts, including retaining the status-quo (ant xslt) and would like to hear someone make the case for change. Otherwise it would seem to be change for change's sake, or keeping up with the Joneses. d. This is somewhat perpendicular to this, but could have an impact... The tests we have right now (they don't compile, but that notwithstanding) are functional tests, not unit tests. So last night I created a new directory and build tasks for junit tests on the individual classes in James. This was primarily driven by wanting to unit test ExtraDotOutputStream, and we can use this test build task for over unit tests as they get written. Adding this prompted me to do some renaming in the build.xml since between the multiple javadocs, multiple source code locations, etc..., the naming conventions were becoming somewhat confusing. For example, the intermediate build directories are named build.[something] while the source directories are named [something].dir. Anyway, I'm pretty sure I've broken where the javadocs get created, but if we're going to just scrap all of that, then maybe it's not important for me to fix it before I commit. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Build process: was http://james.apache.org
Danny Angus wrote: Anyway, I'm pretty sure I've broken where the javadocs get created, but if we're going to just scrap all of that, then maybe it's not important for me to fix it before I commit. Its pretty important for the web-site though. Ok, I can sort that out before committing. Just didn't think we'd be updating the website with HEAD before we moved to Forrest or whatever the decision is. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Stephen McConnell temporary commit privilege
Danny Angus wrote: I'd like to propose that we offer Stephen temporary commit access to James to let him apply his *very welcome* update to James to bring the HEAD up to date with Avalon. d. +1, although would like to have temporary defined... until a specified date (couple of weeks?, 3 months?), until a milestone is reached (ACR?, James 3.0?), or whatever. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
TLP announcement
We've sent around a TLP announcement to every place mentioned on the listserv (leading up to the 2.1 PR), including... Cnet ZDNet ServerWatch JavaWorld SLASHDOT IBM Devworks TechTV.com Onjava.com OfB.biz Apache Java DevJournal Open Directory TheServerSide JSPInsider JSPIN JavaLobby JGuru.com JavaRanch Open Enterprise eBizQ We've got all the info on where to send the news for each, so when we do the 2.1.1 release and want to blast that out, we can handle that as well. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Log File Rotation
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] James uses Avalon's logging mechanism. See the documentation for the FileTargetFactory, and then adjust SAR-INF/environment.xml accordingly. ref: http://jakarta.apache.org/avalon/excalibur/logger/api/org/apache/avalon/exca libur/logger/factory/FileTargetFactory.html [switching to dev] Shouldn't we change James log files to rotate by default so they can't grow unchecked? Is this logger feature available in what we're using with the 2.1 branch? I would +1 to changing it to rotate for the 2.1.1 release. Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Excalibur/Cornerstone/James woes
Stephen McConnell wrote: There are two scenarios I think you should be considering: 1. a James releasse scenario - this is where you referencing relased jars 2. a James build that is based on the current CVS of Avalon based on Gump I agree with 1, but not with 2. I don't think it does James any good to treat the Avalon jar dependencies any different than we would other libraries. I also don't think it does Avalon any good in the long term. I know it's not ideal, but for me the big API change that happened in the Avalon project (Component - Service I think it was) is not that big of a deal. What made it a big deal is that there was not much of a clear release beforehand, I don't think any release (yet) after the fact, and I haven't heard of a changelog or HOWTO to help users make this change. Codebases change all the time, and I have to believe the Avalon committers did what they felt was a right by moving to a different naming/design pattern. But with software engineering, you need software development practices to support it. As an example with another open source project, we use Netsaint for monitoring. This was basically disolved, and the authors went and refactored the codebase into Nagios. I don't mind that Netsaint isn't supported or that my large conf file needs to be completely rewritten... because there is explanation of what happened, clear releases so I can stay with Netsaint until we have the time to migrate, and I've heard rumor there is a conversion tool out there to help you migrate your conf file. These practices allow me to handle the change, and this is better than having Nagios people who are very willing to help because in the end, I know my code/system best and need to understand how to apply it. These software development practices allow the software engineering to happen with less restrictions. For the Avalon community, having James build against Avalon and have Avalon committers help James with that is a misdirection of resources (IMHO). You will get James working on it, but at the expense of other activities that can slow adoption of the codebase (which ultimately James needs to see happen as well). So, I think Avalon should be treated just like other dependencies... people can propose updates, the community reviews it, and then if approved, the update happens. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Excalibur/Cornerstone/James woes
Stephen McConnell wrote: Danny Angus wrote: 1. a James releasse scenario - this is where you referencing relased jars 2. a James build that is based on the current CVS of Avalon based on Gump I agree with 1, but not with 2. I don't think it does James any good to treat the Avalon jar dependencies any different than we would other libraries. I also don't think it does Avalon any good in the long term. I agree with Serge, despite our close relationship with avalon I think we *must* work with released software only, But your not - your build against and distributing against an unrelease cornerstone package. Well yes, and I think this is again why we don't want (and would like to no longer be) doing #2, i.e., building against what's in CVS... because we end up using unreleased code and are otherwise not supported. So now it's a question of getting Avalon to make a published release, and then get a proposal from someone to do the upgrade... and as you imply, since we're not building against a release, I don't think you'd get much disagreement (and I hope we've been supportive of your preparatory work to have that happen). If there is cornerstone code we need that isn't getting released, we can absorb that code into the James package so that we can determine it releasable, and then if Avalon does release it, we can review handing over responsibility for that functionality back to them. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH - smtpserver acceptOnlyLocal and doReverseLookups options
I think this was already mentioned, but in general the James project has taken the approach of accepting first and deleting during processing. Especially as these doesn't seem to be a high traffic/likely settings (you're not going to catch a ton of spammers), this seems like a job for the mailet API. You can already handle deleting messages from bad networks by using existing matchers (HostIsLocal) and otherwise bit-bucket it using the NullMailet. The reverse DNS is a bit more interesting... I would take that code and make it a matcher for who we do most of these rules. We also have bundled (but not enabled by default) a matcher that checks that there is any entry for the deliverer's hostname called SenderInFakeDomain. What it does is if I get an email from [EMAIL PROTECTED], the matcher checks to see if there are MX/A/CNAME records for bar.com (to see if we could send a bounce to that server if necessary). Just thought I'd mention it as another somewhat useful spam deterent. Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com/ - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 4:23 PM Subject: PATCH - smtpserver acceptOnlyLocal and doReverseLookups options Index: james-config.xml === RCS file: /home/cvspublic/jakarta-james/src/conf/james-config.xml,v retrieving revision 1.44 diff -u -r1.44 james-config.xml --- james-config.xml 18 Jan 2003 23:22:34 - 1.44 +++ james-config.xml 23 Jan 2003 21:25:10 - @@ -406,6 +406,26 @@ verifyIdentitytrue/verifyIdentity -- + !-- Uncomment this if you want to only accept recipients in the local domain. -- + !-- Note that leaving this out will cause all recipients to be valid, but -- + !-- messages to other domains will still process per the above configuration, -- + !-- usually to the spam log. Leave this off while debugging, but if you find -- + !-- a huge number of SPAM messages to other -- + !-- you might want to turn it -- + !-- + acceptOnlyLocaltrue/acceptOnlyLocal + -- + + !-- Uncomment this if you want to ensure a reverse DNS Hostname exists -- + !-- for the IP addresses of incoming connections. Most legitimate email -- + !-- will have a rDNS hostname defined, but often the casual spammer will -- + !-- not. Note that this will cause connectivity problems if a sender's -- + !-- hostname cannot be determined by IP, or if the DNS service is-- + !-- -- + !-- + doReverseLookupstrue/doReverseLookups + -- + !-- This sets the maximum allowed message size (in kilobytes) for this -- !-- SMTP service. If unspecified, the value defaults to 0, which means no limit. -- maxmessagesize0/maxmessagesize Index: SMTPHandlerConfigurationData.java === RCS file: /home/cvspublic/jakarta-james/src/java/org/apache/james/smtpserver/SMTPHandl erConfigurationData.java,v retrieving revision 1.3 diff -u -r1.3 SMTPHandlerConfigurationData.java --- SMTPHandlerConfigurationData.java 14 Jan 2003 13:41:54 - 1.3 +++ SMTPHandlerConfigurationData.java 23 Jan 2003 21:04:37 - @@ -54,6 +54,29 @@ boolean isVerifyIdentity(); /** + * Returns whether the service requires connecting + * IPs reverse DNS entry (the Hostname) to exist. + * If the reverse DNS hostname entry for this IP + * addressdoes not exist, and this is true, the + * connection is terminated. + * + * Legitimate email servers have a reverse DNS entry + * for their IP address, so this helps prevent SPAM. + * The default entry is Bfalse/B. + * + * @return true if reverse lookups are + */ +boolean isReverseLookupNeeded(); + +/** + * Returns whether the service only accepts recipients + * with domains local to this server + * + * @return whether only local recipients are accepted + */ +boolean isAcceptOnlyLocal(); + +/** * Returns the MailServer interface for this service. * * @return the MailServer interface for this service Index: SMTPHandler.java === RCS file: /home/cvspublic/jakarta-james/src/java/org/apache/james/smtpserver/SMTPHandl er.java,v retrieving revision 1.42 diff -u -r1.42 SMTPHandler.java --- SMTPHandler.java 14 Jan 2003 13:41:54 - 1.42 +++ SMTPHandler.java 23 Jan 2003 21:04:41 - @@ -328,23 +328,38 @@ out = new InternetPrintWriter(new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()), 1024), false); +boolean bLetThemIn = true
Re: Excalibur/Cornerstone/James woes
- Original Message - From: Stephen McConnell [EMAIL PROTECTED] No. I'm not suggesting *using* unrelease code. #2 is getting the Gump descriptor for James sorted - that does not effect you day to day work. Right, I understand your intention. I think I see that you're treating Gump as a step towards having that better Avalon release process, so that sounds good. My concern is that we end up relying on this compilation check *at the expense of other support*. As an example, the (very frustrating) file repository change that started numbering instances, which didn't change the API and would not have been caught with Gump. I'm looking to Avalon to build a better release process so more changes could be clear to James. I'm also slightly concerned that Gump would give James or Avalon developers false confidence to start making changes that could have unintentended consequences or use code that in the end wasn't going to get released. I would really like to sucessfully validate the candidates against James before proposing releases. Ok. I've updated corenerstone so that each component that James is depedent on has its own build procedure and release version. This means that (a) your not carrying around code for components you are not using, (b) your migrating to something that is supported, and (c) furture evolution of components can be managed properly. Ok. I really appreciate your changes as it would be great to get on an Avalon release, and if an early warning system can help you support Avalon and make it easier to propose upgrades for James, then that's great. I'd rather not be one of those people getting the early warning messages though if possible. :) Anyway, I think we're both heading in the same direction... we want James on an Avalon release (and cleaner code and more avalon adoption). Seems like most of our chat was how we would prioritize achieving those differently, but they're pretty close in the end. Again, much appreciated. Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: http://james.apache.org
Danny Angus wrote: The website is now here http://james.apache.org and the site files on daedalus have been moved. I haven't tried cvs up yet. d. Thanks!! Looks great! -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logo competion..
Danny Angus wrote: I remember somewhere some suggestions for a new logo, I was thinking that perhaps we should have a competition. New name, new look kind of thing. Thoughts? I like the current logo... someone here (Randy Stanard) actually designed it, so I'm probably a bit biased. He's been doing more open source logos lately, like Apache Rivet (http://tcl.apache.org/rivet) and now Apache TCL wants him to do one. He also submitted a ton of logos for the POI competition and finished in spots 2 through 6 (split his own vote :) Anyway, my 2 cents. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logo competion..
alan.gerhard wrote: not too sure about a new logo, but definately more variations; was looking for the /Powered by JAMES/ logo, the 'smaller' logo, for example, to make it easier to place them through various sites. We had a smaller logo (not necessarily a powered-by) that we used on http://www.mailhive.net that you could grab (90x67 pixels). I could ask Randy to put together a powered-by logo based on the current one, but often these get kind of ugly because you're jamming in extra text into an already small area. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logo competion..
Danny Angus wrote: would he like to make the feather colours match the new apache feather colours... at all..? Sure, I asked him to see if he could make a powered-by version this morning, and can ask him to put out the big one with the new apache feature colo[u]rs. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache James... HORRAY! :-D
Kenny Smith wrote: Awesome! :) Nicola Ken Barozzi wrote: Congrats guys, in case you've missed it ;-) you're a TLP at Apache @see http://www.apache.org/. We just posted something to slashdot about James becoming a TLP, but their site is running like molasses (*)# Perl. :) -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Noel J. Bergman wrote: Again, if someone can demonstrate the List methods that embody this presumed contract, I'm happy to listen. The fact that we don't use methods other than those found on Collection belies the necessity, in my view. I'm sorry you feel you had to write so much... again I'm willing to leave it as a Collection since you're so adamant on this point. As to your last point, read the first line to List's JavaDocs... it says it is an ordered Collection. To me as a Java developer, an ordered Collection with duplicates is a List... that's all the Collection API provides. I'm sorry, but I haven't heard a negative implication of allowing index references. Please let's just let this rest. There's no sense spending this much energy talking on this topic when there's code and documentation that everyone seems comfortable solving (sorry, don't mean to be a last word freak). -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Serge Knystautas wrote: Please let's just let this rest. There's no sense spending this much energy talking on this topic when there's code and documentation that everyone seems comfortable solving. And to follow that, a community where everyone agrees isn't feasible... (let's focus on where we do agree and build on that rather than go into long diatribes on where we don't). -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Noel J. Bergman wrote: If the question is whether the interface should change, there ought to be reasons. So far, I have not seen any was my point. Ok, I just meant that you can't reference the implementation if we're talking interfaces. I understand, and I am all for meaningful contracts. My point is that a Java Collection is not unordered. It can be either ordered or unordered, based upon the implementation class. Yes, this is my point... we should not leave it up to the implementation as to whether it is ordered or not. Agreed, a Collection is ordered or unordered. And a List is, An ordered collection (also known as a sequence) as you quoted from the javadocs. Since the MX record query produce an ordered set of IP addresses, I'm saying the interface should return an ordered collection. The ListIterator also adds backwards traversal, list mutators, and index operations. Backwards trasversal is a consequence of having order. Mutators also are a consequence of order. Index operations are a consequence of having order while allowing duplicates. None of these List behaviors are necessary parts of the client contract we need to expose as far as I can see. All that we require is that the elements be ordered according to our application (RFC) defined scheme. But by changing the interface to a List, we preclude the ability to use any other type of ordered collection. The only other ordered collections I know of aside from List is the SortedSet. If we can determine whether we need to allow duplicates, we can choose one or the other. I'm not looking to enable methods that shouldn't be allowed on this result, but for the same reason that we return a Collection instead of an Object, if we have certain characteristics that we know should be present in the result, we should pick the appropriate interface. I hope I am clearer now. Yes, and I hope I am as well. -- Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Serge Sozonoff wrote: Hi Aaron, The James DNSServer class has a custom Comparator and does the ordering. It returns an ordered list. Yeah, the DNSServer code uses a Vector as the underlying implementation and a custom comparator. Then all we really need to do is change the method contract to maintain that this is a List and not a Collection. As for SortedSet vs. List, it logically makes more sense to have it as a SortedSet since it wouldn't make sense to have multiple MX records to the same IP address. But you never know, I don't think DNS could enforce this... I guess we just do extra checks as we add the IP addresses and avoid duplication. I might just make it a List to avoid working this out... the benefit of making it a SortedSet seem minimal to me. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Harmeet Bedi wrote: At the moment Serge S's code is working so it does not impede anyone. I could roll it back or one could apply additional improvements that Serge S sends. Let me know if you prefer rollback. Yeah, I think it's functional and just has a design flaw (a static reference or something), so I would just apply new patch(es) as they're available. Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Steve Short wrote: You can use multiple MX records to the same IP to improve performance by allowing James to use multiple concurrent connections to the same mail server. IIRC Javamail has some per connection synchronisation and multiple MX records can be used to enable multiple connections. So do you think we should collapse these and return a SortedSet, or just return all possible servers using a List? Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JIRA for James
Nicola Ken Barozzi wrote: Not really, I was addressing your comment about IssueZilla that Collabnet uses (Tigris is of Collabnet). Yeah, that was Harmeet's comment actually. As for Scarab, it will most probably be usde because Pier, the Bugzilla guy, is more than fed up with admininstring Bugzilla, and will change as soon as he can to a better system. AFAIK there is no other OS bug tracking system other than Scarab... I can definitely sympathize with Pier. When I mentioned JIRA to him privately, he sounded pretty stressed in general from dealing with this. :) OpenSymphony is a smaller but similar high-quality Java open source project depot (similar to Jakarta), and I think the affiliated business (Atlassian) has produced something a lot better than Scarab in JIRA. It's not OS, and some have espressed that they would feel more than uneasy to use it for all Apache. Yeah, there's a lesson here in how to make a profit on top of the open source market... CollabNet is doing something very similar to Atlassian in that CollabNet has proprietary extensions that they will use to have a sellable version of Scarab. Meanwhile, Atlassian didn't open source the core but justs licenses it for open source use for free... just interesting to see how the different strategies are playing out. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jabber (Instant Messaging) Support
Noel J. Bergman wrote: Alexis, I'm posting this to summarize our discussion. Please join [EMAIL PROTECTED] with whatever e-mail address you want to use (mailto:[EMAIL PROTECTED]), and you'll be able to reply to the list. You have indicated that you'd be pleased to bring JabberServer to the Apache James project, and work with us to incorporate Jabber services into James. This would be an on-going project, not a simple port and drop. We all agree that integrating Jabber messaging with the other services provided by James would provide numerous benefits for many users. Jabber would be a peer of the other James messaging services. We are working on a new unified user data model, and all of the services ought to be able to take advantage of the unified model. The Jabber Service would fit into our class hierarchy, use our connection management, DNS support, storage, and other Avalon components. I understand that you have some issues with XML stream parsing. Your comment was the server SAX parser read chunk of data from the client stream with fixed size (instead of element by element). And sometime the client wait for a server response to continue to send something in the stream (and the server blocks on reading the remaining data). Deadlock can occurs really fast. Apparently, you're using Xerces with some custom code to simulate a non-blocking socket read. Perhaps it would help to look at http://yaja.sourceforge.net, and see if there are some ideas that we can reuse. I just added a link on the Wiki page to Smack, which seems like a pretty nice client library for Java (apache license no less). I don't know if it's of that much use, but if nothing else maybe test cases. The main reason I took note though was because it has one of the easier APIs I've seen. Also maybe this library to get around the XML stream parsing issues you're facing... it's been a while since I've looked into IM protocols. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect,Make use of higher level api
Noel J. Bergman wrote: Change from Collection-List sounds good to me. Will go ahead and make this change in a day or two unless someone objects or gets to it sooner. The method returns a Collection of servers. At the time when we use the Collection, all that we can know, without changing the content of the Collection, is the order and value of the elements. Each Collection class provides its own Iterator type. If the actual Collection is sorted, the order is not lost; the underlying object is still the same. Any decision about sorting can be done within the method when it decides which subclass of Collection to return. In this case, we use a Vector. Vector is an AbstractList, and the provided Iterator iterates through the contents in order. If there is any sorting to do, we can do it before returning the Vector. When we use the Collection in RemoteDelivery, for example, we get an Iterator from the Collection, and use it: Iterator i = targetServers.iterator(); I haven't seen anyone provide a justification to change the current interface. Whatever policy we want to manage the MX records can be handled by the current interface, from what I've seen. Well, you're using a straw man argument IMHO. The question is whether the interface should change, and you're talking about how the underlying implementation behaves. The reason to change the interface is that MX Records have an ordering, so the interface that returns a IP addresses based on MX records should return something that indicates that this is ordered. Right now our interface does not indicate it is ordered. Sure, we are *implementing* the ordering, but the interface isn't accurate and hence needs to be changed. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
- Original Message - From: Harmeet Bedi [EMAIL PROTECTED] From: Serge Sozonoff [EMAIL PROTECTED] Please hold off on the Commit of the DnsJava upgrade, I am still cleaning/clearing up a few things with Noel and we should have a new version Sorry wasn't aware. I was concerned that your patch wasn't committed for a few days and there was no conversation about it on the list. There was conversation on the list about it... the faults were pointed out and (other) Serge said he would go fix and send revised changes. I'm not sure what email reader you're using, but Mozilla or Outlook would let you track threads pretty easily. Upgrade seems fine. I have tested the upgrade on James 2.1 and have been using upgraded DNS Java library on my mail servers for some time. (this email is through the same server) I don't think the library changes are in discussion. It's the code changes that's in question. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
- Original Message - From: Harmeet Bedi [EMAIL PROTECTED] DNSServer block returs a sorted collection now and has been from the first instance of the block. One could loose ordering in a collection but converting to list does not help as list is a collection. Iterator may be the best to express the idea of order. err, a Collection is unordered, and a List is an *ordered* Collection. Yes, a List is a Collection, differentiated by the exact attribute we want... ordering. An Iterator would restrict how you could use the result. Sorting is the responsibility of DNSServer implementation not the user of API. The collection returns MX Records sorted by priority. Remote Delivery gets hold of and collection through mailet context(o.a.j.James), converts to an iterator and attempts to send email to the first mail server address than second if first fails and so on. The only 2 methods called on Collection are Collection::size and Collection::iterator. Right, and on a Collection, iterator is not guaranteeing an order. Converting to a List will not really help as the returned collection/list contains only contains the IP address. There is not enough context like priority in the returned collection/list to allow the user of the API to effectively sort on. The DNS server needs to return the List... it *will* know the correct order to put the IP addresses in. Yes, we cannot later convert it to a List and expect it to create an order, which I why I think the DNS server should return a List. If it is already, that's great. /** * Returns a Collection of Strings of hostnames or ip addresses that * are specified as mail server listeners for the given hostname. * This is done using MX records, and the hostnames or ip addresses * are returned sorted by MX priority. * * @param host - the domain name for which to find mail servers * @return a Collection of Strings of hostnames, sorted by priority */ Collection getMailServers(String host); Yes ok, so this should be changed... getMailServers(String host) should return a List because those IP addresses should be ordered by the underlying implementation. I thought there was a conf option for whether to do authoritative lookups, no? Yes it does and it seems good to have the config option. The default is false and that is probably the better option. I am not suggesting the config option should be removed but curious if folks ever change the authoritative lookup setting. Ok, so we're leaving it as is? Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JIRA for James
- Original Message - From: Nicola Ken Barozzi [EMAIL PROTECTED] Collabnet will move to Scarab once it's released, and I'm confident that Apache will encourage users to move to Scarab too. As for Avalon, we are sticking with Bugzilla for now. Yeah, I'm somewhat disappointed CollabNet has such influence over the Apache infrastructure. Don't get me wrong, I'm incredibly appreciative of their huge and long-term contributions. Just that we seem to be heading towards Scarab, based largely because CollabNet has sponsored that project. OpenSymphony is a smaller but similar high-quality Java open source project depot (similar to Jakarta), and I think the affiliated business (Atlassian) has produced something a lot better than Scarab in JIRA. Anyway, had garnered some hope by seeing that Forrest and (maybe, but guess not) Avalon would be using it. If the future is already set, then no worries. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JIRA for James
I brought this up a while ago, but since the folks that run nagoya didn't seem to interested, I didn't push it further. However, I've just come to know that Forrest uses JIRA, and Peter Donald is planning to move Avalon to JIRA (this was 2 months ago, so may have changed his mind since). We're in the process of migrating all our commercial development from Bugzilla to JIRA because it's just a much better issue tracking system. Better interface, faster, more flexibility, release management... And it's free for open source projects. Anyway, since other Apache projects seem to be adopting it, I think it's worth considering. I think anyone who tries JIRA will have a hard time arguing against it. :) -- Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mailing list issues
Kenny Smith wrote: Hey all, I seem to be subscribed multiple times and am getting many copies of everything. Can however maintains the list make sure that only [EMAIL PROTECTED] is subscribed to the list? I would really appreciate it. Kenny Smith JournalScape.com Check the mail headers to see what addresses you are subscribed as. You were sending a bunch of messages using an address that wasn't subscribed, so I subscribed that one. -- Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] PMC
- Original Message - From: Harmeet Bedi [EMAIL PROTECTED] It does not talk about respository plans. I thought that repository was a really important thing for 3.0. Is this intentional as it is not an external feature ? Maybe something like this would be good to add. Provide a common Repository interface to all of James' protocol servers and to support stanadard repository data formats like maildir to ease migration. Sure, sounds good. I would add mbox in there as well. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api
- Original Message - From: Harmeet Bedi [EMAIL PROTECTED] Looks good but a few minor things - I don't think there is any need to change DNServer interface to return a list instead of collection. The results obtained are already sorted according to priority and there is no need to do any more sorting. The results returned are a collection of IP address so not sure what List to collection does. Would prefer backward compatible API unless there is a real gain. Are you saying it's returning a Collection right now? If it is, then it should be returned as a List. MX records have an order, and if we put the results in a Collection, it seems that we risk losing the ordering, doesn't it? One general question. Do we ever need to do autoritative lookups for MX record ? Wouldn't that slow up. I thought there was a conf option for whether to do authoritative lookups, no? Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: IMAP Support
- Original Message - From: Darrell DeBoer [EMAIL PROTECTED] Yep, the current mail storage doesn't give the basic functionality we need, like flag persistence, hierarchical mailboxes and searching. To get IMAP working with James2, we'll need an IMAP storage mechanism that is back-compatible with the current mechanism (in some way), so that SMTP can deliver to an inbox which is accessible both as a POP3 repository and a mailbox within the IMAP mailbox structure. Aside from some search, what else do we need to add to the mail repository interface to support IMAP? Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: missing mails
alan.gerhard wrote: i can no longer publish to the james list. either you guys see what i am sending but i don't or my emails are not getting there. i am receiving only from mail.xx.com (JAMES) but sending to both JAMES and SENDMAIL so i really do not know what is happening. all very bizar as this is recent from about a week ago ... alan Alan Gerhard Gerhard Computing, Inc. [EMAIL PROTECTED] You need to subscribe to the list to send messages, otherwise they require me to approve each message. I was on a trip the past few days and thought my approved emails were going through, but our spam filter had caught them. Your messages are going through now. -- Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] PMC
Danny Angus wrote: Hi, James commiters.. As you will have seen if we can get the detail done in time we can get our TLP proposal in front of the board on wednesday. Therefore I propose that: The initial PMC of the Apache James project be all active commiters and that active be considered as those who voted in the vote which decided us to propose James for elevation to TLP being: Serge Knystautas Danny Angus Peter Goldstein Noel Bergman Charles Bennet Further nominations and election to the board of other commiters not mentioned being allowed at any time hereafter. Further that unless anyone has a good reason to nominate any other person Serge be elected un-opposed as PMC chair, as he has been nominated already. So ... Any further nominations for the Chair? _Please_ express your opinion ASAP so we can get this done in time. All of these points are interim measures which may be reviewed by the PMC after it has been formed. +1 and no further nominations. :) (danny, sorry I haven't had time to read your proposal... been on biz travel this week... will read again in detail this weekend and will let you know if I have any comments. from first reading when you put it out, I don't remember anything outstanding.) -- Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: James TLP
Danny Angus wrote: I put a proposal template and draft covering letter in proposals/tlp for review... Danny, I went through and made some small edits (typos, small changes), added the history section, and otherwise I think it looks good to go. -- Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New to the list..
Noel J. Bergman wrote: 2) Is there a reason why fetchpop does a send instead of a store? Absolutely. Doing a store would bypass the James pipeline. Doing the send puts the message through local message processing. This is considered desirable. An argument could be made for it being a configuration option. IMHO, absolutely not... if you want to put it at the top of the pipeline, put it in the root repository, which is always the top of the spool for local message processing. The only reason I can think to not specify via repository is if you don't want to have fetchpop know where that repository is (I suppose somewhat of use, but even still doesn't seem that critical). 3) Is anyone else working on something like this or interested in this at all? I think that there would be considerable interest, especially since your version now allows us to integrate yahoo and hotmail, amongst other things, into James. Yeah, the Yahoo! mail javamail implementation is pretty cool. Sounds like it would be good to see your code. -- Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New to the list..
Noel J. Bergman wrote: Doing a store would bypass the James pipeline. Doing the send puts the message through local message processing. This is considered desirable. An argument could be made for it being a configuration option. IMHO, absolutely not... if you want to put it at the top of the pipeline, put it in the root repository, which is always the top of the spool for local message processing. Serge, please clarify your point. The term repository is overloaded a bit too much for clarity in this context. I am not at all sure that we are disagreeing. FetchPOP inserts mail the same way that the SMTPHandler does, using sendMail(). Eventually, sendMail() calls setState(), which specifies which processor. It does not store the user's mail directly in the user's mailbox. Yeah, probably are, so just to clarify... All sendMail(Mail) does is store the mail object in the _inbound_ repository, which out of the box is something like file://var/mail/spool. So if fetchpop just stored the mail object to file://var/mail/spool repository, you'd have the same result (mail gets processed). You could have this target repository as an optional configuration setting (as you suggested) so maybe we are agreeing. But since it seemed you were saying that fetchpop had to do sendMail() to get the mail processing to happen, I didn't think we were. -- Serge Knystautas Loki Technologies http://www.lokitech.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit ...
Noel J. Bergman wrote: Converted tabs to 4 spaces. Looks like the primary change was trimming trailing spaces. I did just do search and replace on tabs to 4 spaces, but in saving the files it does remove trailing spaces as well. While you're at it, I believe that we agreed to delete author tags from all source files. I do not see any reason to affect such a change in the v2 branch, but we might as well do it on the HEAD. Sounds good.. I'll commit the removal of the author tags in a bit. -- Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
