is there a RFC which suggests that the helo name should be DNS resolvable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

is there a RFC which suggests that the helo name should be DNS resolvable

Stefan Sticht
Hi,

is there a RFC or similar which suggests/requires that the helo name
should be DNS resolvable?

Cheers,

Stefan



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

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

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

/dev/rob0
In reply to this post by Stefan Sticht
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?

I think you are looking for RFC 5321:

https://tools.ietf.org/html/rfc5321#section-2.3.5

See also section 4.1.4 as linked from there, and also 4.1.1.1 which
explicitly lays out the EHLO/HELO syntax.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

Robert Schetterer-2
In reply to this post by Viktor Dukhovni
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


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

Miles Fidelman

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 (see  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. HELO

As discussed in Sections 3.1 and 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. 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]


RFC 5321                          SMTP                      October 2008


   available), the client SHOULD send an address literal (see
   Section 4.1.3).

   RFC 2821, 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 in RFC 821) 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 [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]


RFC 5321                          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 in RFC 821 and Section 2.4.

   The EHLO response MUST contain keywords (and associated parameters if
   required) for all commands not listed as "required" in Section 4.5.1
   excepting only private-use commands as described in 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

/dev/rob0
On Wed, Jul 05, 2017 at 03:11:57PM -0400, Miles Fidelman wrote:
> The language in RFC 5231 does not explicitly say that the HELO name
> should be resolvable, but strongly implies it.

No, it does.  Note that "domain" is given as the argument to
EHLO, and see how "domain" is defined in 2.3.5.  See also the
discussion of EHLO in 2.3.5:

"
o  The domain name given in the EHLO command MUST be either a primary
   host name (a domain name that resolves to an address RR) or, if
   the host has no name, an address literal, as described in
   Section 4.1.3 and discussed further in the EHLO discussion of
   Section 4.1.4."

That's a MUST.  Either resolve to an address or use an address
literal.

If we're RFC-lawyering, however, note that it does not explicitly
require that the EHLO name resolves to the connecting client's
address, just to "an address".

And continuing, any site MAY have policies which are not set out
specifically in RFC 5321 or other standards.  So this whole
discussion probably is pointless. :)
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: is there a RFC which suggests that the helo name should be DNS resolvable

Viktor Dukhovni
On Wed, Jul 05, 2017 at 02:41:30PM -0500, /dev/rob0 wrote:

> o  The domain name given in the EHLO command MUST be either a primary
>    host name (a domain name that resolves to an address RR) or, if
>    the host has no name, an address literal, as described in
>    Section 4.1.3 and discussed further in the EHLO discussion of
>    Section 4.1.4."
>
> That's a MUST.  Either resolve to an address or use an address
> literal.

However:  Section 4.1.4:

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9 for a more extensive discussion of
   rejecting incoming connections or mail messages.

So we have is a requirement for the EHLO name, if not an address
literal, to be a real domain that resolves to some address (A or
AAAA).  The server MUST NOT reject messages just because the name
does not correspond to the IP address of the connected client.

While there is no requirement to accept names that don't resolve
at all, in practice such a policy would block too much mail for
most sites, and is not recommended.

--
        Viktor.
Loading...