Re: [rt.amsl.com #7269] ietf.org mail blocking?

["Eric Rescorla" <ekr at rtfm.com>]

On Fri, May 9, 2008 at 2:15 PM, James M Galvin <galvin at elistx.com> wrote:
>
>
> -- On Friday, May 09, 2008 1:14 PM -0700 Eric Rescorla <ekr at rtfm.com> wrote
> regarding Re: [rt.amsl.com #7269] ietf.org mail blocking? --
>
>> > Your machine HELO'ed as "romeo.rtfm.com"... except that host
>> > doesn't seem to exist or resolve:
>> >
>> > core3:/home/glen # host romeo.rtfm.com
>> > Host romeo.rtfm.com.amsl.com not found: 3(NXDOMAIN)
>
> Eric,
>
> As I understand it, your email was delayed (not rejected since the return
> code was 4xx) because the name in the HELO does not exist. It has nothing to
> do with the IP address.

You're making several observations here:

- That the mail was delayed (not rejected). I agree that this is notionally a
   transient error (because DNS sometimes fails) but it's not like it's going
   to fix itself, right? More like my mailer will keep trying and
eventually give
   up. That actually seems worse than immediate rejection since it takes
   days to get a bounce.

- I'm not an expert on reading the mail logs, but it actually looks more to
  me like its related to the reverse name resolution, given the listing of
  the IP here.

Client host rejected: cannot find your hostname, [74.95.2.173] (in
reply to RCPT TO command))

Perhaps it's the forward lookup on the reverse mapping for
74-95-2-173-SFBA.hfc.comcastbusiness.net


> Have you always done this?

Not always, but there hasn't been an A record for "romeo.rtfm.com" for
over a year
and it worked fine till at least 5/5 (which was the last time before today that
I tried to send mail through ietf.org).


> It should be the case that the IETF servers do not take messages from hosts
> that do not exist.

1. The host does exist. It just doesn't have a DNS entry.
2. Why should this be the case?


> The IETF does not apply strict connection controls but it seems reasonable
> to me to reject apparently "anonymous" messages.

What makes the message anonymous? I'm advertising "ekr at rtfm.com" in
my MAILTO.

I'm not trying to be difficult, but I'd appreciate it if you could work through
the logic for me of what checks you believe the system is doing and why
you think they are useful.

Here's my reasoning.

It seems to me that there are at least four potential values here:

(1)The IP address of my MTA.
(2) The domain name you get when you reverse lookup (PTR) the IP.
(3) The hostname my MTA advertises in HELO
(4) The RHS of the email address that my MTA sends in MAIL FROM

Here's what I believe to be true:

1. You can't require that values (3) and (4) match because my MTA
    might be relaying. In fact, it is, since I'm sending from "romeo.rtfm.com"
   but my email address is "ekr at networkresonance.com"

2. Given that I control the domain "example.com", I can put anything I want
    in "foo.example.com", so if I'm a spammer I can arrange that forward
    lookups for value (3) always succeed. Moreover, I can arrange that they
    match value (1)

Given the above two facts, I don't see how checks that involve only
forward lookups from value (3), the HELO value, are useful. In principle,
lookups from the MAIL FROM value (4), might be useful if they somehow
could be tied back to the message (e.g., via SPF or DKIM), but one
can't insist on that given the current state of the network.

Given the above, I don't see how rejecting on failures to resolve values (3)
or (4) make sense from an anti-spam perspective.


This brings us to the topic of values (1) and (2), about which I believe
the following:

0. In general the reverse mapping part of the tree is a mess.
1. That the ISP in general controls the relevant portion of the in-addr tree
    (though they may of course delegate).
2. That ISPs often do populate that section of the tree, but (especially with
    dynamic addresses) the values are synthetic, meaningless names,
    like the one above (i.e., <ip>.provider-domain.)
3. That sometimes those meaningless names forward resolve and sometimes
    they don't.
4. That there are some cases where users can get control of the in-addr
    part of the domain and some cases (dynamic IPs again) where they can't.

Because of point (2) you can't check that value (2) matches value (3) or
value (4). At best you can check that the reverse mapping exists and
that the forward mapping exists. However, the problem here is that
because of point (0), this causes spurious rejections, and therefore only
makes sense if it's significantly harder for spammers to get the
reverse/forward parts of the tree in shape than it is for ordinary
users. Why would this be so?

What have I missed?

Thanks,
-Ekr