Closed ietf-svn-bot closed 2 years ago
@alexey.melnikov@isode.com changed title from IP address literals in EHLO
to G.1. IP address literals in EHLO
@alexey.melnikov@isode.com set component to smtp
@todd.herr@valimail.com commented
I'm wondering if this is the section of the specification that is deemed unclear:
4.1.3. Address Literals
Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name.
(I suppose my not being sure about which section is being referenced is further evidence of things being unclear.)
At any rate, I don't believe I agree with the premise of communication to report and repair the error being blocked in those cases where connections are rejected based on the EHLO argument being an IP address literal. I would expect that a site refusing mail under this condition would respond to the EHLO command with something on the order of "550 5.7.1 some text goes here"; whether or not the refusing site chooses to be specific about the reason for the rejection in the 'some text goes here' part is unknown.
@todd.herr@valimail.com changed status from new
to assigned
@todd.herr@valimail.com set owner to todd.herr@valimail.com
@alexey.melnikov@isode.com commented
I think the main question asked by this ticket is whether or not using IP addresses in EHLO should be allowed. If it is never allowed, then we can make syntax stricted. If it is allowed, then maybe the Applicability Statement document should talk about this issue (probably saying that use of IP addresses in EHLO SHOULD be avoided.)
Another question is whether it is ever Ok to fail EHLO if something syntactically valid (like IP address) is sent by the client.
@todd.herr@valimail.com commented
I think the main question asked by this ticket is whether or not using IP addresses in EHLO should be allowed. If it is never allowed, then we can make syntax stricted. If it is allowed, then maybe the Applicability Statement document should talk about this issue (probably saying that use of IP addresses in EHLO SHOULD be avoided.)
I think "allow them, but advise against them in the Applicability Statement" is the best way to go here. Something like:
"An IP address literal (or 'localhost') as the argument to EHLO or the domain part of MAIL FROM is quite likely to result in the message being rejected as a matter of policy at many sites, since they are deemed to be signs of at best a misconfigured server, and at worst either a compromised host or a server that's intentionally configured to hide its identity."
@todd.herr@valimail.com commented
Discussion from IETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore) landed on:
AS saying “IP addresses on public internet are bad” but don’t change this.
@alexey.melnikov@isode.com changed component from smtp
to email-applicability-statement
The proposed text was incorporated into as-03.
keyword_SMTP
owner:todd.herr@valimail.com
type_defect
| by alexey.melnikov@isode.comG.1. IP Address Literals
The specification is unclear about whether IP address literals, particularly IP address literals used as arguments to the EHLO command, are required to be accepted or whether they are allowed to be rejected as part of the general "operational necessity" exception. Some have suggested that rejection of them is so common as an anti- spam measure that the use of such literals should be deprecated entirely in the specification, others that the are still useful and used and/or that, whatever is said about IP address literals within an SMTP session (e.g., in MAIL or RCPT commands), they should continue to be allowed (and required) in EHLO.
Issue migrated from trac:1 at 2022-01-31 12:33:01 +0000