Hi Ralph,

we would be glad to see your fixes and patch james source ;)

Bye,
Norman

2010/1/1 Ralph B Holland <[email protected]>:
> Norman,
>
> No problems - just helping out so I can use James to source email from all my 
> email accounts, including webmail by using FreePOPs.
> I can say that I have learned heaps in the last 5 days I have been doing this 
> - thanks for the neat project.
>
> I am currently working on the trace Received: header parsing at the moment, 
> having fixed the bug that caused invalid remote domains from crashing 
> createMail(). My version of fetchmail now permits subsequent processing to 
> reject the invalid header if so configured, or allows the email to be further 
> processed if not rejected.
>
> I haven't released this fix yet because I also changed the Received: from 
> parsing and am in the process of testing it.
>
> My ISP uses the Mail-SeCure device, which has a slightly different trace 
> header to other email servers. Since this is a commercial device I think we 
> could argue that its trace is relevant to the wider community despite other 
> interpretations of the RFC.
>
> Perhaps I should release these changes as two patches, one for the exception 
> handling, and the other for the parsing.
>
> Regards,
>
> Ralph
>
> -----Original Message-----
> From: Norman Maurer (JIRA) [mailto:[email protected]]
> Sent: Saturday, 2 January 2010 00:24
> To: [email protected]
> Subject: [jira] Resolved: (JAMES-942) James FetchMail instances are sharing 
> the same Properties class instance preventing correct setting of 
> mail.pop3.port etc
>
>
>     [ 
> https://issues.apache.org/jira/browse/JAMES-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Norman Maurer resolved JAMES-942.
> ---------------------------------
>
>       Resolution: Fixed
>    Fix Version/s: 3.0-M1
>                   3.0
>
> Fixed.. Thx for the patch!
>
>> James FetchMail instances are sharing the same Properties class instance 
>> preventing correct setting of mail.pop3.port etc
>> -------------------------------------------------------------------------------------------------------------------------
>>
>>                 Key: JAMES-942
>>                 URL: https://issues.apache.org/jira/browse/JAMES-942
>>             Project: JAMES Server
>>          Issue Type: Bug
>>          Components: Deployment Modules
>>    Affects Versions: 2.3.2
>>         Environment: Bug is in FetchMail.java
>>            Reporter: Ralph Holland
>>            Assignee: Norman Maurer
>>             Fix For: 2.4, 3.0, 3.0-M1
>>
>>
>> James-fetchmail.xml permits you to set the mail API properies via the 
>> JavaMailProperties element e.g:
>>                   <javaMailProperties>
>>                       <property name="mail.pop3.connectiontimeout" 
>> value="0"/>
>>                       <property name="mail.pop3.timeout" value="0"/>
>>                       <property name="mail.pop3.port" value="2000"/>
>>                   </javaMailProperties>
>> However, the FetchMail class passes a reference to the 
>> Systems.getProperties() class into the Service that interacts with the 
>> MailAPI, this means that multiple instances of the FetchMail class are 
>> actually sharing the same Properties class and prevents different values 
>> from being set, e.g. the mail.pop3.port.
>> A simple fix for this bug is to change FetchMail.computeSession() so a new 
>> instance of a PropertiesClass is passed in to create the session instance, 
>> using the System Properties as a default, as per the example below:
>>     /**
>>      * Answers a new Session.
>>      * @return Session
>>      */
>>     protected Session computeSession()
>>     {
>>        // Make separate properties instance so the
>>        // fetchmail.xml <javaMailProperties> can override the
>>         // property values without interfering with other fetchmail instances
>>        return Session.getInstance( new Properties( System.getProperties()) );
>>     }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.725 / Virus Database: 270.14.123/2595 - Release Date: 12/31/09 
> 19:52:00
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to