Re: [VOTE] jSPF-0.9.6 (seconds try....)
[X] +0 Cool to see the release On Saturday 05 April 2008 11:16, Norman Maurer wrote: > Hi all, > > I just rebuilded the 0.9.6 files for jspf. The release now contains the > pom file changes suggested by Stefano. So I hope the VOTE will now pass > and we get the release out soon ;-) > > Please review and VOTE: > http://people.apache.org/~norman/staging-repository/org/apache/james/apache >-jspf/ > > VOTE: > [ ] +1 Yes plz make this release official! > [ ] +0 Cool to see the release > [ ] -0 Anyway I don't care to much.. > [ ] -1 No.. I don't want a new release for some reason! > > Cheers > Norman > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] James 3.0 Milestone 1...?
+1 On Thursday 19 July 2007 14:01, robert burrell donkin wrote: > the code in trunk has a ton of new features > (http://mail-archives.apache.org/mod_mbox/james-server-dev/200707.mbox/brow >ser) > > i think that the upcoming spring integration might be a good excuse to > cut a milestone from trunk and christen it 3.0 milestone 1. yes, > there's work to be done (on the build, auditing the licenses, making > sure that everyone's happen with policy for milestones, cutting > releases for component sub-projects) but this is only a poll to see > whether people think it would be a good idea or not. > > the milestone would be an official release but just a technology > preview with no guarantees about compatibility with the actual 3 > series releases (whenever they happen). > > - robert > > [ ] +1 Great! > [ ] +0 Yeh, whatever > [ ] -0 Whatever > [ ] -1 Do I Look bovverd? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-570) James insert a Return-Path: null in outgoing email
[ http://issues.apache.org/jira/browse/JAMES-570?page=comments#action_12422080 ] Soren Hilmer commented on JAMES-570: The current SMTP specification is in (http://www.faqs.org/rfcs/rfc2821.html). It has a lot more detail on this subject in section 4.4 > James insert a Return-Path: null in outgoing email > -- > > Key: JAMES-570 > URL: http://issues.apache.org/jira/browse/JAMES-570 > Project: James > Issue Type: Bug >Reporter: Norman Maurer >Priority: Blocker > Fix For: 2.3.0b4 > > > At the moment james insert a Return-Path: null to outgoing emails. That is > not correct. On outgoing emails no Return-Path should be insert. > From RFC (http://www.faqs.org/rfcs/rfc821.html): > When the receiver-SMTP makes the "final delivery" of a > message it inserts at the beginning of the mail data a > return path line. The return path line preserves the > information in the from the MAIL command. > Here, final delivery means the message leaves the SMTP > world. Normally, this would mean it has been delivered to > the destination user, but in some cases it may be further > processed and transmitted by another mail system. > We have also to get sure what todo if there is allready one ( should never > happen). Should we keep the header or strip it. -- 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]
[jira] Commented: (JAMES-525) Add support for signing/decrypt messages with openPGP
[ http://issues.apache.org/jira/browse/JAMES-525?page=comments#action_12415536 ] Soren Hilmer commented on JAMES-525: BouncyCastle can handle PGP as well as S/MIME. So why introduce a new dependancy. > Add support for signing/decrypt messages with openPGP > - > > Key: JAMES-525 > URL: http://issues.apache.org/jira/browse/JAMES-525 > Project: James > Type: New Feature > Reporter: Norman Maurer > > Maybe we could add suport for signing/decrypting messages with openPGP. There > seems to be a java implemention for that. > See http://www.cryptix.org/ -- 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]
[jira] Commented: (JAMES-52) 8bitmime capabilities missing
[ http://issues.apache.org/jira/browse/JAMES-52?page=comments#action_12378915 ] Soren Hilmer commented on JAMES-52: --- So SUN finally closed this bug (4403733) as fixed apparently in JavaMail 1.4. Great! > 8bitmime capabilities missing > - > > Key: JAMES-52 > URL: http://issues.apache.org/jira/browse/JAMES-52 > Project: James > Type: Improvement > Components: SMTPServer > Versions: 2.0a3, 2.1.3, 2.2.0 > Environment: Operating System: All > Platform: All > Reporter: brady moritz > Assignee: Stefano Bagnara > Fix For: 2.3.0a1 > > I am using an IIS front end server which forwards email to the james backend > server. The front server accepts 8bitmime messages but then cannot forward > them > to the james server, resulting in an error message being sent to the > admininstrator(me). It should be a simple matter to add support for 8 bit and > it may even be supported intrinsicly, but the james server does nont > advertise > it via the EHLO commannd. -- 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]
[jira] Commented: (JAMES-124) Add the ability to "kick" the outgoing queue
[ http://issues.apache.org/jira/browse/JAMES-124?page=comments#action_12369626 ] Soren Hilmer commented on JAMES-124: I totally follow Noels view. We allready have something like this in the FromRepository mailet, where any mail received by this mailet, will trigger a re-spooling of mails in some repository. I do belive however that these control messages ought to be kept out of the normal mail flow. This will also make it easier to control who are allowed to inject such messages. > Add the ability to "kick" the outgoing queue > > > Key: JAMES-124 > URL: http://issues.apache.org/jira/browse/JAMES-124 > Project: James > Type: New Feature > Components: MailStore & MailRepository > Versions: 2.0a3, 2.1.3, 2.2.0 > Environment: Operating System: All > Platform: All > Reporter: Jason Webb > Priority: Minor > > It would be nice to be able to "kick" the outgoing queue to force the queue > to > deliver all it's pending mail. This is useful after a problem that affects > all > mail deliveries. > On a related note the SMTP might also want to support ETRN as well if there > anybody uses it anymore. -- 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]
[jira] Closed: (JAMES-428) Deadlock in ServerConnection
[ http://issues.apache.org/jira/browse/JAMES-428?page=all ] Soren Hilmer closed JAMES-428: -- > Deadlock in ServerConnection > > > Key: JAMES-428 > URL: http://issues.apache.org/jira/browse/JAMES-428 > Project: James > Type: Bug > Reporter: Soren Hilmer > Assignee: Soren Hilmer > Fix For: 2.3.0 > > When dispose() is called on ServerConnection, it in turn calls dispose() on > all runners, but these runners are still running and waits for their run() to > finish, unfortunately that requires grapping the lock on > ClientConnectionRunners, which at that time is held by the dispose() call on > ServerConnection. -- 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]
[jira] Resolved: (JAMES-428) Deadlock in ServerConnection
[ http://issues.apache.org/jira/browse/JAMES-428?page=all ] Soren Hilmer resolved JAMES-428: Fix Version: 2.3.0 Resolution: Fixed > Deadlock in ServerConnection > > > Key: JAMES-428 > URL: http://issues.apache.org/jira/browse/JAMES-428 > Project: James > Type: Bug > Reporter: Soren Hilmer > Assignee: Soren Hilmer > Fix For: 2.3.0 > > When dispose() is called on ServerConnection, it in turn calls dispose() on > all runners, but these runners are still running and waits for their run() to > finish, unfortunately that requires grapping the lock on > ClientConnectionRunners, which at that time is held by the dispose() call on > ServerConnection. -- 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]
[jira] Created: (JAMES-428) Deadlock in ServerConnection
Deadlock in ServerConnection Key: JAMES-428 URL: http://issues.apache.org/jira/browse/JAMES-428 Project: James Type: Bug Reporter: Soren Hilmer Assigned to: Soren Hilmer When dispose() is called on ServerConnection, it in turn calls dispose() on all runners, but these runners are still running and waits for their run() to finish, unfortunately that requires grapping the lock on ClientConnectionRunners, which at that time is held by the dispose() call on ServerConnection. -- 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]
Fwd: Re: [dev-crypto] ReadSignedMail.java example
FYI: This was just posted on the BouncyCastle list, so my rollback to 1.3.2 yesterday, looks like the right choice. --Søren -- Forwarded Message -- Subject: Re: [dev-crypto] ReadSignedMail.java example Date: Saturday 15 October 2005 05:52 From: David Hook <[EMAIL PROTECTED]> To: CHAPUIS Jean-Marc <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Further on this issue, the problem has has been confirmed as a bug in the Base64 decoder in JavaMail. Anyone using base64 should stay away from JavaMail 1.3.3 - the decoder will periodically drop bytes from the stream. Regards, David On Mon, 2005-10-10 at 09:58 +0200, CHAPUIS Jean-Marc wrote: > Hello, > > For information, with javamail 1.3.3 this example doesn't work > (CMSException). With javamail 1.3.2 there is no problem. > > Regards --- -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-416) Upgrade to javamail-1.3.3
[ http://issues.apache.org/jira/browse/JAMES-416?page=all ] Soren Hilmer resolved JAMES-416: Resolution: Fixed Downgraded to 1.3.2 > Upgrade to javamail-1.3.3 > - > > Key: JAMES-416 > URL: http://issues.apache.org/jira/browse/JAMES-416 > Project: James > Type: Task > Versions: 2.3.0 > Reporter: Stefano Bagnara > Assignee: Stefano Bagnara > Priority: Minor > Fix For: 2.3.0 > > Probably only performance improvement on base64 encoding/decoding. > Most of the other changes are around IMAP (client) and we don't use it. -- 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]
[jira] Resolved: (JAMES-425) Empty quoted localparts does not lead to parseexception
[ http://issues.apache.org/jira/browse/JAMES-425?page=all ] Soren Hilmer resolved JAMES-425: Resolution: Fixed > Empty quoted localparts does not lead to parseexception > --- > > Key: JAMES-425 > URL: http://issues.apache.org/jira/browse/JAMES-425 > Project: James > Type: Bug > Versions: 2.3.0 > Reporter: Soren Hilmer > Assignee: Soren Hilmer > > MailAddress does a check: > if (userSB.toString().length() == 0) > To ensure the mailaddress has a non-empty localpart, but for quoted > localparts the result after parsing: ""@apache.org does not have length 0 but > length 2 -- 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]
[jira] Created: (JAMES-425) Empty quoted localparts does not lead to parseexception
Empty quoted localparts does not lead to parseexception --- Key: JAMES-425 URL: http://issues.apache.org/jira/browse/JAMES-425 Project: James Type: Bug Versions: 2.3.0 Reporter: Soren Hilmer Assigned to: Soren Hilmer MailAddress does a check: if (userSB.toString().length() == 0) To ensure the mailaddress has a non-empty localpart, but for quoted localparts the result after parsing: ""@apache.org does not have length 0 but length 2 -- 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]
Re: Switch to Loom 1.0RC3
> > Does phoenix trunk supports hotdeploy/undeploy/reload of applications? Not sure about hotdeploy, but undeploy and reload are suported. Both can be achieved through the JMX interface. One caveat with James and our standard distribution is that, Phoenix is ran in a mode where it shuts-down when no applications are running, so unloading James shuts-down the Phoenix container. This can be circumvented by using the p (persist) option to phoenix. --Søren > > > -- > > peter royal > > Thank you for your help, > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
This is the usual deep versus shallow copy discussion, and actually both methods make sense for different purposes. I think we should provide a deep-duplicate or such method, as there might be someone out there, who has coded against the shallow copy behaviour. --Søren On Friday 09 September 2005 09:45, Stefano Bagnara (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/JAMES-421?page=comments#action_1232300 >6 ] > > Stefano Bagnara commented on JAMES-421: > --- > > Here is what it happens in my test: > I send a mail "mail1" to [EMAIL PROTECTED] and [EMAIL PROTECTED] and "original > body" body. The first matcher split the mail1 by duplicating it to > "mail1-!27120": it then remove a recipient from mail1 and the other from > mail1-!27120. mail1 run to the fist MyMailet that change its body to new > text 0. Both Mails run then through the second MyMailet that should change > the body of one mail to "new text 1" and the body of the other mail to "new > text 2". I then print the 2 bodies: I have 2 messages with "new text 2" > body and NO ONE with "new text 1". > > - AbstractRedirect does correctly clone the MimeMessage after the call to > MailImpl.duplicate - Many mailets just use sendMail with the shared > MimeMessage: we should add a comment to mailetContext sendMails to let the > use know that we lock the MimeMessage until we processed it and we never > change it. - LinearProcessor (after partial matching) does duplicate and > this way sends multiple Mails with sharing MimeMessage to the following > mailets. > > We could solve the issue by cloning the MimeMessage in LinearProcessor but > this is too easy to exploit: IMHO we should change the duplicate so that we > wrap the object with a "CopyOnWrite" shield: so we can safely share the > MimeMessage also when storing it and after multiple operations. > > > MailImpls sharing MimeMessage's! > > > > > > Key: JAMES-421 > > URL: http://issues.apache.org/jira/browse/JAMES-421 > > Project: James > > Type: Bug > > Components: James Core > > Versions: 2.3.0, 2.2.0 > > Reporter: Stefano Bagnara > > Assignee: Stefano Bagnara > > Priority: Critical > > Fix For: 2.3.0 > > Attachments: LinearProcessorTest.java > > > > LinearProcessor match a single recipient for a 2 recipient mail. > > it run "MailImpl.duplicate". duplicate DOES NOT clone the "MimeMessage". > > The following mailet will handle 2 different MailImpl sharing the same > > MimeMessage. Attached is the proving test. -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-crypto] warning about JavaMail 1.3.3
Well good questions, I read your entry on the upgrade, wher you state: "Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. " So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available. --Søren On Thursday 08 September 2005 11:25, Stefano Bagnara wrote: > > Just saw this on the BouncyCastle mailinglist, as we provide > > mailets using BouncyCastle we should perhaps revise upgrading > > to JavaMail 1.3.3. > > > > --Søren > > Hi Søren, > > Thank you for pointing this out. What should we do? > I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. > Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? > Should we add a note in the config.xml just before the SMIME stuff? > > Stefano > > > Subject: [dev-crypto] warning about JavaMail 1.3.3 > > Date: Thursday 08 September 2005 00:25 > > From: David Hook <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > > > We're not sure exactly what's happening still, but it appears > > that on some platforms, under some circumstances, Base64 > > decoding, or something underlying it, in JavaMail 1.3.3 > > breaks horribly and produces data with lots of extra bytes of > > the value 0x00 and 0xff. The upshot of this is that messages > > containing Base64 encoded data, such as S/MIME messages will > > no longer work as the data stream containing the encoded > > message has become corrupted. > > > > If S/MIME starts causing exceptions we recommend moving back to 1.3.2. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [dev-crypto] warning about JavaMail 1.3.3
Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren -- Forwarded Message -- Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. Regards, David --- -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
FYI, I compared our codes and while functionally equivalent, I must admit that your fix was cleaner and simpler ;-( So let us stick to that. --Søren On Wednesday 07 September 2005 09:25, Stefano Bagnara wrote: > > You move fast Stefano! I was about to commit my fix for it, > > when I ran into the SpoolManager issues. > > I will compare our fixes :-) > > Feel free to overwrite my changes with yours! Mine has been a really fast > fix. > I will run my test against your code, eventually! > > Stefano > > PS: sorry, I've seen you have the bug assigned but I was not sure you were > working on it so I gave it a try. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
I at least cannot reproduce the behaviour, which lead to this patch any longer. I will do some more tests, and report if any anomalies occur. --Søren On Wednesday 07 September 2005 12:53, Stefano Bagnara wrote: > I just committed my patch to AvalonMailRepository. > > IMHO this is a critical change and we should test it a lot before the > release. > > I'm now trying the same chages in the JDBCMailRepository to see if this > removes the "delay". > > Stefano > > > > I also tried using Derby/db on trunk, and saw "just" the delay. > > > > This is "known". > > > > > I will try out your patch. > > > > Don't try the one I pasted. I already had to change it due to > > unsynchronized notification. > > Just testing a further change, hope I'll commit the change > > soon (stay tuned). > > > > Stefano > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
I have now tried to downgrade to 2.2.0, and I cannot reproduce the effect
there (only tried filerepositories on this version).
I also tried using Derby/db on trunk, and saw "just" the delay.
I will try out your patch.
--Søren
On Wednesday 07 September 2005 11:30, Stefano Bagnara wrote:
> > > Can you try downgrading to 2.2.0 and verify wether the
> >
> > issue is there
> >
> > > or not?
> >
> > Will do that today.
> >
> > > Can you try using db/derby to check wether the issue is
> >
> > there or not?
> >
> >
> > Sure.
>
> I'm testing a patch to both JDBC and Avalon repositories.
> It seems working better than before. I'll run my stress-tests and
> eventually commit the code so you can test it, too!
>
> Stefano
>
> --
>
>
> Index:
> james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
> ===
> ---
> james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
> (revision 233041)
> +++
> james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
> (working copy)
> @@ -205,6 +205,7 @@
> //synchronized (this) {
> //notifyAll();
> //}
> +notify();
> return true;
> } else {
> return false;
> Index:
> james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
> ===
> --- james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
> (revision 233041)
> +++ james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
> (working copy)
> @@ -494,7 +494,7 @@
> *
> * @return true if successfully released the lock, false otherwise
> */
> -public synchronized boolean unlock(String key) {
> +public boolean unlock(String key) {
> if (lock.unlock(key)) {
> if ((DEEP_DEBUG) && (getLogger().isDebugEnabled())) {
> StringBuffer debugBuffer =
> @@ -508,6 +508,7 @@
> getLogger().debug(debugBuffer.toString());
> }
> //notifyAll();
> +notify();
> return true;
> } else {
> return false;
> @@ -521,7 +522,7 @@
> *
> * @return true if successfully obtained the lock, false otherwise
> */
> -public synchronized boolean lock(String key) {
> +public boolean lock(String key) {
> if (lock.lock(key)) {
> if ((DEEP_DEBUG) && (getLogger().isDebugEnabled())) {
> StringBuffer debugBuffer =
> @@ -546,7 +547,17 @@
> */
> public void store(MailImpl mc) throws MessagingException {
> Connection conn = null;
> +boolean wasLocked = true;
> +String key = mc.getName();
> try {
> +synchronized(this) {
> + wasLocked = lock.isLocked(key);
> +
> + if (!wasLocked) {
> + //If it wasn't locked, we want a lock during the
> store
> + lock.lock(key);
> + }
> +}
> conn = datasource.getConnection();
>
> //Need to determine whether need to insert this record, or
> update it.
> @@ -775,6 +786,10 @@
> throw new MessagingException("Exception caught while storing
> mail Container: " + e);
> } finally {
> theJDBCUtil.closeJDBCConnection(conn);
> +if (!wasLocked) {
> +//If it wasn't locked, we need to now unlock
> +lock.unlock(key);
> +}
> }
> }
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax:+45 72 30 64 02
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
I am with Noel on this. We should not do anything that means we get tied more to Avalon/Excalibur. On the other hand I liked the advantages a lot, as I have experienced massive classloader problems with Phoenix, I do a lot of dynamic reloading of .sar's and on Windows this leads to lost handles :-( Maybe we can do some code that enables the use of org.apache.james.util.dbcp.JdbcDataSource with Loom (just thinking aloud here, as I have not investigated the problem). --Søren On Wednesday 07 September 2005 04:37, Noel J. Bergman wrote: > > Should we move to Loom? > > Not if it means some of the things you noted. I am particularly not keen > to start using more excalibur code instead of Jakarta Commons code. > > > we could avoid using DBCP at all. > > But we want to use DBCP. It is well-tested, supported and broadly used. > > And I really don't want to tie us more tightly to Avalon. Rather, we > should incrementally detach the remaining bits, so that we can move to > another container architecture. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
On Tuesday 06 September 2005 15:25, Stefano Bagnara wrote: > > > I'm experiencing spooling issues with file repositories too. > > > > Well, I haven't until now :-( > > Can you try downgrading to 2.2.0 and verify wether the issue is there or > not? Will do that today. > Can you try using db/derby to check wether the issue is there or not? > Sure. > My tests results are that filerepositories have this problem in 2.2.0 and > in trunk. Db is working in both. > > > > Can you try using the db/derby repositories and see wether > > > > you see the > > > > > same problem? > > > > I could, but I need file repositories for my production > > deployments, so I will try to figure this one out instead. > > I would start looking for differences between JDBCMailRepository and > AvalonMailRepository (e.g: JDBCMailRepository.unlock is synchronized) > More: AvalonMailRepository.store does lock/unlock a message not already > locked while JDBCMailRepository does not lock/unlock such messages. > > I've experienced issues with DB repositories also, but they just delayed > the spooling by 60 seconds (probably, for db, the notify does not work > fine). > > I don't use FileRepositories in production because my stresstests provided > exceptions in locking/unlocking EVERY time: > http://issues.apache.org/jira/browse/JAMES-397 > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
On Tuesday 06 September 2005 15:12, Stefano Bagnara wrote: > > I am having trouble with the JamesSpoolManager in the trunk. > > I experience mails hanging in the spool, it looks like the > > offending piece of code is the return statement in line 418. > > The reason I suspect that line is that I cannot reproduce the > > effect if I remove the line. > > If you remove the return you change the current behaviour. Yes, I realize that. I just remembered (like Noel) that I had seen a patch a while back which included this exact return, commented out. > > Currently each spool thread get a message from the spool, run it in the > processor associated with the current spool and returns. > > If you remove the return then a single thread will bring the mail to GHOST > in a single processing. At the end of each processor the LinearProcessor > will store each mail in the spool (currently there are no drowbacks in > storing the same message multiple time without accepting them again, but I > did not changed it because I'm not sure it is a good thing) > > IMHO the problem is in the spool.unlock implementation for the file > repository. Yes, you are probably right. > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
You move fast Stefano! I was about to commit my fix for it, when I ran into the SpoolManager issues. I will compare our fixes :-) --Søren On Wednesday 07 September 2005 00:34, Stefano Bagnara (JIRA) wrote: > [ http://issues.apache.org/jira/browse/JAMES-413?page=all ] > > Stefano Bagnara resolved JAMES-413: > --- > > Resolution: Fixed > > I was working on DNSServer so I fixed this: Soren, please review the patch. > > > James does not resolve CNAME DNS registrations > > -- > > > > Key: JAMES-413 > > URL: http://issues.apache.org/jira/browse/JAMES-413 > > Project: James > > Type: Bug > > Components: DNSServer > > Versions: 2.2.0 > > Reporter: Soren Hilmer > > Assignee: Stefano Bagnara > > Fix For: 2.3.0 > > Attachments: DNSServerTest.java > > > > James does not resolve CNAME DNS entries as required by RFC-2821 sections > > 3.6 and 5 -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
On Tuesday 06 September 2005 14:59, Stefano Bagnara wrote: > > Hi, > > > > I am having trouble with the JamesSpoolManager in the trunk. > > I experience mails hanging in the spool, it looks like the > > offending piece of code is the return statement in line 418. > > The reason I suspect that line is that I cannot reproduce the > > effect if I remove the line. > > > > Have anyone seen something similar, or can someone (Stefano) > > provide the rationale behind this particular return statement. > > I will do some more debugging to better understand what happens. > > I'm experiencing spooling issues with file repositories too. Well, I haven't until now :-( > > The return statement is there since long before I committed my patches ;-) > (the annotation show that the return line has been written on may 2001). In > fact I only done minor changes to the spoolmanager (it now just gets > mailetloader/matcher loader as avalon services instead of running its own). > > I've also tested 2.2.0 and I've experienced the same spool problems using > file repositories. > > IMHO file repositories lock/unlock is not (has never been?) working fine. Probably true. > > If you send more mails you will see that the one in the spool will start > being elaborated. Yes, just tried that, maybe as you say it has allways been there, only I have just noticed it now. > > Can you try using the db/derby repositories and see wether you see the same > problem? I could, but I need file repositories for my production deployments, so I will try to figure this one out instead. --Søren > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spoolmanager blues
Hi, I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. The reason I suspect that line is that I cannot reproduce the effect if I remove the line. Have anyone seen something similar, or can someone (Stefano) provide the rationale behind this particular return statement. I will do some more debugging to better understand what happens. regards Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - 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]
[jira] Commented: (JAMES-406) Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix)
[ http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318984 ] Soren Hilmer commented on JAMES-406: Ahh, yes you are right it was the CVS that had the fixes. > Investigate about libraries upgradability > (cornerstone/excalibur/avalon/phoenix) > > > Key: JAMES-406 > URL: http://issues.apache.org/jira/browse/JAMES-406 > Project: James > Type: Task > Reporter: Stefano Bagnara > Assignee: Stefano Bagnara > > We should try to upgrade to the latest libraries when feasible. -- 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]
[jira] Commented: (JAMES-406) Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix)
[ http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318979 ] Soren Hilmer commented on JAMES-406: I know of a few bugs in the Phoenix we currently use (from the top of my head it had to do with JMX and classloading) which seams fixed in at least Phoenix 4.0.3. Also to know the source we use is major improvement IMO. > Investigate about libraries upgradability > (cornerstone/excalibur/avalon/phoenix) > > > Key: JAMES-406 > URL: http://issues.apache.org/jira/browse/JAMES-406 > Project: James > Type: Task > Reporter: Stefano Bagnara > Assignee: Stefano Bagnara > > We should try to upgrade to the latest libraries when feasible. -- 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]
Re: Next release (Was: Merging version 2.2.1 to 3.0 and 3.0 roadmap)
On Sunday 07 August 2005 19:32, Noel J. Bergman wrote: > Stefano Bagnara wrote: > > BXA issues? Are they specific to James or a new issue > > regarding all ASF projects? > > General to all code developed and/or exported from the USA that contains > any crypto code. Adding S/MIME support to JAMES created the problem. > Well the problem is not the S/MIME code itself, as it merely leverages on the BouncyCastle api for the crypto-routines. The fact that we bundle BouncyCastle is actually the real problem. Why not have users download BC themselves (like with JavaMail and JAF), this would avoid the BXA issues. This is also the approach chosen by "Apache XML Security", see bottom of this page: http://xml.apache.org/security/Java/installation.html --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
On Tuesday 05 July 2005 18:18, Noel J. Bergman wrote: > Soren Hilmer wrote: > > Just noticed that we are still using the "untagged" version of Phoenix. > > I thought that it was a goal of the merger process to get to Phoenix > > version 4.0.4 (isn't that the latest) or have I missed some discussion > > on this? > > I thought that Stephen and Co. had already updated Phoenix when updating > the rest of the Avalon components. If not, we should try to find the right > code and get it included. > Well I you look at the phoenix-bin in trunk it is exactly the same as in the old branch_2_1_fcs also starting the trunk-James gives states Phoenix 4.0.1, so... > Where do you see Phoenix v4.0.4? I see v4.0.3 under tags, but nothing > later. Hmmm, it is sitting here on my disk :-) I downloaded it from ASF a while back (February 18. 2004 to be exact), but the download pages seams gone with the project :-( I can point you to a mirror here: http://www.axint.net/apache/avalon/phoenix/v4.0.4/ Do you by any chance know why ASF has removed Avalon,Phoenix and related downloads. As we keep saying, even while the Avalon project has died, the code is still fine. So there would be no reason to disable downloads of the released versions. Dead projects code could/should be moved to some area for unsupported code or something, "ASF Cemetary" perhaps :-) Also totally unrelated, I noticed that the James home page states: "James requires Java 1.4", again have I missed a consensus on demanding 1.4 I thought that was scheduled for a future release. --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
Hi all, Just noticed that we are still using the "untagged" version of Phoenix. I thought that it was a goal of the merger process to get to Phoenix version 4.0.4 (isn't that the latest) or have I missed some discussion on this? --Søren On Monday 04 July 2005 18:40, [EMAIL PROTECTED] wrote: > > FYI, I have james-3.0-dev in production since some weeks now, > > and it runs quite well: I didn't have any single problem until now. > > So do I > > > I would vote +1 for a new release if asked ;-) > > > > Vincenzo > > So do I ;-) > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2 committer nominations
Stefano Bagnara [+1] Mike Heath [+1] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of Code - JAMES Fastfail
On Thursday 09 June 2005 11:58, Danny Angus wrote: > Are you going to ApacheConEU? We could arrange to brainstorm the > implementation details. Unfortunately not ;-( Great, we are totally on the same track then! --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer of Code - JAMES Fastfail
Hi Danny, > > My own idea config would look like: > > > > > > MAIL > > > FROM > > > > 5xx > foo-barred > > > > 220 > OK > > > > > I like your proposal for fastfail, very much in line with my own thoughts. I only have minor comments. As far as I can see we need another class to grasp state information in a consistent way. This is needed if the CommandHandlers action depends on earlier commands having been executed. My best example of this is that "MAIL FROM" might not be allowed unless STARTLS has been executed. Maybe all we need are attributes being passed to each CommandHandler. Also in your example: do you envision that "Mail" is a user-defined class? I would certainly prefer this as I envision an implementation where I would delegate the fastfail decissions to a policy-daemon that might be running outside James (like reuse of existing postfix policy-daemons). If "Mail" is not a user-defined class such an approach (while still doable) leads to a pretty cumbersome configuration. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding issue in BayesianAnalyzer?
Back to the issue. It is very likely to be fixcrlf causing the problem. I used to run it on som test-mails to ensure they ended in crlf, but as you have experienced it changes the charset as well :-( Luckily you can add an encoding option to fixcrlf like in this example: Don't now if ISO-8859-1 is the correct one to use maybe ISO-8859-15 is better --Søren On Wednesday 01 June 2005 00:55, Noel J. Bergman wrote: > Stefano Bagnara wrote: > > > IIRC, because it was intended to keep Windows users from > > > putting incorrectly formatted files into source control, and > > > to remove tabs. > > > > > > At least the latter should be addressed now by SVN. > > > > AFAIK the first is addressed by SVN. > > <> That's actually what I meant. The tabs issue is not addressed by > SVN. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EHLO and SIZE reply bug
No, this is clearly wrong! RFC-2821 states (page 30) that the first line in a multiline response to EHLO is the "250-domain" line --Søren On Thursday 12 May 2005 12:40, [EMAIL PROTECTED] wrote: > I got this reply from james server with a SIZE limit: > > 220 .domain.com SMTP Server (JAMES SMTP Server 2.2.1-dev) ready Thu, 12 > May 2005 10:35:58 + (GMT) > EHLO domain.com > 250-SIZE 512 > 250-.domain.com Hello domain.com (.domain.com [XXX.XXX.XXX.XXX]) > 250-AUTH LOGIN PLAIN > 250 AUTH=LOGIN PLAIN > > Is this correct? Shouldn't the SIZE header be under the first > "250-.domain.com Hello.." line? > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do we need fast-fail?
On Wednesday 11 May 2005 09:49, [EMAIL PROTECTED] wrote: > > Consider that some servers relay though James from an > > internal trusted network, they do not need to issue STARTTLS, > > others however are relaying through a public network an are > > thus required to issue STARTTLS (perhaps even with > > client-certificate authentication). > > So we do not disable STARTTLS for the internal servers, but > > on the other hand do not require it either. > > Sure, but this seems the normal standard behaviour. We only need a > configuration for > StartTLSSupport = disabled | enabled | required > > Isn't this enough to support the STARTTLS reply? No, a) if you specify "required" the internal servers will also need to execute STARTTLS b) if you specify "enabled" the external servers can relay without doing STARTTLS This is not what I want. Internal servers can always relay and external servers must use STARTTLS. Of course if the "authorizedAddresses", has priority over this setting, we are home free. > > The check to see wether the relay is supported or not because of AUTH or > STARTTLS will be done after the first RCPT so the "extension point" is the > RCPT and not the STARTTLS. Agreed, we just need to capture the state information (preferably in a stateobject as opposed to the current Hashmap) --Søren > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do we need fast-fail?
On Tuesday 10 May 2005 18:59, [EMAIL PROTECTED] wrote: > > On Tue, 2005-05-10 at 16:37 +0200, [EMAIL PROTECTED] wrote: > > > I think that this check should be done on the MAIL FROM or > > > the RCPT TO and so not directly related to the STARTTLS and > > > AUTH. > > > > > > I would add to my list: > > > B2. "mail from" allowed only after AUTH/STARTTLS > > > C2. "rcpt to" you can write to this recipient only > > > when using AUTH/STARTTLS. > > > > The mechanisms for requiring STARTTLS are described in the > > STARTTLS RFC, http://www.faqs.org/rfcs/rfc2487.html see Section 5. > > Thank you Mike, > > This seems to confirm that we could check wether STARTTLS has been sent > when we receive a MAIL FROM or RCPT TO and reply with "530 Must issue a > STARTTLS command first" when the recipient is not local (for example). > > Does anyone think that it would be useful to select wether to allow the > "STARTTLS" or not depending on some business rule and not only via a smtp > server configuration parameter? This would be a further use-case to add to > the list, but I think this is not so usefull: I can't find why we should > disable STARTTLS to specific IPs Consider that some servers relay though James from an internal trusted network, they do not need to issue STARTTLS, others however are relaying through a public network an are thus required to issue STARTTLS (perhaps even with client-certificate authentication). So we do not disable STARTTLS for the internal servers, but on the other hand do not require it either. --Søren > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do we need fast-fail?
On Tuesday 10 May 2005 15:34, [EMAIL PROTECTED] wrote: > > > In order to continue the discussions about the possible > > > > solutions for > > > > > this list I would like to know if you can provide more fast-failing > > > scenarios (probably due to SMTP extensions like AUTH, > > > > STARTTLS, etc). > > > > I believe that we should support fastfail for both STARTTLS and AUTH. > > Ok, but can you provide a real use case? What would you like to do > fast-failing there? > I mean that generic behaviours can be hardcoded, I want to know what kind > of fastfail you are imagining to be configurable for real. The use case is indirectly, what I would like is to have forinstance DATA fastfail if STARTTLS/AUTH has not been executed. That allows us to only accept mail securely and/or from an authenticated source. So what is needed in this case is an internal state that a later command can check and fastfail upon. --Søren > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do we need fast-fail?
> > In order to continue the discussions about the possible solutions for this > list I would like to know if you can provide more fast-failing scenarios > (probably due to SMTP extensions like AUTH, STARTTLS, etc). I believe that we should support fastfail for both STARTTLS and AUTH. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do we need fast-fail?
> > > D. SMTP "DATA": james currently reply "250 Message received" for each > > message under the maximum size handled: > > D1. add antivirus/antispam and other content filters and provide > > dedicated failure feedback. > > I'm not a big fan of this step, since I don't see much benefit to > fast-failing after we've already accepted the full message, but dunno. > It eliminates so IO, but then makes your server less scalable. In any > case, the mailet API maps exactly here. > IMO if we can refuse the reception of the mail at the SMTP protocol level, even at this late point. We technically haven't received the message and thus are not obliged to handle it further thereby possibly saving resources. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POJO pattern
+1 On Monday 11 April 2005 10:57, Danny Angus wrote: > I propose that work commence to extract James's "value add" IP from classes > supporting Avalon specific lifecycle attributes, and Avalon component > dependance, to POJO classes. > I further propose that these POJO's are designed to support IoC but are > agnostic in their choice of SDI/CDI > Therfore I propose that these classes be designed along SDI lines in order > that the change is evolutionary and that they can later be factored to > allow their use by CDI frameworks by those people who wish to do so. > > The basic pattern will be to have agnostic POJO's contain James' domain > specific code. > These POJO's will be extended to produce SDI, CDI, J2EE, or bespoke > pattern-specific lifecycle specialisations through inheritance, delegation > or injection. > These specialisations can then be used to assemble behavioural solutions in > CDI SDI or J2EE containers which can be maintaned independantly of the > domain specific code in the POJO's > > For example: > SMTPHandler -> CDISMTPHandler > -> SpringSMTPHandler > -> JCASMTPHandler > -> AvalonSMTPHandler > > Please indicate your prefrence: > > [ ] +1 I agree that Agnostic SDI style POJO's are an effective first step > and will participate in the development work > [ ] +0 I neither agree nor disagree that Agnostic SDI style POJO's are an > effective first step but do not oppose the proposal > [ ] -0 I disagree that Agnostic SDI style POJO's are an effective first > step but do not oppose the proposal > [ ] -1 I disagree that Agnostic SDI style POJO's are an effective first > step and oppose the proposal because:.. > > 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 Limited. > > 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] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SpringJames vs. JamesNG
This is a very good point!
It is very easy to make a CDI wrapper around an SDI POJO, but the other way
around is rather difficult.
This is probably the strongest argument for SDI, I gave seen.
--Søren
On Friday 08 April 2005 12:47, Simon Funnell wrote:
> Use of CDI 'only' limits a component to certain types of containers, for
> example components with getter/setters patterns can have their dependencies
> changed at runtime, I believe CDI limits a components reuse in other
> projects.
>
> A container should ideally be able to use any component by supporting
> multiple component lifecycle types, Avalon describes/specifies a highly
> detailed lifecycle, Pico container a very simple lifecycle. The point is
> that a simple container cant manage a component with a complex lifecycle
> where as a sophisticated container could/should host any component
> lifecycle, therefore any component.
>
> - A good component will allow containers to create/manage their lifecycle.
> - A good framework will allow the management of multiple lifecycle types.
>
> I think the spring framework is a strong move in that direction container
> wise as the configurations are geared to wiring up components. This is
> close to being (if not is) a dynamic way of describing lifecycles of any
> type.
>
> Simon
>
>
> - Original Message -
> From: "Daniel Perry" <[EMAIL PROTECTED]>
> To: "James Developers List"
> Sent: Friday, April 08, 2005 11:02 AM
> Subject: RE: SpringJames vs. JamesNG
>
> > > Okay, so you prefer code looking like:
> > > p = new SomePOJO ("bla", null, null, null, null, "bli", null,
> > > null, null);
> > >
> > > to code looking like:
> > > p = new SomePOJO ();
> > > p.setBla("bla");
> > > p.setBli("bli");
> > >
> > > I must say, I prefer the latter.
> >
> > I prefer the CDI one.
> >
> > Take two cases:
> >
> > In a normal environment (ie where the container provides the
>
> dependencies),
>
> > the class will be instantiated by the container, so you wont be writing
> > "p
>
> =
>
> > new SomePOJO (...". So it doesnt matter which is used, as you'll never
> > see it!
> >
> > Now consider an environment where someone (who probably has no idea about
> > james's code) is using a component in their own code without DI. My
> > argument is that with CDI they are less likely to miss a dependency. The
> > dependencies are listed in an obvious place - the (only) constructor.
> > They have to provide them. They dont have to go find documentation that
> > says: "you must set bla, and bli after creating the class. You can set
> > other things, but they're optional."
> >
> > CDI makes sense to me. The constructor is where the initialisation of
> > the object takes place, and you can provide initiailisation parmaeters.
> > The constructor is only called once, so dependencies can easily be mate
> > immutable. Using CDI ensures that once an object exists, it is usable.
> > There is no easy way to determine what state an SDI object is in.
>
> Therefore
>
> > it seems logical that it is the place to introduce hard dependencies.
> >
> > > > Another way of avoiding "parameter bloat" is to identify those
> > >
> > > parameters
> > >
> > > > common to many of an application's Classes and gather them together
> > > > in
>
> a
>
> > > > single Class so that instances can be injected as a single object.
> > >
> > > Sure this works, but unfortunately have the effect that classes
> > > are created
> > > for the sole purpose as being place-holders. This leads to a more
> > > complicated
> > > class-hierarchy. Which IMO is to be avoided. Again KISS.
> >
> > Really? I thought this was the main principle of object orientation -
> > encapsulation. You take a bunch of related things, and bundle them
>
> together
>
> > inside an object. Say like, a person (could have a name, date of bith,
>
> etc)
>
> > or a CoreServices (could provide logging, configuration, etc)!
> >
> > > > The key point is that CDI does not force us to deal with a n*n-1
> > > > constructor problem. There are a number of patterns that can be
> > >
> > > applied to
> > >
> > > > avoid this and the associated "parameter bloat" problem.
> > >
> > > Unfortunately all these patterns to deal with parameter bloat
> > > introduces more
> > > complexity and are thus violating the KISS principle.
> >
> > I would argue against that. KISS doesnt mean do it in the least number
> > of classes, or do it in the least number of calls. It means "Keep It
> > Simple Stupid". Minimising the number of classes might contribute to
> > this, but i think the biggest factor is making it easy to understand, and
> > follow. Providing a CDI subclass of each SDI class is simple. Subclass
> > with one constructor. If you name it appropriately so that people can
> > find it,
>
> then
>
> > i dont think this violates KISS in any way!
> >
> > > I agree that we should not focus on any given container.
> > > Apparently we cannot
> > > agree upon which concept JavaBean/CDI is the way to go, so I then m
Re: SpringJames vs. JamesNG
On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
> > No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I
> > prefer using the
> > JavaBean approach instead of CDI.
> > My concern is that CDI does not facilitate optional
> > properties very well.
> > If you have some POJO, with just 2 optional properties that
> > will lead to 4
> > constructors!! This is what I call constructor bloat.
>
> Many of my thoughts regarding a container for James are already recorded in
> the mailing lists. I will not repeat them here.
>
> My interpretation of the CDI metaphor allows no tolerance for ambiguity.
> There should be exactly one public constructor for a Class that encompasses
> all possible parameters. Optional parameters may be passed into this
> constructor as null. This is the contract a Class honours. As there is only
> one constructor, there is no "constructor bloat".
>
Okay, so you prefer code looking like:
p = new SomePOJO ("bla", null, null, null, null, "bli", null, null, null);
to code looking like:
p = new SomePOJO ();
p.setBla("bla");
p.setBli("bli");
I must say, I prefer the latter.
> You might worry that this leads to "parameter bloat", but practical
> experience reveals that with a well structured architecture the number of
> parameters passed is not overwhelming. Moreover, it helps in the creation
> of this well structured architecture by focusing thought on the exact needs
> and responsibilities of each Class. This follows the old adage of "do one
> thing, do it well".
>
> On the rare occasions when this approach leads to too many redundant
> parameters for a particular application's usage of the Class, the
> application's developer may create or re-use a subclass with a public
> constructor that offers just the required parameters. Of course this will
> not work if the Class of interest has been marked final. Then a proxy Class
> is required to do the same job.
This I find complex, and a good argument against CDI. I favour the KISS
principle.
>
> Another way of avoiding "parameter bloat" is to identify those parameters
> common to many of an application's Classes and gather them together in a
> single Class so that instances can be injected as a single object.
>
Sure this works, but unfortunately have the effect that classes are created
for the sole purpose as being place-holders. This leads to a more complicated
class-hierarchy. Which IMO is to be avoided. Again KISS.
> The key point is that CDI does not force us to deal with a n*n-1
> constructor problem. There are a number of patterns that can be applied to
> avoid this and the associated "parameter bloat" problem.
>
Unfortunately all these patterns to deal with parameter bloat introduces more
complexity and are thus violating the KISS principle.
> Getting into the CDI mindset is an evolutionary journey. First forsaking
> Service lookup, then appraising the upsides and downsides of each of the
> dependency injection approaches.
>
> Much of my commercial time is currently spent facilitating architects and
> developers making this journey. A good starting point is to visit
> http://picocontainer.codehaus.org. Next, choose a component (set of
> inter-operating classes) with which you are familiar and refactor them to
> follow the CDI metaphor. As understanding grows the entirely reasonable
> doubts dissipate.
>
> Prior to this journey being completed there are no criteria to evaluate the
> strengths and weaknesses of any given container. As we don't know what we
> need a container to do, how can we say it satisfies our needs?
>
> This is why I have steered clear of advocating any particular container
> thus far. However, if you hadn't guessed already, my view is that CDI is
> the best of the current bunch of DI approaches.
>
> One further point is that we do not need to and should not code for a
> specific container. Rather we should develop to our chosen DI metaphor.
> This leaves people free to deploy our DI POJOs in any container supporting
> the metaphor, or wrap them for deployment in containers supporting other
> metaphors, such as flavours of J2EE EJBs and Connectors.
I agree that we should not focus on any given container. Apparently we cannot
agree upon which concept JavaBean/CDI is the way to go, so I then move in
favour of supporting both. That way we can run in any POJO container. As
someone (sorry forgot who) posted earlier this is quite easy as the CDI
constructor can be implemented like:
SomePOJO (String a, String b, String c, String d)
{
this();
setA(a); setB(b); setC(c); setD(d);
}
Alongside the mandatory no-args constructor.
--Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax:+45 72 30 64 02
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Re: SpringJames vs. JamesNG
On Friday 01 April 2005 11:06, [EMAIL PROTECTED] wrote: > > Someone asked for a road-map: > > 1. POJOification > > 2. Possibly taking ownership over a few Phoenix things > > [...] > > But I see this as done in concert, as you probably need to do > > 2. while doing 1. > > Here is a count of package dependency from the current svn 2_1_fcs branch > (pls note that I grouped class import into packages for a better overview): > > 32 import org.apache.avalon.cornerstone.services.connection.* > 10 import > org.apache.avalon.cornerstone.services.datasource.DataSourceSelector; > 24 import org.apache.avalon.cornerstone.services.scheduler.*; > 4 import org.apache.avalon.cornerstone.services.sockets.*; > 30 import org.apache.avalon.cornerstone.services.store.*; > 8 import org.apache.avalon.cornerstone.services.threads.ThreadManager; > 2 import org.apache.avalon.excalibur.collections.ListUtils; > 14 import org.apache.avalon.excalibur.datasource.DataSourceComponent; > 24 import org.apache.avalon.excalibur.io.*; > 74 import org.apache.avalon.excalibur.pool.*; > 22 import org.apache.avalon.excalibur.thread.*; > 108 import org.apache.avalon.framework.activity.*; > 2 import org.apache.avalon.framework.CascadingRuntimeException; > 186 import org.apache.avalon.framework.component.*; > 262 import org.apache.avalon.framework.configuration.*; > 4 import org.apache.avalon.framework.container.ContainerUtil; > 76 import org.apache.avalon.framework.context.Context; > 112 import org.apache.avalon.framework.logger.*; > 22 import org.apache.avalon.framework.service.*; > 2 import org.apache.avalon.phoenix.BlockContext; > 2 import org.apache.commons.dbcp.BasicDataSource; > 2 import org.apache.commons.net.pop3.POP3Client; > 2 import org.apache.commons.net.pop3.POP3MessageInfo; > 6 import org.apache.excalibur.threadcontext.ThreadContext; > > What dependencies would you like to remove? > What should be included in james? > What should be ported to geronimo's or other container services? I do not want to run under Geronimo, so... My goal is to move James, more or less in it's current state to a new environment, this new environment sort of determines what needs to be ported and what needs to be provided by James itself. > > I think that POJOification is really a simple task compared to this > analysis. I agree, but I also believe that it's futile to try and do this analysis upfront. --Søren > > I don't know much about avalon stuff so I can't understand what should be > removed to avoid too much dependency on not mantained code. > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SpringJames vs. JamesNG
On Thursday 31 March 2005 17:59, Serge Knystautas wrote: > Soren Hilmer wrote: > > Serge recently posted a mail to server-user saying that a container > > switch was a minor concern of ours (or at least something to that > > extent). > > I disagree on this, I believe that we have to make a decission on the > > container issue, to both keep existing comitters interested and possible > > attract new skilled people. > > I'll restate since it must have been unclear... WHICH new container we > move to is not important at this phase of development since we have to > change our current code to a bunch of POJOs. Ahh, we agree then! > > > The container issue is by far the one thing that is keeping myself from > > doing commits into James. I hate doing something today and having to redo > > it all over in a month or two. > > I'm in the same camp. > > > I tried to follow the discussion on JamesNG a while back, but as I at > > that time had little knowledge of neither Groovy nor Spring, I did not > > comment. > > > > I have now done some reading on the two subjects and believe that Spring > > is the way to go for James. My main concern on JamesNG (I know this is > > not Groovy related) is the CDI principle IMO this principle leads to > > constructor bloat if you want to have some properties with default > > values, and I believe we do. > > The Spring framework's Java-Bean approach is IMO a way better solution to > > the POJO-ification issue. > > How are you seeing JavaBean != POJO? I've always used them as > synonymous, except JavaBean's also has weird setter propertyeditor API > for setAsText stuff. No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I prefer using the JavaBean approach instead of CDI. My concern is that CDI does not facilitate optional properties very well. If you have some POJO, with just 2 optional properties that will lead to 4 constructors!! This is what I call constructor bloat. > > > Now I have started to convert James into POJO's the Spring way (only > > James.java so far), but as I stated above I hate doing things over, so > > let us take a vote. Is it going to be SpringJames or JamesNG. > > Could you explain what the differences are? The difference is CDI vs. JavaBean, just that. Someone asked for a road-map: 1. POJOification 2. Possibly taking ownership over a few Phoenix things 3. Making a SpringConfiguration which does the same as our current configuration. 4. Test 5. Celebrate But I see this as done in concert, as you probably need to do 2. while doing 1. And doing 3. afterwards is probably too tiresome. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SpringJames vs. JamesNG
Hi all, Serge recently posted a mail to server-user saying that a container switch was a minor concern of ours (or at least something to that extent). I disagree on this, I believe that we have to make a decission on the container issue, to both keep existing comitters interested and possible attract new skilled people. The container issue is by far the one thing that is keeping myself from doing commits into James. I hate doing something today and having to redo it all over in a month or two. I tried to follow the discussion on JamesNG a while back, but as I at that time had little knowledge of neither Groovy nor Spring, I did not comment. I have now done some reading on the two subjects and believe that Spring is the way to go for James. My main concern on JamesNG (I know this is not Groovy related) is the CDI principle IMO this principle leads to constructor bloat if you want to have some properties with default values, and I believe we do. The Spring framework's Java-Bean approach is IMO a way better solution to the POJO-ification issue. Now I have started to convert James into POJO's the Spring way (only James.java so far), but as I stated above I hate doing things over, so let us take a vote. Is it going to be SpringJames or JamesNG. I will start with a +1 for SpringJames. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
Is it not the case that CornerStone is no longer actively maintained (or is it just Avalon) In which case I would prefer moving them into James. If CornerStone is alive and well, submitting the code back would be a good move. But If my memory does not fail me completely (I often get the issues on Phoenix and CornerStone and Avalon mixedup in my head) the current James 2.1 branch is stuck with an old CornerStone build (actually one that is not even tagged in the CornerStone-CVS, so we cannot recreate it) in which case we also need to put the code into James. So the short story IMO is, put it into James and submit it back if it makes sense (the two implementations may of course differ depending on the CornerStone version). --Søren On Wednesday 22 December 2004 15:22, Jason Webb wrote: > > -Original Message- > > From: Soren Hilmer [mailto:[EMAIL PROTECTED] > > Sent: 22 December 2004 14:15 > > To: James Developers List > > Subject: Re: Repositories > > > > On Wednesday 22 December 2004 13:50, Danny Angus wrote: > > > Soren, > > > Derby would be embedded in James, it would not be visible to users at > > > > all, > > > > > and require no additional admin or configuration. > > > The messages would not be visible in the filesystem, but that would be > > > > the > > > > > only drawback. > > > > Okay, sounds a little better. > > > > Still I must say I prefer the file repositories, it is a lot easier to > > support > > a mailserver when you can read the mails currently in process directly > > from > > the filesystem. > > This is AFAIK also the approach serious mailservers like Postfix does > > things. > > > > If we go for an all DB solution. We need better tools to show the > > repositories > > and messages within them. > > > > I can see the problems about destroying/renaming repositories, because > > those > > operations are not supported by CornerStone. > > > > Could it be a compromise that we require DB repositories only when IMAP > > is used, and thereby allowing existing setups to continue with > > file/filedb repositories? > > One repository to rule them all, one repository to find them. One > repository to rule them all and in the darkness bind them :) (Apologies to > JRR > > One of my primary design goals is to make sure the user can access their > email using POP3 or IMAP4 in whatever way they choose. I will implement the > file based repositories to have the required methods for IMAP. This will > involve changes to the cornerstone classes. Is the best thing to do with > these changes to move them into James proper or to attempt to submit > changes to the Cornerstone project? > > > --Søren > > > > > d. > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
On Wednesday 22 December 2004 13:50, Danny Angus wrote: > > Soren, > Derby would be embedded in James, it would not be visible to users at all, > and require no additional admin or configuration. > The messages would not be visible in the filesystem, but that would be the > only drawback. Okay, sounds a little better. Still I must say I prefer the file repositories, it is a lot easier to support a mailserver when you can read the mails currently in process directly from the filesystem. This is AFAIK also the approach serious mailservers like Postfix does things. If we go for an all DB solution. We need better tools to show the repositories and messages within them. I can see the problems about destroying/renaming repositories, because those operations are not supported by CornerStone. Could it be a compromise that we require DB repositories only when IMAP is used, and thereby allowing existing setups to continue with file/filedb repositories? --Søren > > 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 Limited. > > 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] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories
I feel very badly about doing that, as we suddenly demand installation of a DB to run James. I believe this is a major drawback for the installed userbase, much greater than a change from Java-1.3 to Java-1.4. I must admit that I have not followed the IMAP discussions closely, could you perhaps sum up, what the problem with the filebased repositories are in regard to IMAP? --Søren On Wednesday 22 December 2004 11:34, Jason Webb wrote: > I've only played with Cloudscape before (Derby's forerunner if you don't > know, I'm sure Danny does!). How would people feel about dropping file: > support altogether and only using db: repositories then? > However this would mean that dbfile: wouldn't work. I don't want to kill a > feature "accidentally" that a lot of people rely on. > > Any thoughts? > > -- Jason > > > -Original Message- > > From: Danny Angus [mailto:[EMAIL PROTECTED] > > Sent: 22 December 2004 10:20 > > To: James Developers List > > Subject: Re: Repositories > > > > I've been messing with Derby recently and wondered if we shouldn't > > just bundle derby for people who don't care what happens..? > > > > Otherwise I think we will need to deprecate the cornerstone ones in > > favour of something better for our sanity if nothing else. These have > > had "issues" for as long as I've been involved and I'd cheer, loudly, > > if we saw the back of them. I believe that the NNTP server uses a much > > simpler format for its file repo's, mabey you could re-use something > > from that? > > > > d. > > > > On Wed, 22 Dec 2004 09:55:15 -, Jason Webb <[EMAIL PROTECTED]> wrote: > > > Sorry to all those waiting for the IMAP work to be committed, but what > > > > with > > > > > changing jobs and looking after 2 small people my time has become a > > > > little > > > > > tight... > > > > > > However, this has not stopped me thinking about the biggest issue the > > > > IMAP > > > > > server faces and that is the repository interface. At the moment I feel > > > > I'm > > > > > trying to ram a very square peg into a very round hole and it's fairly > > > painful. > > > > > > The database repositories are simple to deal with as we (James) own the > > > code. My main issue is with the Cornerstone file: repositories as they > > > > are > > > > > "owned" by the Avalon project. I would like to make changes to these, > > > > but I > > > > > need to know if we are still going to be going forward with > > > Cornerstone/Avalon or whatever. > > > > > > -- Jason > > > > > > - > > > 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] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration
No problem for me either! On Tuesday 16 November 2004 11:14, Hes Siemelink wrote: > Works fine with Tortoise SVN on Windows. > > I checked out the 'trunk' -- is that OK? > I'm afraid it doesn't build out of the box, but what happens is > described pretty accurately in bug report JAMES-333 (which talks about > CVS) so I guess the migration was OK... > > Cheers, > > Hes. > > -Original Message- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: Monday, November 15, 2004 16:40 > To: [EMAIL PROTECTED] > Subject: Test SVN migration > > Noel has done a test migration of James CVS code to SVN. It's available > at: > > http://svn.apache.org/repos/test/james > > If anyone can give it a test and confirm it worked, we'll hopefully cut > over soon. -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merged code available to review
Hi Noel, I just tried this (sorry it took so long). I have found this: a) an extra MailImpl.java in the dnsserver package, this makes the whole thing unable to build. I assumed the one in core was correct and removed that (the 2 sources are not identical) b) org.apache.james.mailrepository.AvalonMailRepository.java does not import javax.mail.MessagingException, but uses it. c) org.apache.james.mailrepository.JDBCMailRepository, org.apache.james.tansport.JamesSpoolManager, did not import java.util.Collection d) org.apache.james.transport.mailets.JDBCAlias, org.apache.james.transport.mailets.JDBCVirtualUserTable, org.apache.james.transport.mailets.JDBCListserv all imports org.apache.avalon.cornerstone.services.datasource.DataSourceSelector but the class is called org.apache.avalon.cornerstone.services.datasources.DataSourceSelector (note s in datasources) e) org.apache.james.transport.mailets.listservcommands.BaseCommand, org.apache.james.transport.mailets.listservcommands.IListServCommand imports org.apache.james.transport.mailets.ICommandListservManager it is missing! f) org.apache.james.transport.mailets.listservcommands.BaseCommand, org.apache.james.transport.mailets.CommandListservProcessor org.apache.james.transport.mailets.FromRepository imports org.apache.james.util.RFC2822Headers but it is called org.apache.mailet.RFC2822Headers g) org.apache.james.tansport.JamesSpoolManager, did not import org.apache.james.core.MailImpl h) org.apache.james.core.MimeMessageWrapper did not import javax.mail.Session i) org.apache.james.core.MimeMessageWrapper does not import org.apache.avalon.cornerstone.blocks.masterstore.IOUtil unfortunately this class resides in an impl jar: cornerstone-store-impl-1.0.jar hmmm. j) org.apache.james.core.AbstractJamesService still had som code that depended on connectionManger not beeing an JamesConnectionManager even though an explicit cast to the latter is made at initialization time. k) org.apache.james.James uses org.apache.avalon.framework.component.ComponentException; it should use ServiceException at that point ( l) org.apache.james.mailrepository.JDBCMailRepository did not import java.sql.Blob m) org.apache.james.transport.mailets.AvalonListservManager had repName declared incorrectly n) org.apache.james.util.connection.SimpleConnectionManager did not define public void connect(String arg0, ServerSocket arg1, ConnectionHandlerFactory arg2, ThreadPool arg3) as needed by the contract. o) org.apache.james.dnsserver.DNSServer also failed to build as the dnsjava distributed was dnsjava-1.4.3 not dnsjava-1.6.2 p) org.apache.james.util.connection.SimpleConnectionManager some clash between org.apache.excalibur.thread.ThreadPool and org.apache.avalon.excalibur.thread.ThreadPool Not sure yet what is the correct fix for this so just did something to make things compile q) org.apache.james.transport.mailets.AvalonListservManager, org.apache.james.transport.mailets.AvalonListserv did not declare that MessagingException could be thrown in init Pheww, finally things compiled! As for runtime stay tuned! -- Søren On Sunday 01 August 2004 23:41, Noel J. Bergman wrote: > I just finished a first cut at merging the branches. I haven't even had > time to do a build with it, and I may need to pick up some of Stephen's > most recent changes, but I need to get on the road to drive to Atlanta. > > A copy of the merged code is in > http://www.apache.org/~noel/james-merge-test.tgz. If you get a chance, > please take a look and let me know if you spot any problems or regressions. > Hopefully I will have time during an evening this week to make sure I have > picked up the most recent changes and get this thing building. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate from CVS to SVN
+1 On Sunday 07 November 2004 18:37, Noel J. Bergman wrote: > I propose that we migrate from CVS to Subversion ASAP (I should have time > to do it during ApacheCon next weekend). > > One of the underlying reasons for this is to invigorate JAMES development > by leveraging SVN capabilities. We can leverage Subversion's branching to > improve accessibility for committers to maintain their code on the server > instead of exclusively in their own working copies, as with my merger or > Jason Webb's work. > > I still have the merged work I did in the Spring, which I would update in a > branch, and then move to trunk/ after people review it. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: STARTTLS for JavaMail
Intent and intent, this is a snip from the README: "This SSL/TLS support in JavaMail works only when JavaMail is used on a version of J2SE that includes SSL support. We have tested this support on J2SE 1.4 and J2SE 1.5, which include SSL support. The SSL support is provided by the JSSE package, which is also available for earlier versions of J2SE. We have not tested such configurations" I read this as: if it works with anything but J2SE 1.4/1.5 you are in luck, if it does not don't blame us ;-) An yes, this could be a feature that will push our users toward 1.4+. --Søren On Tuesday 06 July 2004 06:15, Noel J. Bergman wrote: > > I am currently testing an early access release of JavaMail 1.3.2, > > and this versions implementation of STARTTLS, does not work under > > JDK 1.3. > > > > the readme states it has only been tested against JDK 1.4 and 1.5 > > Is there any intent for it to work with JDK 1.3, or is this providing a > capability that will tend to push our users to JDK 1.4+? > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: STARTTLS for JavaMail
Hi, I am currently testing an early access release of JavaMail 1.3.2, and this versions implementation of STARTTLS, does not work under JDK 1.3. with JSSE 1.0.2. But this was rather as expected as the readme states it has only been tested against JDK 1.4 and 1.5, and the SSL implementation has changed considerably between the standalone JSSE's and the JDK bundled ones. (Hope I am not violating some non-disclosure here, Bill) --Søren On Friday 02 July 2004 07:09, Serge Knystautas wrote: > Noel J. Bergman wrote: > >>>Is there any plan to support STARTTLS for the different stores (IMAP, > >>>POP3) and transport (SMTP) shipped with Sun's JavaMail implementation? > >> > >>Yes, this will be included in 1.3.2 for IMAP and SMTP. > >>I hope to get an Early Access version out next month. > > If they can figure out how to initiate TLS with the JDK 1.3 on the > client side, hopefully we can learn from them and do it on the server side. -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
On Friday 25 June 2004 03:51, Noel J. Bergman wrote: > > While I agree that we should be container neutral, it would be good to > > accomodate the extended, but optional, Avalon lifecycles into a reworked > > Mailet API so that it can be leveraged when available. > > I would be -1 regarding any contamination of the Mailet API with container > specific interfaces. But I do concur that we want to support dynamic > reconfiguration. That is something we can all collaborate on, that is more > of an issue for a Mailet Container than the Mailet API. I believe that we > already have enough in the Mailet API to support destroying and re-initing > Mailets. As you already noted to Stephen McConnell, "The current Mailet > lifecycle is init, service, destroy. To reconfigure, the container could > simply send a destroy followed by an init to effect reconfiguration." The > Servlet API demonstrates that we don't need more than that in the Mailet > API to support reloading. And if/when we do add things, I would adopt a > Listener interface approach, just as is done in the Servlet and Portlet > APIs. The events would be in the Mailet domain, not a container domain. > > A key design area is the Mailet container, which is currently a Processor. > We need to look at that, and decide whether we can merge Processor and > Mailet; if we need to (and can) have Processor extend Mailet; if we can use > some additional Listeners to allow dynamic reconfiguration of a Mailet; > etc., but I would not tie this into the Avalon lifecycle except with an > adapter. Nor would I require Mailets to register, anymore than Servlets or > Portlets have to register if they have declared listener interfaces. > > On a related note, as I believe I've mentioned I'd like to change the way > that RemoteDelivery works. Rather than have RemoteDelivery handle its own > queuing, I'd like to push that out a level so that any matcher/mailet can > benefit from that capability. For example, if a DNSRBL matcher failed, the > operation could be requeued. I would not mind putting that on my list, well I guess most stuff that concerns RemoteDelivery has my interest ;-) Do you have more detail of how you envision this requeing service? --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My Status, and James RoadMap
On Friday 18 June 2004 03:47, Noel J. Bergman wrote: > OK guys, James 2.2.0 is released. That's it from me for probably the next > week or so. I have something next week that I really must focus on. After > that, I'll get onto the branch merger. > > Conjectured Roadmap: > > Release James X (2.3, 3.0, don't care) based upon > the merged code with contemporary Avalon code. > > Start to add features. > > I have two immediate feature changes I want to make, post-merger. One is a > "hack" related to JavaMail that should dramatically improve footprint and > performance in two key locations in the code. Basically, I want to > convince JavaMail that the message content should be shared and streamed. > The second is in-process processor support for the SMTP handler. > > Comments/criticisms/concerns? Sounds great! My work list is as follows: - allowing RemoteDelivery to use SMTP-SSL (port 465) - support for STARTTLS in SMTPHandler - handling source routes by stripping them - RemoteDelivery uses HELO not EHLO, due to a bug in JavaMail back in 2001, so I believe it is time to revisit that. --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here comes the release ...
On Wednesday 16 June 2004 21:21, Serge Knystautas wrote: > Steve Brewin wrote: > > Anyway, before we dwell too much on the future, a big thanks to everyone > > who helped in getting this release out, especially Noel who has spent so > > much time painstakingly putting it all together. > > +1! Actually +1 is way to small a recognition for Noel's work, but as it is all we can offer here is mine as well. +1 --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here comes the release ...
On Tuesday 15 June 2004 15:19, Serge Knystautas wrote: > Danny Angus wrote: > > I think we'd need to poll our users explicitly first. > > There are still good reasons for not doing so unless we really *need* to. > > > > -1 (It is not a good indication) > > I know Danny is stuck with JDK 1.3. :) > > There's NIO, built in JNDI DNS library, TLS capabilities. What about > requiring 1.4 for james 3.0? +1 -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here comes the release ...
On Monday 14 June 2004 23:05, Noel J. Bergman wrote: > As you can probably tell, I just tweaked CVS to include the final release > versions of DBCP and Pool. The only change between what we have now and > what we used for testing is trivial removal (a few lines, which were > carefully vetted by hand) of some JDK 1.4 dependencies. It is interesting > to note that during our tests, no one complained. Not sure what to take > away from that fact, but we're avoiding the JDK 1.4 dependency. Could it be an indicator that we can move on to requiring 1.4, that would be nice. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Routing
After reading some more RFC-2821 (and a conversation with a co-worker of mine), we can only see that a 550 response is permitted for source routing in relation to RCPT TO commands. We get the source route in a MAIL FROM command. The specific sections (3.3 and 4.1.1.2) does not mention a 550 answer as a possibility there, instead they refer to appendix C which in turn refer to F.2. --Søren On Thursday 10 June 2004 10:43, Soren Hilmer wrote: > >> The backend system (apparently it must have a few years on it's back) > >> uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] > >> > >> Now James hickups at this issuing: > >> ERROR smtpserver: Error parsing sender address: > >> @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position > >> 1 > >> > >> So to be compliant James actually MUST accept this syntax ;-( > > > >Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which > > makes it quite clear that we are entitled to reject with a 550 the RCPT > > TO command that provided a source route. If you want to support it by > > stripping the source route information, that's fine, but I'm just as > > comfortable issuing the 550. > > Okay, see your point. I missed that paragraph in section 4.1.1.3. > Seen from my chair though one of the really great things about James (and > what we primarily use it for) is its mail-processing capabilities, so we > usually has it set up like a mail-processing router, between the internet > and an existing mailserver or other backend system. For this purpose it is > a better strategy to strip the routes (the fix is actually quite simple). > > I will do the fix and commit it. But now as 2.2.0 is getting released. What > is the procedure for comitting fixes? Is it better to hold of everything > till after the merger with MAIN? Maybe I should just go back and reread the > threads on this. I have sort of lost the overall picture of the merger > strategy. > > --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Routing
>> The backend system (apparently it must have a few years on it's back) >> uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] >> Now James hickups at this issuing: >> ERROR smtpserver: Error parsing sender address: >> @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 >> So to be compliant James actually MUST accept this syntax ;-( >Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which makes >it quite clear that we are entitled to reject with a 550 the RCPT TO command >that provided a source route. If you want to support it by stripping the >source route information, that's fine, but I'm just as comfortable issuing >the 550. Okay, see your point. I missed that paragraph in section 4.1.1.3. Seen from my chair though one of the really great things about James (and what we primarily use it for) is its mail-processing capabilities, so we usually has it set up like a mail-processing router, between the internet and an existing mailserver or other backend system. For this purpose it is a better strategy to strip the routes (the fix is actually quite simple). I will do the fix and commit it. But now as 2.2.0 is getting released. What is the procedure for comitting fixes? Is it better to hold of everything till after the merger with MAIN? Maybe I should just go back and reread the threads on this. I have sort of lost the overall picture of the merger strategy. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release James 2.2.0RC5 as James v2.2.0
+1 -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Source Routing
Hi, Okay we just ran into the following at a site, where James is setup as a mailprocessing gateway. The backend system (apparently it must have a few years on it's back) uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] ie. the old RFC-821 source route style. Now James hickups at this issuing: 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 ;-( I propose a fix, where we use the MAY above, that is ignore the routes and utilize only the target domain in the address. If you all agree with me that this is something we should (no must) handle, and in the proposed manner. I will start working on this fix. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery and new DSNBounce Mailet
Ignore the last mail!! For some reason my mail-client decided to resurrect some old mails and put them in the outboks ;-( --Søren On Friday 26 March 2004 11:29, Soren Hilmer wrote: > Hi Noel, > > Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons > why I have not committed it. > > i) It does not compile under 1.3 because: > a) Uses Java's regular expressions (have fixed that) > b) Uses InetAddress.getCanonicalHostName (I am still deciding on how > this is best handled, either close your eyes and use getHostName, or extend > and use our DNSServer). > > ii) It uses text/plain instead of message/delivery-status as Content-type > for the dsn message. This should be easy to resolve, given Steve Brewin's > code. > > > I then decided that splitting the commit up, so the bounceprocessing > feature was separately comitted to RemoteDelivery made sense, at least that > way developers have the hook they need to do custom bounceprocessing. > > > --Søren > > On Friday 26 March 2004 06:20, Noel J. Bergman wrote: > > Serge, Soren and Andreas, > > > > Soren just committed the change with Serge's modifications. Did we ever > > get the DSNBounce Mailet? > > > > Reviewing the change change, two things occur to me: > > > > 1 - there is a "bug" -- actually more of a limitation. > > Quoting RFC 3464: > > > > A DSN can be used to notify the sender of a > > message of any of several conditions: failed > > delivery, delayed delivery, successful delivery, > > or the gatewaying of a message into an environment > > that may not support DSNs. > > > > The patch handles only bounces and not other types > > of Delivery Status Notification types. > > > > 2 - It seems to me that the original DSN (as in Delivery Status > > Notification) seems more general than "Bounce." I would > > change delivery-error to delivery-status. The processor > > could be ... ?? Just to prepare > > for when we do support more than just error notices. > > > > I have not made any change for either. Would consider changing for #2, > > and would not want to touch #1 until post release, although if someone > > else has the time, please feel free to look into it. > > > > By the way, due to an error on my part (failing to do a cvs up before a > > build), this change did NOT make it into a16. It will be in a17. > > > > --- Noel > > > > -Original Message- > > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > > Sent: Thursday, November 27, 2003 22:21 > > To: James Developers List > > Subject: Re: [PATCH] RemoteDelivery and new DSNBounce Mailet > > > > > > Andreas, > > > > Two things... > > 1. You only attached the RemoteDelivery patch, not the DSNBounce mailet. > > 2. The change to remote delivery... other people have requested handling > > how bounces work, so I might suggest we make this more generic. > > Basically the code would stay the same, just remove the DSN-specific > > naming, e.g., configure a and store the exception as > > the delivery-error. > > > > -- > > Serge Knystautas > > President > > Lokitech >>> software . strategy . design >> http://www.lokitech.com > > p. 301.656.5501 > > e. [EMAIL PROTECTED] > > > > Andreas Göggerle wrote: > > > Hi, > > > > > > finaly I got time to get things ready. > > > > > > This Patch to RemoteDelivery introduces a new parameter . > > > Here you can specify a processor, where DSN conform Bounces are > > > created. If this parameter is missing, mails get bounced the "old way". > > > > > > Here is a configuration example: > > > > > > > > > [...] > > > > > >[...] > > > > > > dsn > > > > > > > > > > > > > > > > > > > > >[EMAIL PROTECTED] > > > > > >ERROR: > > >false > > > > > > > > > > > > The DSNBounce Mailet creates Bounce Mails in the format specified by > > > RFCs 3462 > > > to 3464. There is only one discrepancy: the MIME-type "text/plain" is > > > used for > > > the status-report part, instead of "message/delivery-status". > > > JavaMail doesn't support "message/delivery-status". > > > > - > > 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] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-265 and the pending Release
+1 to add the fix.
On Wednesday 21 April 2004 06:29, Noel J. Bergman wrote:
> Folks,
>
> If you have been following the discussion on server-user@, you will have
> noticed a lengthy discussion between Marc De Oliviera and myself that
> resulted in a one line (two, if you count the avoidable import :-)) change
> to DNSServer.java.
>
> +import org.xbill.DNS.Lookup;
> @@ -148,6 +149,7 @@
>try {
>resolver = new ExtendedResolver( serversArray );
> +Lookup.setDefaultResolver(resolver);
>} catch (UnknownHostException uhe) {
>
> The change sets the default resolver for dnsjava. Without it, dnsjava
> makes a best guess regarding how to resolve DNS information, and ignores
> the configured servers when using the high level API, e.g.,
> Address.get[All]ByName(). With it, we force dnsjava to always use the
> servers configured for James.
>
> Considering that Marc could not use RC1 because of this issue, I'd like to
> see 2.2.0 ship with this fix. I'm sure that his is not the only system for
> which dnsjava won't be able to autodetect the DNS servers.
>
> --- Noel
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax:+45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MxSorter and changes to DNSServer.java
On Tuesday 13 April 2004 03:49, Noel J. Bergman wrote: > > I haven't looked at the org.xbill.DNS.Address but it > > sounds like a good solution. > > Agreed. I'll look at making that change. > > > I have put it on my todo-list to go through the code and > > weed-out InetAddress, just haven't gotten around to it yet. > > I just did: > > $ grep --recursive "InetAddress\.get.*ByName" src/java/ -l > src/java/org/apache/james/James.java > src/java/org/apache/james/core/AbstractJamesService.java > src/java/org/apache/james/dnsserver/DNSServer.java > src/java/org/apache/james/fetchmail/MessageProcessor.java > > src/java/org/apache/james/transport/mailets/RemoteDeliverySocketFactory.jav >a src/java/org/apache/james/transport/mailets/RemoteDelivery.java > src/java/org/apache/james/transport/matchers/InSpammerBlacklist.java > src/java/org/apache/james/util/NetMatcher.java > > James, AbstractJamesService, and RemoteDeliverySocketFactory were all local > stuff. > > I've updated DNSServer, MessageProcessor, RemoteDelivery, > InSpammerBlacklist, and NetMatcher it use org.xbill.DNS.Address for the two > static methods. I fully qualified the name to (a) make it easier to find, > and (b) because it was necessary in some cases to distinguish from > javax.mail.Address, anyway. Of course, I just realized that like an idiot, > I just committed the changes before testing them. :-( I'll be doing that > immediately. Sounds great, (except for the non-testing part ;-)) > > Another side-effect of the changes since yours and Richard's is that by > passing an IP address to JavaMail, we eliminate its lookup, which would > also have used InetAddress' caching. Yes, I was aware of that "sideeffect". > > I find it bothersome that Sun's DNS service for JNDI apparently ignores the > TTL provided by the DNS server. Agreed, the Sun is absolutely NOT geared towards a mail-server solution, and their reason for the "cache-forever" srategy (that it is made to prevent spoofing attacks) is IMO a bit farfetched, the very least they could have done was to provide a hook to circumvent it. But as it is we are not too pleased with their JavaMail implementation either ;-) --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MxSorter and changes to DNSServer.java
On Friday 09 April 2004 17:12, Noel J. Bergman wrote:
> > My concern on this is that InetAddress caches successfull DNS
> > lookups forever (at least on default) and this strategy is not
> > very sound for a mailserver
>
> Good point, Søren. And that happens in InetAddress, but through
> contamination with sun.* classes. It isn't pluggable. The is a comment in
> the code that suggests that the author realizes it is a problem. Even
> replacing the default DNS provider with dnsjava (using
> sun.net.spi.nameservice.provider), would not help.
>
> However, since the use of InetAddress within DNSServer is opaque, we could
> trivially switch to using org.xbill.DNS.Address, which is a InetAddress
> clone that uses dnsjava. How does that sound?
>
I haven't looked at the org.xbill.DNS.Address but it sounds like a good
solution.
> I haven't checked the rest of the code, but InSpammerBlacklist also has
> this problem. That should probably be changed to use dnsjava, and perhaps
> JNDI in the future (portable, but more overhead). That would also allow us
> to get the TXT record, which some DNS RBLs use to provide useful
> information, e.g.,
>
> attrs = dnsContext.getAttributes(rblString, new String[] {"A", "TXT"});
>
> in JNDI-speak.
>
Yes, Noel I was aware that other places of the code might malfunction because
of this, and I have put it on my todo-list to go through the code and
weed-out InetAddress, just haven't gotten around to it yet.
-- Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax:+45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MxSorter and changes to DNSServer.java
Hi Noel, My concern on this is that InetAddress caches successfull DNS lookups forever (at least on default) and this strategy is not very sound for a mailserver, as I happened to discover :-( A possible (not optimal) solution is to set the security property networkaddress.cache.ttl to something less than the maximum retry-time for an undelivered mail, somewhere in James (RemoteDelivery ?). --Soren On Wednesday 07 April 2004 21:18, Noel J. Bergman wrote: > I have modified getSMTPHostAddresses to call findMXRecords and then use the > Iterator from that collection. We could go back to using MxSorter (the > comment I just put in about being able to us MxSorter within findMXRecords > is wrong, since we don't ever see a Collection over which to iterate; we > get an iterator), if we make some changes to it. > > 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. 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. > > Comments? Any strong feelings either way about using MxSorter to sort on > the fly versus pre-sorting, which is what findMXRecords does? If people > want to use MxSorter, the fixes should be fairly straightforward. The > drawback is having two sections of code doing largely the same thing, but > if we end up deprecating findMXRecords, that issue goes away. > > I am not sure if MxSorter is faster unless there would be a lot of records. > Even if you are using the first record, we have already got the records, > and sorting a small Collection in place is quick. MxSorter makes a linear > pass through the entire Collection, engages in object creation (at the > least, it has to call toString()) for each host matching the then > leastPriorityFound, and may create and delete entries from its working > collection depending upon the order in which they are present from the > lookup call. At least that's my take on the code. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery and new DSNBounce Mailet
Hi Noel, Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons why I have not committed it. i) It does not compile under 1.3 because: a) Uses Java's regular expressions (have fixed that) b) Uses InetAddress.getCanonicalHostName (I am still deciding on how this is best handled, either close your eyes and use getHostName, or extend and use our DNSServer). ii) It uses text/plain instead of message/delivery-status as Content-type for the dsn message. This should be easy to resolve, given Steve Brewin's code. I then decided that splitting the commit up, so the bounceprocessing feature was separately comitted to RemoteDelivery made sense, at least that way developers have the hook they need to do custom bounceprocessing. --Søren On Friday 26 March 2004 06:20, Noel J. Bergman wrote: > Serge, Soren and Andreas, > > Soren just committed the change with Serge's modifications. Did we ever > get the DSNBounce Mailet? > > Reviewing the change change, two things occur to me: > > 1 - there is a "bug" -- actually more of a limitation. > Quoting RFC 3464: > > A DSN can be used to notify the sender of a > message of any of several conditions: failed > delivery, delayed delivery, successful delivery, > or the gatewaying of a message into an environment > that may not support DSNs. > > The patch handles only bounces and not other types > of Delivery Status Notification types. > > 2 - It seems to me that the original DSN (as in Delivery Status > Notification) seems more general than "Bounce." I would > change delivery-error to delivery-status. The processor > could be ... ?? Just to prepare > for when we do support more than just error notices. > > I have not made any change for either. Would consider changing for #2, and > would not want to touch #1 until post release, although if someone else has > the time, please feel free to look into it. > > By the way, due to an error on my part (failing to do a cvs up before a > build), this change did NOT make it into a16. It will be in a17. > > --- Noel > > -Original Message- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 27, 2003 22:21 > To: James Developers List > Subject: Re: [PATCH] RemoteDelivery and new DSNBounce Mailet > > > Andreas, > > Two things... > 1. You only attached the RemoteDelivery patch, not the DSNBounce mailet. > 2. The change to remote delivery... other people have requested handling > how bounces work, so I might suggest we make this more generic. > Basically the code would stay the same, just remove the DSN-specific > naming, e.g., configure a and store the exception as > the delivery-error. > > -- > Serge Knystautas > President > Lokitech >>> software . strategy . design >> http://www.lokitech.com > p. 301.656.5501 > e. [EMAIL PROTECTED] > > Andreas Göggerle wrote: > > Hi, > > > > finaly I got time to get things ready. > > > > This Patch to RemoteDelivery introduces a new parameter . > > Here you can specify a processor, where DSN conform Bounces are created. > > If this parameter is missing, mails get bounced the "old way". > > > > Here is a configuration example: > > > > > > [...] > > > >[...] > > > > dsn > > > > > > > > > > > > > >[EMAIL PROTECTED] > > > >ERROR: > >false > > > > > > > > The DSNBounce Mailet creates Bounce Mails in the format specified by RFCs > > 3462 > > to 3464. There is only one discrepancy: the MIME-type "text/plain" is > > used for > > the status-report part, instead of "message/delivery-status". > > JavaMail doesn't support "message/delivery-status". > > - > 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] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: prepare-mxinfo warning
Well, define normal ;-) No, it is caused by the * import of org.apache.avalon.framework.component in James.java. I have committed the necessary change on branch_2_1_fcs, do you still favor a parallel commit on MAIN? --Søren On Saturday 20 March 2004 05:22, Noel J. Bergman wrote: > Is this normal? > > --- Noel > > prepare-mxinfo: > Running > WARNING: Some classes refer to other classes that were not found among the > sources or on the classpath. > (Perhaps the referred class doesn't exist? Hasn't been generated > yet?) > The referring classes do not import any fully qualified classes > matching these classes. > Since at least one package is imported, it is impossible for > xjavadoc to figure out > what package the referred classes belong to. The classes are: > org.apache.james.James --> Composable qualified to Composable > org.apache.james.James --> Component qualified to Component > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge Status
Hi Noel, Just as you know. I have not committed DSNBounce and its accompanying changes to RemoteDelivery. Because you are currently refactoring RemoteDelievery, I have decided to wait until after the merger, hope that is okay. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMS mailet
Probably the best answer is to look at the RemoteDelivery mailet. Basically what it does is to move the mail to another MailRepository and then on intervals check if any mails in that repository are ready for a transmission retry. --Søren On Wednesday 25 February 2004 13:14, astrograph wrote: > hi, > > I´ve written a mailet which sends emails to a JMS queue. Sometimes I get > an error (JMSException), in this case I want James to retry sending the > JMS, i.e. processing the email again with this mailet... > > how can I configure the mailets, so an e-mail which was not GHOSTED will > again be processed? > > tia > > phil > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1999
FYI I have gone through all the original (1.1 versions) and for those java files comittet in 1999 (no one is earlier) and are still in the repository (though not necesarily in the same package) I have changed the copyright notice from 2000-2004 to 1999-2004. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: james-server/tools/lib LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar
Hi, Yes, I plan to commit it for MAIN as well, hopefully today. --Søren On Thursday 19 February 2004 00:24, Steve Brewin wrote: > Hi Soren and Noel, > > These updates look great. The only worry I have is that in order to help > Noel with the task of merging the MAIN (3.0) and branch_2_1_fcs sources I > had recently synchronized the two fetchmail code paths. Now they are out of > sync. again as you have applied the JMX changes to branch_2_1_fcs only. > > Nothing wrong with that, but fetchmail cannot be resynced in MAIN without > adding to MAIN many of the changes committed to branch_2_1_fcs by this > commit. > > Is the intention to also commit the JMX changes to MAIN? If not, can we > agree that for the merge branch_2_1_fcs is the definitive source for > fetchmail and we will ignore MAIN? > > I would guess the same issues touch other areas too? > > -- Steve > > > > - > 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]
Re: CVS problems
Thanks Steve How stupid can one get, totally forgot that I reinstalled a standard JDK 1.3.1, so i lost the jar, and got totally confused as the compilation started to fail. --Søren On Wednesday 18 February 2004 18:46, Steve Brewin wrote: > Soren > > For branch_2_1_fcs I see revision 1.1.2.2 of > src/java/org/apache/james/util/dbcp/JdbcDataSource.java, timestamped > 24/07/03 02:45. I believe this is the correct version and compiles fine > with JDK 1.3.1. > > Sure you have jdbc2_0-stdext.jar in your classpath? > > -- Steve > > > - > 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]
CVS problems
Hi, I just did an update on my branch_2_1_fcs checkout and suddenly I got the file ../util/dbcp/JdbcDataSource which belongs to MAIN, and cannot compile using JDK 1.3 so I completely removed my checkout and did a new one, but the file in question keeps coming back. The CVS/Entries in dbcp reports: /JdbcDataSource.java/1.1.2.2/Thu Jul 24 01:45:58 2003//Tbranch_2_1_fcs so apparently it belongs to this branch, although looking at: http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/util/ dbcp/?only_with_tag=branch_2_1_fcs says this is empty. Any suggestions what is happening Søren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autogeneration or handcoding?
> I don't know of any reason not to use a tool, but we should make sure of > Avalon's plans. Hopefully they are maintaining compatibility as they add > JMX into Merlin. I looked at http://avalon.apache.org/merlin, the Avalon > Wiki, and the mailing lists, but couldn't find anything other than some > e-mails back in September, so I am cc'ing Stephen to make sure we get a > response. Fine, I will wait for his response. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autogeneration or handcoding?
On Sunday 15 February 2004 00:14, Noel J. Bergman wrote:
> > I am just getting ready to commit Steve Shorts JMX extensions.
>
> To where? MAIN?
Well both MAIN and branch_2_1_fcs, is that not what you prefer?
or would you rather have that I wait until the merger has finished?
>
> > The patch removes the need to handcode the .mxinfo files by using the
>
> Phoenix
>
> > supplied doclet
> >
> > However for this to work we need to commit four additional .jar files
>
> (Steve
>
> > places them in tools/lib which makes sense)
>
> Is this a build time process? I am possibly OK with the doclet approach
> (can you provide an example?) if it is strictly a build time issue.
>
It is strictly a build-time issue. You place tag in the MBean interface like
this for the DNSServerMBean:
/**
* An interface to expose James management functionality through JMX.
*
* @phoenix:mx-topic name="DNSServer"
*/
public interface DNSServerMBean {
...
Then the .mxinfo files are autogenerated during the build process and put in
the james.jar.
The same thing is possible for .xinfo files and it is documented (rather well
actually) at the phoenix site.
I thought that this was not used because we for some reason did not want to
introduce more tools or something.
--Søren
> --- Noel
>
>
> -
> 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]
Autogeneration or handcoding?
Hi all, I am just getting ready to commit Steve Shorts JMX extensions. There is a little issue with it I like to get second opinions on. The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet which handles this automagically from Javadoc tags in the code. However for this to work we need to commit four additional .jar files (Steve places them in tools/lib which makes sense), the question is, do we want this or do we want handcoded mxinfo files. I suspect we want the handcoded ones as we also use handcoded .xinfo files, which could also have been autogenerated. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JamesConnectionManager (JAMES-151)
Sure Noel, I will do that. --Soren On Friday 13 February 2004 21:50, Noel J. Bergman wrote: > > Resolved bug. By extending the ConnectionManager interface. And > > using that extension in assembly.xml and .xinfo files > > Although we can do this during the merger, you might as well commit this to > the MAIN branch. :-) > > --- Noel > > > - > 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]
Re: [jira] Closed: (JAMES-151) connectionLimit on services ignored
No, I am afraid not, this is purely a configuration issue. We have the possibility to specify connectionLimit on a per service basis as well as for all services. The per service setting had no effect, though the global one was fine. --Soren On Friday 13 February 2004 17:11, Serge Knystautas wrote: > Does this relate to Michael Nestler's email bug report this morning? He > reported it against James 2.1.3, not 2.2.0a15. We might need to create > more versions for what we have released in the wild. Also, you have to > reopen an issue to change an issue (such as the affects version). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S/MIME (was [PROPOSAL] Release Plan)
Ahh, that makes sense then, ofcourse you could change the From header. Now, a client replying to the mail will probably do it to the trusted-server (unless you modify the reply-to header) but that is really often what you want, because otherwise the client cannot find the right certificate and thus not make an encrypted reply. Now the final issue is how to forward the mail to the right recipient from the server, which is a bit of a challenge ;-) --Søren On Thursday 12 February 2004 13:02, Vincenzo Gianferrari Pini wrote: > > > > Vincenzo: S/MIME code? > > > > > > This mailet (server side signing) is properly working, and just needs > > > to be javadoc enhanced and some ho-to documentation. But as I found a > > > problem with Outlook Express > > > > > > > > > because it considers as a tampering the fact of > > > having the signature not coming from the sender, > > > > > > Which it actually should according to the S/MIME standard (RFC-2632): > > > >Sending agents SHOULD make the address in the From or Sender header > >in a mail message match an Internet mail address in the signer's > >certificate. Receiving agents MUST check that the address in the From > >or Sender header of a mail message matches an Internet mail address > >in the signer's certificate, if mail addresses are present in the > >certificate. A receiving agent SHOULD provide some explicit alternate > >processing of the message if this comparison fails, which may be to > >display a message that shows the recipient the addresses in the > >certificate or other certificate details. > > I wasn't precise: > > a) the unsigned message comes with a > From: [EMAIL PROTECTED] > header; > > b) the mailet adds a > Sender: "Trusted Server" <[EMAIL PROTECTED]> > header and > > c) the mailet signs as > [EMAIL PROTECTED] > > Obviously it is all parameterized. > > This was done on purpose to comply with RFC-2632 (the Sender header is the > same as the Internet mail address in the signer's certificate), but Outlook > Express ignores the Sender header and checks only the From header. > > Vincenzo > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S/MIME (was [PROPOSAL] Release Plan)
> > > > Vincenzo: S/MIME code? > > This mailet (server side signing) is properly working, and just needs to be > javadoc enhanced and some ho-to documentation. But as I found a problem > with Outlook Express > because it considers as a tampering the fact of > having the signature not coming from the sender, Which it actually should according to the S/MIME standard (RFC-2632): Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.3 or 2.2.0a15???
Hi, Personally I would choose 2.2.0a15. It is not less stable than 2.1, as a lot of bug-fixes have been applied. So in short you get the best of two worlds more stability and more features, ain't life great. --Søren On Wednesday 11 February 2004 09:29, Philipp Salzgeber wrote: > Hi! > > I am starting on a project where James will be used as a smtp server. I > am going to write a mailet which sends all incoming msgs to a > SessionBean in an EJB Container. > > I am wondering if I should use the productive version 2.1 or if the > advantages of the 2.2.0a15 outweigh the non-stable status of the code? > > with best regards > > Philipp > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
