On 7/5/17 2:45 PM, Robert Schetterer wrote:
Am 05.07.2017 um 19:15 schrieb Viktor Dukhovni:
On Wed, Jul 05, 2017 at 06:57:17PM +0200, Stefan Sticht wrote:
Is there a RFC or similar which suggests/requires that the helo name should
be DNS resolvable?
SMTP is defined in RFC 5321 (which obsoletes 2821 and 821).
I think the question might be : is
reject_unknown_helo_hostname rfc alike today, it wasnt in the past
postfix faqs are only pointing
on
reject_non_fqdn_helo_hostname for rfc
additional
reject_invalid_helo_hostname is acceptable in real world setups
The language in RFC 5231 does not explicitly say that the HELO name
should be resolvable, but strongly implies it.
From RFC 5231 - note specifically the line "In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available),
the client SHOULD send an address literal (seeSection 4.1.3
<https://tools.ietf.org/html/rfc5321#section-4.1.3>).
And, in practice, an awful lot of mailers, and spam filters, will reject
incoming
connections at (E)HELO, if the domain doesn't resolve, and match the source IP.
F.3 <https://tools.ietf.org/html/rfc5321#appendix-F.3>. HELO
As discussed in Sections3.1 <https://tools.ietf.org/html/rfc5321#section-3.1>
and4.1.1 <https://tools.ietf.org/html/rfc5321#section-4.1.1>, EHLO SHOULD be used
rather
than HELO when the server will accept the former. Servers MUST
continue to accept and process HELO in order to support older
clients.
4.1.1.1 <https://tools.ietf.org/html/rfc5321#section-4.1.1.1>.
Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
Klensin Standards Track [Page 32]
------------------------------------------------------------------------
<https://tools.ietf.org/html/rfc5321#page-33>
RFC 5321 <https://tools.ietf.org/html/rfc5321> SMTP October 2008
available), the client SHOULD send an address literal (see
Section 4.1.3 <https://tools.ietf.org/html/rfc5321#section-4.1.3>).
RFC 2821 <https://tools.ietf.org/html/rfc2821>, and some earlier informal
practices, encouraged following
the literal by information that would help to identify the client
system. That convention was not widely supported, and many SMTP
servers considered it an error. In the interest of interoperability,
it is probably wise for servers to be prepared for this string to
occur, but SMTP clients SHOULD NOT send it.
The SMTP server identifies itself to the SMTP client in the
connection greeting reply and in the response to this command.
A client SMTP SHOULD start an SMTP session by issuing the EHLO
command. If the SMTP server supports the SMTP service extensions, it
will give a successful response, a failure response, or an error
response. If the SMTP server, in violation of this specification,
does not support any SMTP service extensions, it will generate an
error response. Older client SMTP systems MAY, as discussed above,
use HELO (as specified inRFC 821 <https://tools.ietf.org/html/rfc821>)
instead of EHLO, and servers MUST
support the HELO command and reply properly to it. In any event, a
client MUST issue HELO or EHLO before starting a mail transaction.
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keywords follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
RFC 5234 <https://tools.ietf.org/html/rfc5234> [7
<https://tools.ietf.org/html/rfc5321#ref-7>], is:
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
Klensin Standards Track [Page 33]
------------------------------------------------------------------------
<https://tools.ietf.org/html/rfc5321#page-34>
RFC 5321 <https://tools.ietf.org/html/rfc5321> SMTP October 2008
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices
specified inRFC 821 <https://tools.ietf.org/html/rfc821> andSection 2.4
<https://tools.ietf.org/html/rfc5321#section-2.4>.
The EHLO response MUST contain keywords (and associated parameters if
required) for all commands not listed as "required" inSection 4.5.1
<https://tools.ietf.org/html/rfc5321#section-4.5.1>
excepting only private-use commands as described inSection 4.1.5
<https://tools.ietf.org/html/rfc5321#section-4.1.5>.
Private-use commands MAY be listed.
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
