Regarding should not versus must not, I’m not arguing for either position—just saying that if it’s should not you should at least briefly discuss why an implementation might do this. If it’s for backwards compatibility, and no other reason, that’s worth saying.
Op do 17 okt 2024 om 08:20 schreef Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx>
On Thu, Oct 17, 2024 at 12:37:16AM -0400, John C Klensin wrote:
> > Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of 4.1.1.1
> > not a MUST NOT? What is the exception?
>
> I'll like to hear from others in the WG, but there was a certain
> reluctance to invalidate (i.e., render completely non-conforming)
> existing conforming implementations without clear evidence of harm.
> There is no harm here if servers accept it (rather than treating it
> as an error), even if they then ignore it, which is what the first
> part of the sentence essentially says. At the other extreme, SMTP
> servers are basically allowed to decline to accept a message for any
> reason(s) they find appropriate, so why should this be the exception?
> I don't have any idea how many SMTP clients do send that information
> or whether people who think market size is important would consider
> any such client worth considering.
MUST NOT (client sending) sounds right to me. To the extent that
Postfix tolerates this, the entire construct "[literal] ..." ends
up as the HELO name, including the trailing junk. But this would
typically fail the widely used "reject_invalid_hostname" restriction.
> ehlo [192.0.2.1] foo bar
< 250-...
< ...
mail from:<ietf-dane@xxxxxxxxxxxx>
250 2.1.0 Ok
rcpt to:<ietf-dane@xxxxxxxxxxxx>
501 5.5.2 <[192.0.2.1]?foo?bar>: Helo command rejected: invalid ip address
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
