Re: [Exim] exim HELO ack

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Jez Hancock
Fecha:  
A: Exim Users List
Asunto: Re: [Exim] exim HELO ack
On Wed, Aug 27, 2003 at 09:34:17AM +0100, Russell King wrote:
> On Tue, Aug 26, 2003 at 08:56:44PM -0400, Wakko Warner wrote:
> > I use this:
> >     drop    message = HELO doesn't look like a hostname
> >         log_message = Not a hostname
> >         condition = ${if match{$sender_helo_name} \
> >                       {\N^[^.].*\.[^.]+$\N} \
> >                  {no}{yes} \
> >                  }

> >
> > This means: Drop the HELO unless it contains a . somewhere in the HELO
> > string, but may not begin or end with a . (imposed minimum length is 3
> > chars). basically x.x is ok, but .x. is not
>
> Note that:
> - at least some Windows machines seem not to send a fqdn in their
> HELO string (despite being told both their host and domain names.)

OE6 on win2k appears to send the netbios name in the HELO. On reading
RFC821 this doesn't appear to break any standard, but then again doesn't
exactly adhere to the suggestions made later in RFC2821 either (namely
that in the absence of a FQDN the client SHOULD send an address literal
which on my reading equates to a dotted quad - IP address???):

(this from RFC2821)
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 field 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
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. y The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.

where the 'address literal' is defined in 4.1.3 from the same RFC2821:

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. For
IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form. For
IPv6 and other forms of addressing that might eventually be
standardized, the form consists of a standardized "tag" that
identifies the address syntax, a colon, and the address itself, in a
format specified as part of the IPv6 standards [17].

Specifically:

      IPv4-address-literal = Snum 3("." Snum)
      IPv6-address-literal = "IPv6:" IPv6-addr
      General-address-literal = Standardized-tag ":" 1*dcontent
      Standardized-tag = Ldh-str
            ; MUST be specified in a standards-track RFC
            ; and registered with IANA


      Snum = 1*3DIGIT  ; representing a decimal integer
            ; value in the range 0 through 255
      Let-dig = ALPHA / DIGIT
      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig


      IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
      IPv6-hex  = 1*4HEXDIG
      IPv6-full = IPv6-hex 7(":" IPv6-hex)
      IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
                 IPv6-hex)]
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 6 groups in addition to the "::" may be
            ; present
      IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
      IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
                   [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 4 groups in addition to the "::" and
            ; IPv4-address-literal may be present


Personally I'm not overwhelmed by spammers or other abusers who misuse the
HELO/EHLO command and I can't justify denying or dropping clients based
solely on the fact that they don't use a FQDN or even an address literal
in their HELO/EHLO - a lot of my users use OE which appears to not adhere
to this anyway.

--
Jez

http://www.munk.nu/