Re: IMAP
Stefano Bagnara wrote: Can you provide a list of most commonly used IMAP commands (by common clients such as Outlook) and their parameters? Stefano here is are the logs for a IMAP session. The client is Thunderbird 1.0.5, the server is Communigate Pro 4.2.7 both running on the local computer. http://openconnector.org/imap.log.1.txt I did a few SEARCHes and there are a few FETCHes in there. Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP
Stefano Bagnara wrote: Can you provide a list of most commonly used IMAP commands (by common clients such as Outlook) and their parameters? I can if you need. I'll do try to do Outlook tonight or tomorrow. Maybe someone can do Thunderbird? And maybe a UW client like Pine? Through in what the Apple users use ( iMail ? ) and I think we would have got good coverage. Some interesting links to begin with... Mozilla IMAP interop. http://www.mozilla.org/quality/mailnews/tests/sea-mn-imap-interop.html IMAP Cliet Guidelines ( brief ) http://www.dovecot.org/imap-client-coding-howto.html IMHO we should take into consideration most common commands in order to achieve a performant implementation: we cannot simply index EVERY message property or split the message in hundreds of parts, but we could treat most accessed fields with caching and separate storage. Ok. But maybe we will run into performance versus compliance issues in the future? I think we will be forced to index on the usual message headers, system flags ( there a 6 default ), and a few important dates at least. "NO" is the answer for NO results or is defined by the RFC that should be used when a search is too complex? Yes, "NO" is an error. http://ietfreport.isoc.org/idref/rfc3501/#page-49 ... Result: OK - search completed NO - search error: can't search that [CHARSET] or criteria BAD - command unknown or arguments invalid The client would probably show the user an error message in response. PS. I planning on writing an implementation of... "private class HierarchicalMailbox implements ImapMailbox" that writes to Derby. Is that an acceptable first step? Also, why does HierarchicalMailbox implement ImapMailbox? Shouldn't it be the other way around? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IMAP
> Stefano Bagnara wrote: > > > > IMHO we need to consider real cases to be able to do > something performant. > > How would SEARCH and FETCH affect performance? > > I think we can get away with stubbing a lot of SEARCH > functionality, but not FETCH. The SEARCH command can return > 'NO' if the operation is too complex. > > Regards, > Kervin Can you provide a list of most commonly used IMAP commands (by common clients such as Outlook) and their parameters? IMHO we should take into consideration most common commands in order to achieve a performant implementation: we cannot simply index EVERY message property or split the message in hundreds of parts, but we could treat most accessed fields with caching and separate storage. "NO" is the answer for NO results or is defined by the RFC that should be used when a search is too complex? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
> > IMHO James needs to have people doing things to it, we've had a > > virtual > > -1 > > I know I'm going to step on toes by saying this but... > > James does not need more code before James needs management > and design. > > Everyone, except for Stefano, seems to be too busy. Which is > understandable, but has consequences. > > James isn't going to attract many new developers with the "Do > what you want, the code is in CVS" > attitude that seems to be the persuasion around here. And > the code looks it too, everyone goes into their corner, does > their own thing, returns and commits. Please look at this page http://james.apache.org/todo.html Most of my commits and most of my proposals are mentioned in the OLD TODO list. I worked mostly on bugfixes and JIRA cleanup and: - I added the "8BITMIME extension", and "enhanced status codes extension (RFC 2034)". - I'm working on "Revisit the MailRepository", "Revisit the SpoolRepository" and "Define a simple mechaism for addressing repositories". - I'm refactoring the Avalon Blocks in order to simplify the removal of the phoenix container (see "Container options"). - I'm partecipating in "Discuss and design the next revision of the Mailet API." - My local james has "Complete support for delivery service notification" but I don't like the way I implemented it so I'll wait to have a refactored James that will allow me to have a more clean approach to this. As you can see everything I'm doing has been written in a page that was last updated on January 2005 :-) I'll take your reply as a feature request for IMAP, but I don't have knowledge and time to work on IMAP, but I'll put my efforts in helping anyone that will provide an alpha working implementation because I think IMAP is a needed feature. Most of the ROADMAP has already been discussed plenty of times, we just need people to do something from the roadmap. You can see that IMAP is in the TODO list. If you want to contribute code or sponsor a developer for that feature you're welcome ;-) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
On 23/08/05, Kervin L. Pierre <[EMAIL PROTECTED]> wrote: > I know I'm going to step on toes by saying this > but... > > James does not need more code before James needs > management and design. I don't think you are being overly critical, but I do think you are oversimplifying the situation. James has had a stable and consistent design for a few years, it is well understood by the commiters, and the future of James has been discussed over and over. What we have lacked is people with the time to expend on reaching our goals. Stefano is not "doing his own thing" we have elected him to join us because not only does he understand James, he also understands our direction and has demonstrated his ability to adapt his point of view when the group disagrees with him. What I am in favour of is encouraging people to return to the propose, commit, review approach we have traditionally taken. This may result in a longer cycle between stable major versions but it does not diminish quality, what we have to ensure is that the review is conscientious, and that we take the time to reach consensus of approach. > I hope I am not being overly critical. I have > had high expections of James. Especially being > an Apache project and all. In what way does James fail to meet your high expectations? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
Danny Angus wrote: On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: IMHO the ONLY way to move is to CODE something +1 IMHO James needs to have people doing things to it, we've had a virtual -1 I know I'm going to step on toes by saying this but... James does not need more code before James needs management and design. Everyone, except for Stefano, seems to be too busy. Which is understandable, but has consequences. James isn't going to attract many new developers with the "Do what you want, the code is in CVS" attitude that seems to be the persuasion around here. And the code looks it too, everyone goes into their corner, does their own thing, returns and commits. I hope I am not being overly critical. I have had high expections of James. Especially being an Apache project and all. Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-296) James does not handle Source Routing
[ http://issues.apache.org/jira/browse/JAMES-296?page=all ] Soren Hilmer resolved JAMES-296: Resolution: Fixed > James does not handle Source Routing > > > Key: JAMES-296 > URL: http://issues.apache.org/jira/browse/JAMES-296 > Project: James > Type: Bug > Components: Mailet API > Versions: 2.2.0 > Reporter: Soren Hilmer > Assignee: Soren Hilmer > Fix For: 2.3.0 > > Old RFC-821 style addresses like: > @YYY.XXX.DK:[EMAIL PROTECTED] > Makes James (SMTPServer, but the actual bug is in the mailet api's > MailAddress): > ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:[EMAIL > PROTECTED]: No > local-part (user account) found at position 1 > Which is logical as MailAddress is not designed to handle source routes. > But according to RFC-2821 appendix F.2: > "SMTP servers MUST continue to accept source route syntax as specified in the > main body of this document and in RFC 1123. They MAY, if necessary, ignore > the routes and utilize only the target domain in the address. If they do > utilize the source route, the message MUST be sent to the first domain shown > in the address. In particular, a server MUST NOT guess at shortcuts within > the source route." > So to be compliant James actually MUST accept this syntax > Proposed fix is to ignore the source routes and use the target domain as > suggested in the quote above. This is also the way the Postfix mailserver > handles this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r239384 - /james/server/trunk/src/java/org/apache/mailet/MailAddress.java
Author: hilmer
Date: Tue Aug 23 02:46:24 2005
New Revision: 239384
URL: http://svn.apache.org/viewcvs?rev=239384&view=rev
Log:
Strip RFC-821 source routing information. JAMES-296
Modified:
james/server/trunk/src/java/org/apache/mailet/MailAddress.java
Modified: james/server/trunk/src/java/org/apache/mailet/MailAddress.java
URL:
http://svn.apache.org/viewcvs/james/server/trunk/src/java/org/apache/mailet/MailAddress.java?rev=239384&r1=239383&r2=239384&view=diff
==
--- james/server/trunk/src/java/org/apache/mailet/MailAddress.java (original)
+++ james/server/trunk/src/java/org/apache/mailet/MailAddress.java Tue Aug 23
02:46:24 2005
@@ -71,6 +71,21 @@
private int pos = 0;
/**
+ * strip source routing, according to RFC-2821 it is an allowed approach
to handle mails
+ * contaning RFC-821 source-route information
+ */
+private void stripSourceRoute(String address) throws ParseException {
+if (pos < address.length()) {
+if(address.charAt(pos)=='@') {
+int i = address.indexOf(':');
+if(i != -1) {
+pos = i+1;
+}
+}
+}
+}
+
+/**
* Construct a MailAddress parsing the provided String
object.
*
* The personal variable is left empty.
@@ -80,6 +95,11 @@
*/
public MailAddress(String address) throws ParseException {
address = address.trim();
+
+// Test if mail address has source routing information (RFC-821) and
get rid of it!!
+//must be called first!! (or at least prior to updating pos)
+stripSourceRoute(address);
+
StringBuffer userSB = new StringBuffer();
StringBuffer hostSB = new StringBuffer();
//Begin parsing
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories refactoring proposal
On 8/22/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > IMHO the ONLY way to move is to CODE something +1 IMHO James needs to have people doing things to it, we've had a virtual moratorium on changes this last while and I see our current position as being one in which we can afford to, in fact you might argue that we need to, make rapid evolutionary changes to revitalise both the product and our enthusiasm. The _next_ stage will be to refactor, consolidate, and mature the changes in response to observations, tests and theory (aka, "Boys, ah've bin a figurin and the way I figures it it is this..") Don't forget that we have a competent mature product available for download which has been proven in hundreds (thousands? I don't know!) of commercial deployments, we don't have to rush the next version out to satisfy users *or* shareholders. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit ed. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
