@@ -58,7 +58,7 @@ class UntaggedResponse < Struct.new(:name, :data, :raw_data)
5858
5959 # Net::IMAP::IgnoredResponse represents intentionally ignored responses.
6060 #
61- # This includes untagged response "NOOP" sent by eg . Zimbra to avoid
61+ # This includes untagged response "NOOP" sent by e.g . Zimbra to avoid
6262 # some clients to close the connection.
6363 #
6464 # It matches no IMAP standard.
@@ -280,7 +280,7 @@ class ResponseText < Struct.new(:code, :text)
280280 # ==== +QRESYNC+ extension
281281 # See {[RFC7162]}[https://www.rfc-editor.org/rfc/rfc7162.html].
282282 # * +CLOSED+, returned when the currently selected mailbox is closed
283- # implicity by selecting or examining another mailbox. #data is +nil+.
283+ # implicitly by selecting or examining another mailbox. #data is +nil+.
284284 #
285285 # ==== +IMAP4rev2+ Response Codes
286286 # See {[RFC9051]}[https://www.rfc-editor.org/rfc/rfc9051] {§7.1, "Server
@@ -1045,7 +1045,7 @@ def media_subtype
10451045 # === Bug Analysis
10461046 #
10471047 # \IMAP body structures are parenthesized lists and assign their fields
1048- # positionally, so missing fields change the intepretation of all
1048+ # positionally, so missing fields change the interpretation of all
10491049 # following fields. Additionally, different body types have a different
10501050 # number of required fields, followed by optional "extension" fields.
10511051 #
@@ -1060,15 +1060,15 @@ def media_subtype
10601060 # Normally, +envelope+ and +md5+ are incompatible, but Net::IMAP leniently
10611061 # allowed buggy servers to send +NIL+ for +envelope+. As a result, when a
10621062 # server sent a <tt>message/rfc822</tt> part with +NIL+ for +md5+ and a
1063- # non-<tt>NIL</tt> +dsp+, Net::IMAP mis-interpreted the
1063+ # non-<tt>NIL</tt> +dsp+, Net::IMAP misinterpreted the
10641064 # <tt>Content-Disposition</tt> as if it were a strange body type. In all
10651065 # reported cases, the <tt>Content-Disposition</tt> was "attachment", so
10661066 # BodyTypeAttachment was created as the workaround.
10671067 #
10681068 # === Current behavior
10691069 #
10701070 # When interpreted strictly, +envelope+ and +md5+ are incompatible. So the
1071- # current parsing algorithm peeks ahead after it has recieved the seventh
1071+ # current parsing algorithm peeks ahead after it has received the seventh
10721072 # body field. If the next token is not the start of an +envelope+, we assume
10731073 # the server has incorrectly sent us a <tt>body-type-basic</tt> and return
10741074 # BodyTypeBasic. As a result, what was previously BodyTypeMessage#body =>
0 commit comments