Author: Thomas Jacob Date: To: exim-users Subject: Re: [exim] verify = helo, PTR record lookup
On Tue, 2007-06-12 at 10:30 -0400, Marc Sherman wrote: > That is, by definition, broken reverse DNS. If it didn't do the
> double-check (look up the PTR record, then look up resulting host name
> and make sure it points to the same IP), then anyone could spoof mail
> supposedly coming from your site just by setting their PTR to point to
> your domain name.
>
> The fact that verify=helo fails here is a feature.
The Exim spec says
"matches the host name that Exim obtains by doing a reverse lookup of
the calling host address"
so basically "a reverse lookup" has to be read as
"reverse lookup/lookup-again using Exim's host_lookup technique"? Hmm.
I realise that technically speaking C) doesn't conform to
RFC 2821, but there seems to be a relevant number of legitimate
MTA's out there, that sends mail using an IP with a reverse lookupable
PTR
record, that points to their HELO string, which in turn points to
something stupid.
And HELO-strings are worthless for IDing the true origin of
an email anyway, but the PTR records of the IPs of
compromised systems cannot easily be manipulated by spammers,
but of course, they could simply do a PTR lookup of
the spam zombie host and use that as a HELO string.
> That, if true, would be a bug, I'd think. I don't actually use
> verify=helo, so I can't say if I've ever seen it do that in production.
Well it pretty much looks like it in the code:
src/acl.c
if (strcmpic(ss, US"helo") == 0)
{
if (slash != NULL) goto NO_OPTIONS;
if (!helo_verified && !helo_verify_failed) smtp_verify_helo();
return helo_verified? OK : FAIL;
}
but reading some more, one can possibly work around that by checking the
result
of $host_lookup_deferred after a verify = helo, as smtp_verify_helo uses
the same code as verify = reverse_host_lookup internally, for the
IP->PTR->Name=Helo->IP check, and a function that also updates
$host_lookup_deferred for the Helo=Name->IP check.