Closed ietf-svn-bot closed 3 years ago
@alexey.melnikov@isode.com changed title from Remove or deprecate the work-around from code 552 to 452?
to G.5. Remove or deprecate the work-around from code 552 to 452?
@alexey.melnikov@isode.com set component to smtp
@alexey.melnikov@isode.com commented
Discussion thread:
https://mailarchive.ietf.org/arch/msg/emailcore/IREZktaUrAyUD1zbnl9x-5QR1vI/
@alexey.melnikov@isode.com changed status from new
to assigned
@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com
@alexey.melnikov@isode.com commented
It looks like Viktor Dukhovni and Jeremy Harris are disagreeing with John Klensin that sending MTAs are treating 552 in response to RCPT TO as 452.
(As a participant) I agree with Viktor/Jeremy.
@alexey.melnikov@isode.com changed _comment0 which not transferred by tractive
@alexey.melnikov@isode.com commented
I think WG discussion reached agreement that the following sentence should be removed:
Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works.
@alexey.melnikov@isode.com commented
Implemented in -03.
@alexey.melnikov@isode.com changed status from assigned
to closed
@alexey.melnikov@isode.com set resolution to fixed
keyword_SMTP
owner:alexey.melnikov@isode.com
resolution_fixed
type_defect
| by alexey.melnikov@isode.com4.5.3.1.10. Too Many Recipients Code
RFC 821 [3] incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works.
The suggestion in Section 4.5.3.1.10 may have outlived its usefulness and/or be inconsistent with current practice. Should it be removed and/or explicitly deprecated?
Issue migrated from trac:5 at 2022-01-31 12:33:24 +0000