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?
> | >
> | That they do it at all. You give me host only, then as far | as I
> know, you are a workstaiton, as that is how almost
> | every workstation connects.
>
> So you reject, or not? You said "almost all", how do you decide?
> | Otherwise, you have a broken server.
>
> Otherwise than what?
>
You are either a workstation that should not be sending to my server
directly as your ISP has relay servers for this purpose, OR your mail
server is VERY BADLY MISCONFIGURED! There is nothing to decide
HELO/EHLO == host only, connection == reject.
If your Server/Workstation REALY, REALY wants to send email to my server,
and your FQDN is not proper, then you HELO/EHLO with an IP Literal
HELO [IPADDRESS] as per the RFC's. Now, if the IP literal you send in
the HELO/EHLO phase does not match your connecting IP, I drop the
connection as it is 'false and misleading'. Just as 'false and misleading'
as issueing HELO/EHLO with false host or FQDN information.
>
> | > | as they are not valid email servers.
> | >
> | > Not as I read the RFCs. Cite?
> | Gladly... I will also save you the trouble of going to a website |
> jump to the bottom of this message where these citings are | posted
> (some sections not complete)
> |...
>
> Interesting, even RFC2821 contradicts itself on this point.
>
How so? I cited, where is yours?
>
> | > | And Greg is not the only one that requires host information | > |
> to valid in many different ways. --
> | >
> | > True, I'm sure. Which is not the same as saying it's a good idea.
> FWIW, | > when I experimented with much less strict consistency checking
> here | > (IP->PTR->sameIP), I got about 25% false positives. I have a
> hard time | > picturing any company that could afford to use such checks
> to reject | > mail.
> | >
> | I never said that I currently implement IP->PTR->sameIP,
>
> Nor did I say you did. I said *I* tried it, and saw what I said I saw.
>
> | you will get far
> | more than a 25% false positive rate.
>
> I didn't, but I didn't have it in place very long.
>
I have Never rejected on that basis nor do recomend it, but I do know
how to read my logs for all sorts of usefull information, just like
how many 'verified vs. !verified' hosts we get connections from.
>
> | I do however require that your
> | connecting IP meet one of these:
> | (yes PTR OR no PTR then A/CNAME == connecting IP)
> | AND
> | (A/CNAME == resolvable)
>
> Sorry, I can't follow that. There are two possible names of A/CNAME
> records, the HELO name and the PTR name if it exists. It's not clear
> which you mean where.
>
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.
(now these are only some of the tests that are done during the entire
coarse of an SMTP transaction, and the more you fail, the more likely
your connection is to be dropped or blacklisted)
>
> 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.
I get more rejections from servers that HELO/EHLO with an '_' in the
FQDN. Can't do that either, it breaks the rules for proper DNS
implementation.
>
> | Greg IS more strict than I am, but if you follow RFC2821 then | HELO
> blahblahblah MUST have IP==PTR==HostA/CNAME
>
> That makes no sense. HELO doesn't "have IP", do you mean the source
> IP? Or do you mean the IP you may get by resolving the HELO name?
> Either way, it seems you're still wrong. I find no mention of PTR
> records in RFC2821.
>
Valid and Proper PTR records are what 'Verified Domain Hosts' means.
That no matter how you look at it, ALL of the information matches.
(example: Does your bank trust the 'balance' listed on an ATM reciept if
it does not match what they have on 'other' records, or do the verify
everything from more than one source?)
>
> 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.
--
--EAL--
