On Tue, Mar 02, 2004 at 10:31:58AM +0100, Vincent Lefevre wrote:
| On 2004-03-01 15:08:17 -0500, Derrick 'dman' Hudson wrote:
| > On Sun, Feb 29, 2004 at 10:16:23PM +0100, Vincent Lefevre wrote:
| > | RFC 2821:
| > |
| > | An SMTP server MAY verify that the domain name parameter in the EHLO
| > | command actually corresponds to the IP address of the client.
| > | However, the server MUST NOT refuse to accept a message for this
| > | reason if the verification fails: the information about verification
| > | failure is for logging and tracing only.
| >
| > You have a nice Catch-22 here. The receiver is not allowed to reject
| > bad data, but the sender isn't allowed to send it either!
|
| This isn't necessarily bad data.
RFC 2821, section 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
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 [...], the
client SHOULD send an address literal
If the client gives a domain name that is not fully-qualified, it
violates the specification. Therefore it is bad data.
| Some machines have several interfaces, i.e. several IP addresses,
| and several FQDNs may resolve to the same IP address; so, the FQDN
| and the IP address seen by the server won't always match.
Sure. I have no problem with this.
| Same problems with machines on private networks, when NAT is used.
Those machines could have domain names, although they might not be
listed in the public DNS. They could also provide an IP address.
| > It boils down to what you, as a receiver, find acceptable. I find
| > requiring the HELO to be syntactically correct and fully-qualified to
| > be effective at limiting junk (spam and viruses) while not causing
| > significant collateral damage. I think requiring the name to resolve
| > to the same address as the client connecting is being too strict. In
| > fact, I have found that requiring the name to resolve to anything
| > creates too much collateral damage. YMMV.
|
| Well, I think that requiring a FQDN (i.e. with at least a dot) is even
| too much, as the FQDN is completely useless and most spam messages are
| sent with a valid FQDN anyway.
Many are sent without it. Here are some of my stats from last week :
Helo command rejected: Don't use my own hostname (total: 72)
Helo command rejected: Invalid name (total: 6)
Helo command rejected: localhost? Really? Nah, fix your hosts file. (total: 4)
Helo command rejected: need fully-qualified hostname (total: 215)
Helo command rejected: Your software is not RFC 2821 compliant (total: 194)
That is 491 junk messages I did not receive due to simple sanity
checking of the HELO parameter. It works for me.
It is easy enough for anyone who wants to send mail to either relay it
through a provider, or to provide a syntactically valid
fully-qualified name or IP address that I don't consider the checks I
enforce to be too strict. You're free to not enforce these checks on
your own server if you don't want to.
-D
PS:
"Invalid name" - the name contained characters not allowed by the RFC
"not RFC 2821 compliant" - an IP address literal missing the brackets
"localhost" / "my name" - since the HELO is "Hello my name is
...." then only I can fill in the blank with my own name.
Anyone else who does that is, clearly, wrong. I think
spammers and/or malware do this to hide their own identity yet
pass the fully-qualified and exists-in-DNS tests some sites
perform.
PPS Interesting, I just reread the paragraph of RFC 2821 you quoted
earlier, and I technically comply with that -- I reject messages
for failing other verifications but not the one described in that
paragraph.
--
NOTICE: You have just been infected with Cooperative UNIX Email Virus.
To cooperate please run rm -rf / as root.
Thank you for your cooperation
www: http://dman13.dyndns.org/~dman/ jabber: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature