Re: [jira] Commented: (JAMES-282) Mail not correctly deliverd after DNS time-out on From: address
[EMAIL PROTECTED] wrote: OK, this partial message problem is reproducible and comes from the fact that when the socket prematurely closes (as opposed to times out, which does generate an exception), the associated stream just returns -1 when asked for more data. This gets passed back through the chain until it reaches James, which couldn't tell the difference between the pre-mature end of stream and the legitimate end of the Character Terminated stream. Thanks, Noel, for your clarifying explanation of this part of the problem. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:(JAMES-282) Mail not correctly deliverd after DNS time-out on From: address
[EMAIL PROTECTED] wrote: The following comment has been added to this issue: Author: Hes Siemelink Created: Wed, 19 May 2004 6:46 AM Body: I'm afraiud the problem is not potential but quite real and reproducible. We have nailed down the problem to the following: - Open a conenection to James - Give the HELO, MAIL FROM, RCPT TO and DATA commands - Close the connection after the DATA command. (On Windows, the most effective way to do this is by closing the telnet window) James will deliver a stub message. Hes, After reviewing RFC 2821 sections 3.3 and 4.1.1.4, I am not convinced this behavior is a bug. Those RFC sections do not seem to say what the SMTP receiver should do in this case. So I would think we are free to choose the present behavior, unless the present behavior violates a standard. Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Standard Could Reduce Spam
It seems to me that spam is a big problem that many of us (or perhaps most of us) have ideas about. I guess that most of the work now being done on mail-handling programs (including James) is motivated by a desire to limit spam. In this vein, I have spent most of the last four years working toward a kind of solution. But after four years the best I can say is that I've learned a lot. Also I have a preliminary offering at Mailscreen.net, but I grant this is so blunt and unrefined that it will please almost no one. My work on spam mixes in a heavy dose of my philosophy, which is libertarian. I mistrust government and hope to see solutions developed by private free market entrepreneurs. On my to-do list, after I get caught up in the J2EE course which I'm slogging through http://www.javapassion.com/j2ee/index.html, I want to put up a blog focused on a search for market-oriented network protocols. I posit that basic protocols at the IP level would contain better provisions for assuring the mutual gain of participants if those protocols had evolved in a marketplace between business traders, rather than having been developed on contract for a monolithic power (the US Department of Defense). Rich Hammer my present project: http://mailscreen.net/ resume: http://trilug.org/~rh/resume.html a previous project now in hibernation: http://freenation.org/ Vincenzo Gianferrari Pini wrote: I found this article today: http://www.wired.com/news/print/0,1294,63513,00.html This is something that I already developed last fall at the sender MTA side (AddServerSignature mailet), but stopped because I was counting on having a MUA check at the recipient side, and Outlook Express was not behaving correctly. The threads were From email address validation and [PROPOSAL] Release Plan in this list. This thing could become important in my country (Italy) also because the Italian Government is setting new rules regarding MTAs sending back signed receipt confirmations, in order to have email messages become legally valid etc. I'm going to dig a little around this. Perhaps other countries are doing something similar now ... Any thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: keeping a JDBC connection active
Thank you for the information, Danny. Rich Danny Angus wrote: If you don't use transactions and transaction locking you'll most likely never see a data issue. If you do you may find ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
keeping a JDBC connection active
In my mailserver (a cousin of James) I use one java.sql.Connection throughout the life of the server. I call java.sql.DriverManager.getConnection() once at server startup. I've never suspected there was anything wrong with this, but I guess there might be. If this is of interest to anybody, several times I have gotten java.net.SocketException Connection reset by peer, indicating a dead connection to the database and requiring me to restart the server. This happens several hours after server startup, when I am running the mailserver in a Windows 2000 desktop and the database (PostgreSQL) in a RH7.3 Linux box on the LAN. I have found that I can work around this by running both mailserver and database on the same Linux box; then the Connection seems to last forever. Rich Hammer Noel J. Bergman wrote: Do you have any reason to believe that there are legitimate reasons for a JDBC connection to be active for several minutes, much less an hour? I ran grep against the logs in my production environment. There have been 32 timeouts since August 2002. Getting them tends to indicate a need to repair tables, at least in our environment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: keeping a JDBC connection active
Serge Knystautas wrote: ... permanently holding a single database connection open is a Bad Idea(tm). Some downsides: - your code is inherently single-threaded. I have not noticed any single-thread limitation. I have a singleton (only one instance) database class. It has the one Connection as an instance variable which is set when the class is constructed at server startup. Multiple threads call the methods in this database class. Each call to one of the database methods prepares its own PreparedStatement from the one Connection, and closes the PreparedStatement before returning. (I would have avoided that pattern of preparing a PreparedStatement on each method call, since it seems wasteful in my limited knowledge. But if I recall correctly I got the pattern from James, where I gather it works well enough, and I have not had reason to change it in my code.) Anyhow, I have the impression that the Connection keeps track of its many individual PreparedStatements, like a mama knows her children apart, and never mixes up their interactions. Do you think it might? I've never noticed any jumbling of data. I think I've got the necessary synchronization, pertaining to the reading and setting of database data, handled higher up in my code. But maybe there is some database programming issue here which I need to learn. - if you restart your db server, you get a failure in your app. Yes! This one has hit me over the head. You've helped me see which direction I need to go to fix it. ... Database connection pools are pretty prevalent, even most JDBC3 drivers have something bundled. I would really encourage you to look into using one. Thank you, Serge. I've got work to do. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MxSorter and changes to DNSServer.java
Noel J. Bergman wrote: The more important change in DNSServer was reverting to the previous technique of using InetAddress.getAllByName to get the IP addresses for the SMTP hosts, rather than the Type.A lookup. I haven't looked at this code recently, but I guess this change might end the reliance upon the org.xbill jar. Do you know offhand if it does? ... The code was failing to resolve hosts that use CNAME on the right hand side of an MX record. That may be an incorrect DNS configuration, but it is all too common as I have noticed over the past couple weeks of testing the new code. It is good that you caught this, Noel. When I was working with this functionality back in December, I felt unsure of the proper ways to use DNS since I don't know of a good reference which tells how mailservers should use DNS. Do you know of such a reference? or do we just push ahead learning from our experience? Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
The original issue http://issues.apache.org/jira/browse/JAMES-248 says: Isn't this kind of a memory leak? After all, attachments to such a MIMEMessage can be 13MB large. Shouldn't those objects be null-ed latest after the POP3Handler.doQUIT of a session? Commenting upon this, Noel wisely asks Do you have any reason to believe that there is currently a problem in James? I guess that this IS NOT a kind of memory leak. The people who specified the JVM seem to believe that they have the JVM's memory managment under control, and they seem to want us Java developers to leave that problem to them. Generally, I trust the JVM to do garbage collection using parameters which are known to the JVM. Generally, all you need to do with a variable name when you are done with it is to forget it. Just let it fall out of scope, while making sure of course that your scope is not larger than needed. When I see variables set to null after their use, I think that this programmer does not know Java. Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl
Noel J. Bergman wrote: Serge posted an article today that discusses this issue in some detail. See Explicit Nulling in http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html. Great article! Thank you, Noel. Java performance has few absolutes. For example, the author of that article is not a fan of user-level object pooling. Neither, for that matter, is the J2SE tech lead. However, when we added object pooling of certain objects in James, we found that performance improved significantly under load. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mail list loop, reverse path - Return-Path header
I had some difficulty with the way James handles Return-Path headers,
while developing my mail service which borrows much code from James
but which also has significant architectural changes.
As Hontvari reports, the SMTPHandler in the version of James with
which I started (about 18-24 months ago) added a return-path header to
each message which came in. At first I copied that. Then I was
incorrectly forwarding SMTP messages with the Return-path header still
in place. Now my code adds a Return-path header only when it places a
message in a POP3 mailbox.
The James MailImpl class seems to keep the return path, since it has
the method getSender(). With the return path thus accessible in
James, addition of a Return-Path header might be moved to those places
where the message is leaving the SMTP environment.
Hope this helps,
Rich Hammer
mailscreen.net
Hontvari Jozsef wrote:
(I am not sure what is the status of the merge, so I don't send a patch now,
and anyway, you may not agree on my evaluation)
org.apache.james.James class has a bounce method, which is intended to be
used for bouncing invalid emails to the reverse path (i.e. the email address
supplied in the SMTP MAIL FROM command). RemoteDelivery mailet does use this
method.
This method tries to determine the reverse path from the Return-Path header
(which is stored _within_ the email) instead of using the reverse path
stored along the email in the Mail class. According to the mail RFCs, the
Return-Path header is not indeded to be used by an smtp service, it should
only be used when final delivery occurs, e.g. when storing the mail in a
mailstore used by a pop service. I consider this as a hack, and really don't
like it in James, but because the James smtp handler always inserts the
Return-Path header it seems to be working.
However, the GenericListserv mailet removes the Return-Path header. I think
that is quote correct, on the other hand it breaks the above, not so correct
assumption about the Reverse-Path header. The bounce method in these cases
defaults to the Reply-To, i.e the mail list itself, so you get a mail loop
involving as many people as you have on the list... It happened to me
several times.
In my oppininon the correct solution would be to enirely remove the
dependency on the Return-Path header, but I don't have enough time and
understanding of James. So I only implemented a fallback specifically for
the case when the Return-Path header is not present, which eliminates this
type of loop in my case:
I replaced the
getLogger().warn(Mail to be bounced does not contain a
Return-Path header.);
line with this code:
MailAddress reversePath = mail.getSender();
if (reversePath == null) {
getLogger().warn(Mail to be bounced does not contain a
Return-Path header and reverse path is null too, sending to postmaster.);
reply.setRecipient(MimeMessage.RecipientType.TO,
getPostmaster().toInternetAddress());
} else {
getLogger().warn(Mail to be bounced does not contain a +
Return-Path header although expected (wrongly!),
+
reverse path used (it should be used always): +
reversePath.toString());
reply.setRecipient(MimeMessage.RecipientType.TO,
reversePath.toInternetAddress());
}
(I copied this code directly from my source, maybe the log message isn't
suitable for a release)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JavaMail InternetHeaders could be more friendly to server developers
Three months ago in November we exchanged a few ideas about how the JavaMail API might be made more useful for development of mail servers -- as distinct from development of mail clients. Now I have discovered one more point that I would like to add. I might be mistaken again because of my incomplete understanding of the API, but I hope this is right. My comment concerns javax.mail.internet.InternetHeaders. When a SMTP server receives a message it needs to add a Received: header at the top of the headers. But InternetHeaders does not seem to offer any way to add a header specifically at the top of the list. This class seems to offer no way for its users to learn or set the order of the headers. (I am referencing the JavaDocs for JavaMail 1.3). As a consequence the code in James* goes through an awkward workaround: constructing a new InternetHeaders object, adding the new Received: header, and then adding the remaining header lines by looping through an Enumeration of header lines retrieved from the original incoming InternetHeaders object. This workaround relies upon behavior which I have not seen documented, namely that the addHeaderLine() method always adds to the bottom of the list of headers. So, I would suggest that InternetHeaders could be improved, for the use of server developers, by addition of a method addHeaderLineAtTop(), and by promising and documenting the present behavior of addHeaderLine(), that it adds to the bottom. Rich Hammer Hillsborough, N.C. *The code in James to which I refer is in: org.apache.james.smtpserver.SMTPHandler.processMailHeaders(InternetHeaders) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: when to dot-stuff, dot-strip
Danny Angus wrote: -- BUT I NEVER USE IT IN THE DOT-STRIPPED CONDITION. Huh? internally do you mean? I never use the bodies of the messages which have come in except to send them out again. They sit in a file until they are shipped out again, and later the file is deleted. The choice is to develop some kind of logic to determine and mark the stuffing status of messages, or strip and stuff everything. I think the latter is safer I agree, given that a system is already established and working. But for future development of MTAs there might be some simpler MTAs which could entirely skip the coding of dot-stuffing and dot-stripping. For instance, if all you are running is an open relay :-?, then you can entirely skip this dot business. Thank you for your response, Danny. I'll mention this on the [EMAIL PROTECTED] list, since it seems like an issue which may relate to the specification. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Determine Message Size in Mailet
Kraig Schario wrote: I am having a problem with a mailet when copying the Mail mail object to a MimeMessage. MimeMessage message = mail.getMessage(); It only occurs when the message contains large attachments. Usually larger than 2 MB. I receive the following error in the Mailet.log java.lang.OutOfMemoryError I think one way to deal with this is to give the JVM more memory to work with than it gets by default. You can do this with a command line option to the java command, an option like -Xmx96m. I had this working once, after experimenting some, and was thereby able to process bigger messages through JavaMail. Unfortunately, now I can't find specifically what option I used. You may succeed with trial and error. As I recall, the JVM gets 64 megs by default in my situation. Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Determine Message Size in Mailet
Oh, and let me add that documentation (or perhaps I should say hints) about that memory-increasing command line option can be found in places like this http://java.sun.com/j2se/1.4.1/docs/tooldocs/windows/java.html. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: escaping of SQL strings
Thank you, Serge. PreparedStatement.setString() does the escaping trick, all right. I've confirmed this with testing. The API documentation didn't give me a clue. Rich Serge Knystautas wrote: Richard O. Hammer wrote: I stumbled into this question when, using my James-offshoot server, I sent a test message with a possessive (single quote) in the subject: Subject: Friday's test and it failed with java.sql.SQLException: ERROR: parser: parse error at or near s You shouldn't do escaping yourself in Java. Do PreparedStatement.setString(paramNum, stringValue) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
escaping of SQL strings
When James stores message headers or other text in a database, I assume that it escapes the single-quote characters in those strings (and perhaps a few more characters as needed). But my look at the code this morning does not find that functionality, so I wonder if it is happening somewhere I am not looking. I am looking at these calls: mailrepository.JDBCMailRepository.store(Mail), which calls MimeMessageWrapper.writeTo(various) and I don't see any escaping going on there. Unfortunately I do not have a running copy of James with which to test this myself. I stumbled into this question when, using my James-offshoot server, I sent a test message with a possessive (single quote) in the subject: Subject: Friday's test and it failed with java.sql.SQLException: ERROR: parser: parse error at or near s So I have to be escaping my headers before I feed them into SQL, and I went looking in James for a good idea of a way to do it. But I have not found it yet. Assuming that James does this escaping, what method does it use? Thank you, Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
Below you may find code which I have developed and tested to deal with
this issue.
This solution has a new little type to wrap the data needed in
RemoteDelivery. It carries a String hostName and an array of InetAddress.
import java.net.InetAddress;
import org.xbill.DNS.ARecord;
import org.xbill.DNS.Record;
/** A holder of data generated in the DNSServer and needed in
RemoteDelivery. Especially needed for multihomed hosts.
*/
public class SMTPHostAddresses {
String hostName;
InetAddress[] ipAddresses;
SMTPHostAddresses(Record[] aRecords, String hostName){
this.hostName = hostName;
if (aRecords == null){
ipAddresses = new InetAddress[0];
}else{
ipAddresses = new InetAddress[aRecords.length];
for (int i = 0; i ipAddresses.length; i++){
ipAddresses[i] = ((ARecord)aRecords[i]).getAddress();
}
}
}
public String getHostname(){
return hostName;
}
public InetAddress[] getAddresses(){
return ipAddresses;
}
}
The following new method, added to DNSServer, provides the interface
to the underlying DNS functionality. This will be used instead of
DNSServer.findMXRecords(hostname).
/** Performs DNS lookups as needed to find servers which should or
might
* support SMTP. Returns one SMTPHostAddresses for each such host
discovered
* by DNS. If no host is found for domainName, the Enumeration
* returned will be empty and the first call to hasMoreElements()
will return
* false.
* @param domainName the String domain for which SMTP host
addresses are
* sought.
* @return an Enumeration in which the Objects returned by
nextElement()
* are instances of SMTPHostAddresses.
*/
public Enumeration getSMTPHostAddresses(final String domainName){
return new Enumeration(){
private Enumeration mxHosts = new MxSorter(domainName);
public boolean hasMoreElements(){
return mxHosts.hasMoreElements();
}
public Object nextElement(){
String nextHostname = (String)mxHosts.nextElement();
Record[] aRecords = lookup(nextHostname, Type.A);
return new SMTPHostAddresses(aRecords, nextHostname);
}
};
}
You will notice that this method simply wraps another Enumeration,
which I will supply below.
But first let me touch upon how this would be used in RemoteDelivery,
if that is not obvious. The code immediately below is an untested
sketch of the structure which I suppose could work in
RemoteDelivery.deliver(). It contains an outer loop going through the
Enumeration of SMTPHostAddresses, and an inner loop going through the
array of InetAddresses in each SMTPHostAddresses.
Enumeration smtpHosts = /* something like */
getMailetContext().getSMTPHostAddresses(host);
if(!smtpHosts.hasMoreElements()){
//error condition as in RemoteDelivery
log(No mail server found for: + host);
StringBuffer exceptionBuffer =
new StringBuffer(128)
.append(There are no DNS entries for the hostname )
.append(host)
.append(. I cannot determine where to send this message.);
return failMessage(
mail, new MessagingException(exceptionBuffer.toString()),
false);
}
while(smtpHosts.hasMoreElements()){
SMTPHostAddresses thisHost =
(SMTPHostAddresses)smtpHosts.nextElement();
String thisHostName = thisHost.getHostname();//if needed for
logging
InetAddress[] addresses = thisHost.getAddresses();
for (int addressIndex = 0; addressIndex addresses.length;
addressIndex++){
InetAddress thisAddress = addresses[addressIndex];
//attempt SMTP connection at thiAddress
//do other work
}
}
I agree with Noel that in some ways a single Enumeration,
necessitating only a single loop, would be simpler. But I've already
got this written, and there are also some ways in which this structure
seems better.
Now for the biggest block of my code, the inner class MxSorter below
also goes into DNSServer. This is the Enumeration that was wrapped
above in the method DNSServer.getSMTPHostAddresses().
/** A way to get mail hosts to try. If any MX hosts are found for the
* domain name with which this is constructed, then these MX hostnames
* are returned in priority sorted order, lowest priority numbers
coming
* first. And, whenever multiple hosts have the same priority then
these
* are returned in a randomized order within that priority group, as
* specified in RFC 2821, Section 5.
*
* If no MX hosts are found for the domain name, then a DNS search is
* performed for an A record. If an A record is found then
domainName itself
* will be returned by the Enumeration, and it will be the only
object in
* the Enumeration. If however no A record is found (in addition
to no MX
* record) then the Enumeration constructed will be empty; the
first call to
* its hasMoreElements() will return
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
Søren Hilmer wrote: ... I am adding a DNSServer.findARecords method to do it (basically a copy/paste of findMXRecords). I find this very interesting, and I am working on code to deal with it. But I don't want to step on Søren's toes. Within a day or two, I hope to post some code here which works -- as far as I have been smart enough to test it. Then I hope to benefit from the list's critical review of that code. I don't know enough about DNS to feel sure of myself here. I want to confirm my understanding of preferences. As Noel cited, RFC 2821, section 5, says: The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented. I believe that these preferences pertain to the host targets of the MX records. The hosts are ranked. But, for any given host, if that host is multihomed, then the IP addresses for that host are not ranked. They can be returned in any order within the list of IP addresses for that host. Does that sound right? Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Richard O. Hammer wrote: Another class which does more than I want is Transport. ... it sets message headers Bill Shannon wrote: I'm not sure what you're referring to. You are right Bill. I wrote based upon my poor memory of experiments I did a year ago or more. I had noticed that headers were being set in a way which seemed out of my control, and I guessed incorrectly it was being done in Transport. But the frustrations which mail-server developers face in using JavaMail don't worry me quite so much anymore. In my project I have gotten around some of those frustrations by writing some simple classes for my basic needs. Note that my project is not James, but an offshoot of James. Thank you, Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LocalDelivery and Delivered-To
Is the addition of a Delivered-To header called for in an RFC? If so, where? I'm having trouble finding it. From the a comment in the source of the LocalDelivery mailet, I surmise that this practice originated with Qmail. Is that correct? By the way, I want to thank the James team for assembling the folder of relevant RFCs and including them with the distribution. I've got a link to that on my desktop. Very useful. Rich Hammer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with outgoing email
Two tools which I find useful for troubleshooting such difficulties are: 1. telnet to port 25 of the server in question (one of the Yahoo servers which DNS is finding for you) and talk SMTP to it. That is, type in SMTP commands and observe the responses. You can send test messages to yourself in this low-level way. For an example of a SMTP exchange, see RFC 2821, Appendix D. 2. Ethereal to capture the packets of a given exchange. It is possible that some error message is being generated, in the exchange between javax.mail.Transport and the yahoo mail server, which is not being reported up to you. By scrutinizing the SMTP exchange, which you can capture with Ethereal, you might find an error message. Rich Hammer Serge Knystautas wrote: Chandru wrote: Hi, Took me a bit of time to figure out that I need to point James to the apropriate dns server (default is localhost). The nameservers are set correctly (I am using yahoo's namesservers currently). The emails seem to be going out from James: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Danny Angus wrote: ... JavaMail is explicitly and in its detail a mail client API, it lacks support in may areas for the kind of server functionality James provides and it is not always easy, and often impossible, to force James to use JavaMail interfaces and classes for many of the tasks of a server. ... Reflecting upon what Danny wrote, I wonder if Sun ever considered the possibility of dividing the existing functionality in the JavaMail API. It would be great for us if this existing functionality were divided into a basic set, tools useful to both servers and clients, and an extended set, just for clients. Then we developers of servers could employ the basic set without having to disentangle ourselves from the features intended for clients. JavaMail includes a lot of important, basic work, promising to ease the burdens of other developers. Because of this, we developers of servers find ourselves sucked in, trying to use the good stuff that is inside JavaMail for our purposes. But JavaMail would be much more valuable to us if the basic tools were exposed free of the stipulations which have been added for clients. Rich Hammer Hillsborough, N.C. mailscreen.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Thank you, Bill. Even though I raised this point, I doubt that I'm the best person from the James Developers list to respond to your saying, If you think some great advantage could be had by splitting the APIs in this way, tell me more. I guess that Danny, Noel, Serge, or others, might be able to quickly throw together a list of ways that life could be made easier for us if more of the basic functionality inside JavaMail were made accessible without the requirements for clients. Assuming that I have actually represented the needs of James developers, I hope that others from this list might respond. I don't know if a list of our needs might rise to the level of a great advantage from Sun's viewpoint. You are probably right that there are many fewer server-side projects than client-side projects. Rich Hammer Bill Shannon wrote: Richard O. Hammer wrote: Danny Angus wrote: ... JavaMail is explicitly and in its detail a mail client API, it lacks support in may areas for the kind of server functionality James provides and it is not always easy, and often impossible, to force James to use JavaMail interfaces and classes for many of the tasks of a server. ... Reflecting upon what Danny wrote, I wonder if Sun ever considered the possibility of dividing the existing functionality in the JavaMail API. It would be great for us if this existing functionality were divided into a basic set, tools useful to both servers and clients, and an extended set, just for clients. Then we developers of servers could employ the basic set without having to disentangle ourselves from the features intended for clients. JavaMail includes a lot of important, basic work, promising to ease the burdens of other developers. Because of this, we developers of servers find ourselves sucked in, trying to use the good stuff that is inside JavaMail for our purposes. But JavaMail would be much more valuable to us if the basic tools were exposed free of the stipulations which have been added for clients. We did some of this. We separated the pieces of JavaMail into the core API piece and the protocol provider pieces. That allows you to pick just the pieces you need. But we haven't considered carving the core API piece into multiple pieces. And we wouldn't consider doing anything of that sort that would break compatibility with the existing API. Requiring servers to carry around the additional client parts of the core API doesn't seem like a great burden. I'd be more concerned about adding significant new server support that clients were required to carry around. If you think some great advantage could be had by splitting the APIs in this way, tell me more. I think the more interesting question is how much can we morph the APIs into something that's more useful for servers without compromising ease of use for clients? I expect there to be many thousands of applications using JavaMail for client mail access. I only expect tens (at most) of applications using JavaMail to implement mail server functions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with outgoing email
Chandru wrote:
I have a similar issue where the connection times out trying to contact
yahoo.com (exception below). Shoudn't james be trying to contact the
mail server (mx?.mail.yahoo.com) instead?
This reminds me of something I've seen in the finally block in
org.apache.james.dnsserver.DNSServer.findMXRecords(hostname). You can
see the code below. If the DNS lookup fails to find MX records, then
findMXRecords may return simply the hostname from the email address.
So possibly your MX lookup is not working. I would check first to
confirm that you have the nameservers configured correctly.
Rich Hammer
} finally {
//If we found no results, we'll add the original domain
name if
//it's a valid DNS entry
if (servers.size () == 0) {
StringBuffer logBuffer =
new StringBuffer(128)
.append(Couldn't resolve MX records for
domain )
.append(hostname)
.append(.);
getLogger().info(logBuffer.toString());
try {
InetAddress.getByName(hostname);
servers.add(hostname);
} catch (UnknownHostException uhe) {
// The original domain name is not a valid host,
// so we can't add it to the server list. In this
// case we return an empty list of servers
logBuffer = new StringBuffer(128)
.append(Couldn't resolve IP address
for host )
.append(hostname)
.append(.);
getLogger().error(logBuffer.toString());
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: building from james head
This is valid source as far as the Java language is concerned.
InetNetwork is not an inner class, but rather is another class in the
same package. While it is customary to put each class in its own file
this is not required by Java standards.
But, from scanning the Exception message which you attach, this
practice seems to violate a design assumption of Avalon.
Although I have not tried this, I suspect you could make InetNetwork
into an inner class simply by moving the closing brace of class
NetMatcher down below the closing brace of InetNetwork. That might
fly, and might even have been intended, if no class but NetMatcher
uses reference to InetNetwork.
Rich Hammer
Hillsborough, N.C.
Stephen McConnell wrote:
This one is interesting:
The class org.apache.james.util.NetMatcher includes references to the
inner class InetNetwork. However, if we look at the source we see that
InetNetwork is not defined as an inner class (at least not in a way I am
familiar with).
What we have is :
start-source
public class NetMatcher
{
// stuff
}
class InetNetwork
{
// stuff
}
// more stuff
end-source
Ok - it compiles but is this really a valid source?
Stephen.
Internal error during kernel instantiation.
---
Exception: org.apache.avalon.merlin.kernel.KernelException
Message: Deployment failure.
Cause: org.apache.avalon.activation.appliance.DeploymentException
Message: Composite deployment failure in block: [block:/james]
Cause: org.apache.avalon.activation.lifecycle.LifecycleException
Message: Unable to create a new component instance in appliance
[/james/spool] due to a component deployment failure.
Cause: org.apache.avalon.activation.lifecycle.LifecycleException
Message: Component initiated initialization failure.
Cause: java.lang.NoClassDefFoundError
Message: org/apache/james/util/InetNetwork
stack trace --
java.lang.NoClassDefFoundError: org/apache/james/util/InetNetwork
at
org.apache.james.transport.matchers.AbstractNetworkMatcher.init(AbstractNetworkMatcher.java:95)
at org.apache.mailet.GenericMatcher.init(GenericMatcher.java:154)
at
org.apache.james.transport.MatchLoader.getMatcher(MatchLoader.java:108)
at
org.apache.james.transport.JamesSpoolManager.initialize(JamesSpoolManager.java:212)
at
org.apache.avalon.activation.appliance.impl.DefaultAppliance.applyInitialization(DefaultAppliance.java:952)
at
org.apache.avalon.activation.appliance.impl.DefaultAppliance.newInstance(DefaultAppliance.java:637)
at
org.apache.avalon.activation.lifestyle.impl.SingletonLifestyleHandler.resolve(SingletonLifestyleHandler.java:
94)
at
org.apache.avalon.activation.appliance.impl.DefaultAppliance.resolve(DefaultAppliance.java:585)
at
org.apache.avalon.activation.appliance.impl.DefaultAppliance.resolve(DefaultAppliance.java:571)
at
org.apache.avalon.activation.appliance.impl.DefaultAppliance.deploy(DefaultAppliance.java:520)
at
org.apache.avalon.activation.appliance.impl.DefaultBlock.deploy(DefaultBlock.java:625)
at
org.apache.avalon.activation.appliance.impl.BlockThread.run(BlockThread.java:111)
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new InputStream class for mail data
In case you are considering using that class SMTPDataInputStream, you may want to know that I am now rewriting part of it, making what I consider to be an improvement, an improvement stimulated by the discussion of the last few days. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
