ietf-wg-emailcore / emailcore

3 stars 0 forks source link

G.1. IP address literals in EHLO #1

Closed ietf-svn-bot closed 2 years ago

ietf-svn-bot commented 3 years ago

keyword_SMTP owner:todd.herr@valimail.com type_defect | by alexey.melnikov@isode.com


G.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

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com changed title from IP address literals in EHLO to G.1. IP address literals in EHLO

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com set component to smtp

ietf-svn-bot commented 3 years ago

@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.

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com changed status from new to assigned

ietf-svn-bot commented 3 years ago

@todd.herr@valimail.com set owner to todd.herr@valimail.com

ietf-svn-bot commented 3 years ago

@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.

ietf-svn-bot commented 3 years ago

@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."

ietf-svn-bot commented 3 years ago

@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.
ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com changed component from smtp to email-applicability-statement

ksmurchison commented 2 years ago

The proposed text was incorporated into as-03.