Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0
    • Component/s: None
    • Labels:
      None

      Description

      I add a new configuration option to RCPTCmdHandler to limit the RCPT that are set per Mail. This can be usefull for Admins that want to set a limit for RCPTs.
      The RCPT count get reseted if the DATACmdHandler get called.

      Here it is..

      1. DataCmdHandler-maxrcpt.patch
        1 kB
        Norman Maurer
      2. james-config.xml-maxrcpt.patch
        1 kB
        Norman Maurer
      3. maxRcpt-rfc-fix.patch
        1 kB
        Norman Maurer
      4. maxrcpt-rfc-junit-fix.patch
        0.8 kB
        Norman Maurer
      5. RcptCmdHandler-maxrcpt.patch
        5 kB
        Norman Maurer
      6. SMTPServerTest-maxrcpt.patch
        3 kB
        Norman Maurer
      7. SMTPTestConfiguration-maxrcpt.patch
        2 kB
        Norman Maurer

        Activity

        Hide
        norman Norman Maurer added a comment -

        Patch for DATACmdHandler to reset RCPT Count

        Show
        norman Norman Maurer added a comment - Patch for DATACmdHandler to reset RCPT Count
        Hide
        norman Norman Maurer added a comment -

        Patch of config.xml to reflect the new feature

        Show
        norman Norman Maurer added a comment - Patch of config.xml to reflect the new feature
        Hide
        norman Norman Maurer added a comment -

        Patch for RCPTCmdHandler to add the new feature

        Show
        norman Norman Maurer added a comment - Patch for RCPTCmdHandler to add the new feature
        Hide
        norman Norman Maurer added a comment -

        JUnit Tests

        Show
        norman Norman Maurer added a comment - JUnit Tests
        Hide
        norman Norman Maurer added a comment -

        Junit Config

        Show
        norman Norman Maurer added a comment - Junit Config
        Hide
        norman Norman Maurer added a comment -

        Feature Complete.

        Show
        norman Norman Maurer added a comment - Feature Complete.
        Hide
        bago Stefano Bagnara added a comment -

        Applied the patch.

        I have removed the DataCmdHandler code change (session state reset) because the whole session state is restarted when a mail is sent (See SMTPSessionHandler).

        Hint to Norman: you can even create a single patch file for all the files changed if you select them all when you create the patch.

        Thank you for the new feature!

        Show
        bago Stefano Bagnara added a comment - Applied the patch. I have removed the DataCmdHandler code change (session state reset) because the whole session state is restarted when a mail is sent (See SMTPSessionHandler). Hint to Norman: you can even create a single patch file for all the files changed if you select them all when you create the patch. Thank you for the new feature!
        Hide
        sshort Steve Short added a comment -

        This patch returns the wrong status code when the recipient limit is reached. It currently returns 571 but it should return 452. See RFC 2821 section 4.5.3.1. Here's the relevant phrase:

        "If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452..."

        Show
        sshort Steve Short added a comment - This patch returns the wrong status code when the recipient limit is reached. It currently returns 571 but it should return 452. See RFC 2821 section 4.5.3.1. Here's the relevant phrase: "If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452..."
        Hide
        sshort Steve Short added a comment -

        I forgot to add this status should prevent the addition of further recipients but should not invalidate the mail, the client must be able to complete and send the mail for the recipients that have already been accepted.

        Show
        sshort Steve Short added a comment - I forgot to add this status should prevent the addition of further recipients but should not invalidate the mail, the client must be able to complete and send the mail for the recipients that have already been accepted.
        Hide
        bago Stefano Bagnara added a comment -

        Norman, please let us know if you're going to update the unittests and fix this, otherwise I'll do that in the weekend.

        Show
        bago Stefano Bagnara added a comment - Norman, please let us know if you're going to update the unittests and fix this, otherwise I'll do that in the weekend.
        Hide
        norman Norman Maurer added a comment -

        I will fix it soon..

        Show
        norman Norman Maurer added a comment - I will fix it soon..
        Hide
        norman Norman Maurer added a comment -

        After have a quick review of some patches for qmail and reading a bit more docs it can also use a 571 code and reject the message if to many recipients are used. Maybe we should make it configurable ?

        Show
        norman Norman Maurer added a comment - After have a quick review of some patches for qmail and reading a bit more docs it can also use a 571 code and reject the message if to many recipients are used. Maybe we should make it configurable ?
        Hide
        bago Stefano Bagnara added a comment -

        Is this alternative described in an RFC ?
        If not we should follow the standard behaviour (452 and accept remaining recipients)

        From my "status codes knowledge" I believe that a 571 code sent in reply to an RCPT TO will make the client think the recipient address is permanently invalid and that you will not be able to send any other message to the same recipient and this is not the intended behaviour.

        Show
        bago Stefano Bagnara added a comment - Is this alternative described in an RFC ? If not we should follow the standard behaviour (452 and accept remaining recipients) From my "status codes knowledge" I believe that a 571 code sent in reply to an RCPT TO will make the client think the recipient address is permanently invalid and that you will not be able to send any other message to the same recipient and this is not the intended behaviour.
        Hide
        norman Norman Maurer added a comment -

        can someone confirm that we should send a bounce with the not accepted recipients to the sender ? or should the msg just not send to these ? i think we must make a bounce that contains the rcpts that are not accepted

        qmail patches are use a 571 code and reject the whole message. that make more sense for me but it seems not to be valid.

        Show
        norman Norman Maurer added a comment - can someone confirm that we should send a bounce with the not accepted recipients to the sender ? or should the msg just not send to these ? i think we must make a bounce that contains the rcpts that are not accepted qmail patches are use a 571 code and reject the whole message. that make more sense for me but it seems not to be valid.
        Hide
        bago Stefano Bagnara added a comment -

        No bounces. The 452 in response to the RCPT TO already provide enough information to the client. The client will decide wether to send the message to the partial rcpt list or close the connection.

        Javamail SMTPTransport, for example, has a parameter "sendPartial" that manage this scenario: you can decide what to do when you find invalid recipients while sending a new message.

        If we implement the standard behaviour then the client will have the power to decide what to do.

        Show
        bago Stefano Bagnara added a comment - No bounces. The 452 in response to the RCPT TO already provide enough information to the client. The client will decide wether to send the message to the partial rcpt list or close the connection. Javamail SMTPTransport, for example, has a parameter "sendPartial" that manage this scenario: you can decide what to do when you find invalid recipients while sending a new message. If we implement the standard behaviour then the client will have the power to decide what to do.
        Hide
        norman Norman Maurer added a comment -

        Patch for return the right status code like descripted in rfc.

        Show
        norman Norman Maurer added a comment - Patch for return the right status code like descripted in rfc.
        Hide
        norman Norman Maurer added a comment -

        Fix junit test

        Show
        norman Norman Maurer added a comment - Fix junit test
        Hide
        bago Stefano Bagnara added a comment -

        I already applied the last patch to unittest while testing.

        Show
        bago Stefano Bagnara added a comment - I already applied the last patch to unittest while testing.
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            norman Norman Maurer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development