[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373819 ]
Stefano Bagnara commented on JAMES-468:
---
No bounces. The 452 in response to the RCPT TO already provide enough
information to the client. The client will decide wether
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373785 ]
Norman Maurer commented on JAMES-468:
-
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
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373663 ]
Steve Short commented on JAMES-468:
---
This patch returns the wrong status code when the recipient limit is reached.
It currently returns 571 but it should return 452. See
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373665 ]
Steve Short commented on JAMES-468:
---
I forgot to add this status should prevent the addition of further recipients
but should not invalidate the mail, the client must be
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373670 ]
Norman Maurer commented on JAMES-468:
-
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
Norman Maurer (JIRA) wrote:
I will fix it soon..
If I can give you an hint on bugfix workflow:
1) change the tests to check both issues and see them failing
2) fix the involved class
3) rerun tests and see they pass.
4) provide the patch
Stefano
Limit MaxRcpt per Email
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12373674 ]
Stefano Bagnara commented on JAMES-468:
---
Is this alternative described in an RFC ?
If not we should follow the standard behaviour (452 and accept remaining
recipients)
[
http://issues.apache.org/jira/browse/JAMES-468?page=comments#action_12372995 ]
Norman Maurer commented on JAMES-468:
-
Feature Complete.
Limit MaxRcpt per Email
---
Key: JAMES-468
URL:
