search

jakartaee / mail-api

Jakarta Mail Specification project
https://jakartaee.github.io/mail-api
Other
244 stars 101 forks source link

Don't throw exception on unknown 2yz recipient error #577

Closed cjnewman closed 1 year ago

cjnewman commented 3 years ago

Describe the bug Jakarta mail presently throws an exception when the server response to RCPT TO is an unknown 2xx response. The standard states: https://datatracker.ietf.org/doc/html/rfc5321#section-4.3.2 ... Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only.

The standard states that servers SHOULD NOT send such responses, but unfortunately an engineer on OCI Email Delivery deployed and documented a new three digit code (254) which became a documented interface here: https://docs.oracle.com/en-us/iaas/Content/Email/Concepts/troubleshooting.htm and cloud stability rules require one year advance notice prior to changing a documented interface so once a plan to fix this is started, it will still take a year before it's fixed on the server side.

So this is a request to have Jakarta mail comply with RFC 5321 "MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only." by treating any 2yz RCPT TO response as a success.

The present workaround is complicated and described here: https://docs.oracle.com/en-us/iaas/Content/Email/Reference/known_issue.htm#javamail

To Reproduce Steps to reproduce the behavior:

  1. Send email with two recipients to a server that returns an unknown 2xx response code to one of those recipients (e.g., OCI Email Delivery with a suppressed recipient).
  2. Jakarta mail API raises an exception.

Also described here: https://docs.oracle.com/en-us/iaas/Content/Email/Reference/known_issue.htm#javamail

Expected behavior Jakarta mail API should not raise an exception in this case; the unknown 2yz response should be treated the same as 250 since in SMTP theory of reply codes (section 4.2.1), a 2yz reply is "Positive Completion reply".

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

Smartphone (please complete the following information):

Mail server:

Additional context Add any other context about the problem here.

jmehrens commented 2 years ago

@lukasj This seems like a valid issue but I think we'll have to move this over to angus-mail as the fix would be handled in the SMTPTransport class. Is there a way to move this issue to that project or do we have to manually copy it over?

lukasj commented 2 years ago

@jmehrens I have an option to "Transfer issue", do you see it too on the right side, bellow Lock conversation and Pin issue?

jmehrens commented 2 years ago

@lukasj Thanks for the tip I totally missed that button. Assuming we don't backport this to v1.x is it okay if I move this?

jmehrens commented 1 year ago

@lukasj only mail-tck and mail-spec show up as options for an issue transfer. The eclipse-ee4j/angus-mail is not allowed.