Ralf Doeblitz wrote:
--On Dienstag, März 22, 2005 13:10:34 +0100 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
[...]
I've given mx 1 because the MTA needs to look this up anyway
For a MAIL FROM nobody(_at_)xyzzy you'd normally not check the MX,
or are you talking about MTAs trying some call back methods ?
Of course you do - unless you are willing to accept mail from senders
that you may not be able to send an DSN to. MX checking is done by
default in most MTAs AFAIK. So the additional cost of a naked MX (as
opposed to "mx:DOMAIN.example") is zero.
Interesting point. Sendmail 8.13.1 does't seem to do this by default.
How is it turned on?
However, at least sendmail does do 2 queries before the HELLO: a PTR on
the incoming IP, and a forward on the resulting name. If the IP's don't
match, it will add the 'may be forged' comment in the Received header.
It's been doing this since 1998. Google: "sendmail PTR lookup"
If the PTR does not resolve, it bounces like so:
R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily
denied. Cannot resolve PTR record for " $&{client_addr}
R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. IP
name possibly forged " $&{client_name}
If the A lookup fails, you get this:
R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP
name lookup failed " $&{client_name}
So this would indicate that a PTR lookup from an SPF record is nearly free:
If the mail is coming from a legitimate MTA, the PTR mechanism is free,
because the query has already been cached.
If it comes from a zombie whose ISP gives names to their IP addresses,
it's also free.
However, if it comes from zombie whose ISP does not use names for their
IP address block, sendmail will reject with 450 anyway.
Radu.