At 11:19 PM +0200 2003/08/30, Peter J. Holzer wrote:
RFC 2821 requires the parameter to be either an FQDN or an address
literal. A client which sends an unqualified hostname is in violation of
the RFC without any good reason. (broken software and lazy
administrators are not good reasons, IMHO)
I don't see this requirement in 2821:
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.
Note the qualification of "if one is available." Also note that
there is no MUST assigned to this usage. The client SHOULD otherwise
use the IP address literal, but again this is not a requirement. The
address literal is defined in section 4.1.3:
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.
Note that the RFC explicitly states that the IPv4 address should
be in square brackets. Which is precisely the kind of behaviour that
I believe you said that you were refusing.
Any reason why it must identify itself as [10.0.1.5]? Why not with the
external IP address or as bradknowles.dyndns.net?
If it's behind a NAT, how would it know the external DNS name?
If that IP address on the NAT device is dynamically assigned and the
machine is not an intelligent host running software capable of
updating a dynamic DNS record (as 99.999% of all NAT/router devices
are almost certainly going to be), then how would the internal host
know what this external DNS name is?
That would be nice, but it's not required. We are working on a BCP for
mail administrators here, not on a technical specification for the SMTP
protocol.
You are correct, we are working on a BCP, and we can go beyond
the recommendations in the RFCs.
You can get an FQDN for free in a few minutes. If want to run a properly
configured mail server that is the least of you worries.
(Of course this is also true for spammers - they might adapt quickly if
people start to check helo parameters)
Indeed, a lot of spammers do already register valid domains, then
throw them away in hours or days, after they are done using them.
One could argue that if they don't understand DNS, they shouldn't run a
mail server.
I would like to be able to make such an argument. I really
would. Indeed, I could even see making such an argument part of a
BCP, but only if the recommended practice did *NOT* involve rejecting
the connection outright just because they did not have reverse DNS
properly configured.
In fact that was the reasoning behind the rDNS checks in
Klaus Assmann's anti-spam hacks for sendmail
And that's precisely the sort of thing that I believe we should
recommend against.
I know, I know. I used to do it myself. But my views have
recently changed.
(still only for
about 150 users or so - the results of a large ISP would be
interesting).
My subjective views have been based on my experience as the Sr.
Internet Mail Administrator for AOL from '95-97 (up to five million
users), and the Sr. Systems Architect for Belgacom Skynet from
'98-2001 (peak of ~one million users).
I'm not sure if we've got anyone on the list with current
experience and access to log data from such large ISPs, but I do know
that we have some people on the list with current experience and
access to log data from ISPs in the six-figure range. I would be
very interested to see their data.
--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg