On 5 Feb 2004 at 13:15, Edgar Lovecraft wrote about
"Re: [Exim] Require A records for ho":
| Fred Viles wrote:
| >
| > On 4 Feb 2004 at 23:53, Edgar Lovecraft wrote about
| > "Re: [Exim] Require A records for ho":
| >
| > | Fred Viles wrote:
| > | >
| > | > |...
| > | > | And almost all of those that use only host
| > | > | and not host.domain should be rejected
| > | >
| > | > Almost? What should be the discriminating factor?
|...
| There is nothing to decide
| HELO/EHLO == host only, connection == reject.
That was my point.
|...
| > Interesting, even RFC2821 contradicts itself on this point.
| >
| How so? I cited, where is yours?
In your post. Specifically, in section 3.6 it says:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
while section 4.1.1.1 says:
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.
(*if 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
(SHOULD, not MUST)
send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
So according to 4.1.1.1 it is valid to not send a FQDN, and valid but
not recommended (SHOULD vs MUST) to not send an address literal.
|...
| I have Never rejected on that basis nor do recomend it,
Agreed, neither have I. To experiment with it, I quarantined an
examined.
|...
| Clear to me:
| If you have a PTR record then OK
| If you have NO PTR record then what does the HELO/EHLO hostname find?
| if DNS lookup finds an A/CNAME record that matches your IP then OK.
| If no PTR record and HELO/EHLO [IPADDRESS] == connecting IP then OK.
Yes thanks, this is clear.
| >
| > FWIW, I found when I backed off to requiring PTRNAME->SameIP only when
| > PTRNAME exists I still had an unacceptably high flase positive rate.
| >
| > | Believe it or not, most spam/virus get kicked on those alone,
| > Of course it does. But even a 100% spam rejection rate is not usefull
| > if it comes with an unacceptable false positive rate.
| >
| I have not found this to be an unacceptable false positive rate.
You haven't mentioned trying it. What you describe above is not the
same, you don't even look up the address the PTR name resolves to.
|...
| > | Greg IS more strict than I am, but if you follow RFC2821 then
| > | HELO blahblahblah MUST have IP==PTR==HostA/CNAME
|...
| > I find no mention of PTR records in RFC2821.
| >
| Valid and Proper PTR records are what 'Verified Domain Hosts' means.
I don't find that term in RFC2821 either.
| > And even if you were right, it isn't relevant to the point I was
| > actually making when you jumped in: That rejecting mail on the basis of
| > failing either an IP->PTRNAME->sameIP test or a HELONAME->sameIP test is
| > simply not practical in the real world.
| >
| Yes, it is, when ALL of the information is taken as a whole.
I don't know why this is so hard to understand. *All* I said was,
when I tried each of the tests above I saw a false positive rate way
beyond what I think most organizations would find acceptable for
rejections.
You seem to be disagreeing, even though you've said you think I must
be unobservant for not seeing a much higher false positive rate. You
put forward a claim that RFC2821 requires conformant MTAs to have DNS
records such that a connectingIP->PTRname->connectingIP test would
succeed. Whether it does or not, it doesn't affect my point: that
there are way to many MTAs sending legitimate messages but failing
the test for it to be usefull. From a practical standpoint, it's
irrelevant whether such MTAs are RFC compliant or not.
- Fred
