Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.0
    • Component/s: FetchMail
    • Labels:
      None

      Description

      Added new FetchMail service. Enhanced and backported from the MAIN branch by Steve Brewin.

        Activity

        Hide
        Serge Knystautas added a comment -

        Committed 8/30/2003, included in 2.2.0a10.

        Show
        Serge Knystautas added a comment - Committed 8/30/2003, included in 2.2.0a10.
        Hide
        Serge Knystautas added a comment -

        Added directory for sample configurations, and started with sample fetchmail configurations. Committed 9/21/2003, included in 2.2.0a11.

        Show
        Serge Knystautas added a comment - Added directory for sample configurations, and started with sample fetchmail configurations. Committed 9/21/2003, included in 2.2.0a11.
        Hide
        Serge Knystautas added a comment -

        FetchMail update from Steve Brewin

        1) Documentation and Samples

        • xdocs
        • now include fetchmail_configuration_2_2.xml
        • documentation_2_1.xml updated to include the above
        • fetchpop_configuration_2_1.xml includes text indicating it is deprecated and fetchmail is prefered
        • conf
        • now has a sub-directory 'samples' that has a sub-directory 'fetchmail' containing the samples described in the xdocs

        2) Added features. - When the intended recipient cannot be determined by an Account processing can optionally be deferred to the next pass, giving other Accounts within the fetch task the oppurtunity to resolve the recipient.

        3) Improved features. - DynamicAccounts are now preserved between passes, enabling communication of state and variables such as the List of deferred messages required by the defer processing described above.

        4) Sundry refactorings and tidying up. The major refactoring is that Account objects replace ParsedConfiguration as primary source of the context for fetchmail delegate classes.

        5) Within the docs and config have highlighted the fact that the POP3 protocol does not mandate the SEEN flag, therefore the markSeen attribute may not stick when fetching from a POP3 server. Have also refactored the code to include handler methods for when JavaMail considers the server to have a non-permanent SEEN flag. The default handlers behave as normal when a non-permanent flag is tested and log warnings when a non-permanent flag is set, subclasses may choose to extend this behaviour, maybe to add SEEN support when the server doesn't have it?

        Committed 9/21-22/2003 by Noel, included in 2.2.0a11.

        Show
        Serge Knystautas added a comment - FetchMail update from Steve Brewin 1) Documentation and Samples xdocs now include fetchmail_configuration_2_2.xml documentation_2_1.xml updated to include the above fetchpop_configuration_2_1.xml includes text indicating it is deprecated and fetchmail is prefered conf now has a sub-directory 'samples' that has a sub-directory 'fetchmail' containing the samples described in the xdocs 2) Added features. - When the intended recipient cannot be determined by an Account processing can optionally be deferred to the next pass, giving other Accounts within the fetch task the oppurtunity to resolve the recipient. 3) Improved features. - DynamicAccounts are now preserved between passes, enabling communication of state and variables such as the List of deferred messages required by the defer processing described above. 4) Sundry refactorings and tidying up. The major refactoring is that Account objects replace ParsedConfiguration as primary source of the context for fetchmail delegate classes. 5) Within the docs and config have highlighted the fact that the POP3 protocol does not mandate the SEEN flag, therefore the markSeen attribute may not stick when fetching from a POP3 server. Have also refactored the code to include handler methods for when JavaMail considers the server to have a non-permanent SEEN flag. The default handlers behave as normal when a non-permanent flag is tested and log warnings when a non-permanent flag is set, subclasses may choose to extend this behaviour, maybe to add SEEN support when the server doesn't have it? Committed 9/21-22/2003 by Noel, included in 2.2.0a11.
        Hide
        Serge Knystautas added a comment -

        Each fetch task now has its own JavaMail Session enabling each fetch task to have its own set of configuration properties. Previously all fetch tasks shared the default Session instance and the same configuration properties.

        Configuration properties can now be set for each fetch task using the optional configuration tag <javaMailProperties> and any number of its child tag <property name="x" value="y">. The following example has been added to the default fetchmail configuration...

        <!-- Properties to be applied to the JavaMail Session. -->
        <!-- Properties are specific to the selected JavaMail provider. -->
        <!-- Any number may be specified. -->
        <javaMailProperties>
        <!-- Set the connection timeout to 3 minutes -->
        <property name="mail.pop3.connectiontimeout" value="180000"/>
        <!-- Set the I/O timeout to 3 minutes -->
        <property name="mail.pop3.timeout" value="180000"/>
        </javaMailProperties>

        Submitted by: Steve Brewin, Committed 9/23/2003 by Noel, included is 2.2.0a11.

        Show
        Serge Knystautas added a comment - Each fetch task now has its own JavaMail Session enabling each fetch task to have its own set of configuration properties. Previously all fetch tasks shared the default Session instance and the same configuration properties. Configuration properties can now be set for each fetch task using the optional configuration tag <javaMailProperties> and any number of its child tag <property name="x" value="y">. The following example has been added to the default fetchmail configuration... <!-- Properties to be applied to the JavaMail Session. --> <!-- Properties are specific to the selected JavaMail provider. --> <!-- Any number may be specified. --> <javaMailProperties> <!-- Set the connection timeout to 3 minutes --> <property name="mail.pop3.connectiontimeout" value="180000"/> <!-- Set the I/O timeout to 3 minutes --> <property name="mail.pop3.timeout" value="180000"/> </javaMailProperties> Submitted by: Steve Brewin, Committed 9/23/2003 by Noel, included is 2.2.0a11.
        Hide
        Serge Knystautas added a comment -

        1) The MailImpl instance sent to James now includes the remote address and remote host of the n'th relay in the delivery chain as reported by the 'from' field of the 'RECEIVED' headers. This is equivalent to the remote address and remote host set in the MailImpl by the SMTPHandler deduced from the socket of the connected server.

        The n'th relay is specified by the new fetchmail configuration parameter 'remoteReceivedHeaderIndex'. This is explained in the configuration file and updated xdoc.

        The InSpammerBlackList matcher validates against the remote address in the MailImpl. Prior to this patch it was having no effect and all mail was considered valid.

        2) Made logging at the INFO level less verbose and logging at the DEBUG level more detailed.

        Submitted by: Steve Brewin. Committed 10/19/2003 by Noel, included in 2.2.0a14.

        Show
        Serge Knystautas added a comment - 1) The MailImpl instance sent to James now includes the remote address and remote host of the n'th relay in the delivery chain as reported by the 'from' field of the 'RECEIVED' headers. This is equivalent to the remote address and remote host set in the MailImpl by the SMTPHandler deduced from the socket of the connected server. The n'th relay is specified by the new fetchmail configuration parameter 'remoteReceivedHeaderIndex'. This is explained in the configuration file and updated xdoc. The InSpammerBlackList matcher validates against the remote address in the MailImpl. Prior to this patch it was having no effect and all mail was considered valid. 2) Made logging at the INFO level less verbose and logging at the DEBUG level more detailed. Submitted by: Steve Brewin. Committed 10/19/2003 by Noel, included in 2.2.0a14.

          People

          • Assignee:
            Unassigned
            Reporter:
            Serge Knystautas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development