[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rt.amsl.com #7269] ietf.org mail blocking?
A short answer to you is the following.
RFC 2821 clearly states in Section 3.6 that:
Only resolvable, fully-qualified, domain names (FQDNs)
are permitted when domain names are used in SMTP.
However, perhaps we (the IETF) want to be a bit more generous in
what we accept, so I've commented more fully inline. As always,
"rules" can be changed.
-- On Friday, May 09, 2008 2:48 PM -0700 Eric Rescorla
<ekr at rtfm.com> wrote regarding Re: [rt.amsl.com #7269] ietf.org
mail blocking? --
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? --
>
- 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))
It looks that way, I agree. I'm told it doesn't mean that but I've
asked Glen to double check so we can be sure.
> 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).
When you say "no A record", do you mean it was not listed in the
DNS or just that it did not have an A record?
> 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?
While the host may certainly exist, presence in the DNS is commonly
used as a weak authoritative existence test. The assumption is
that a process, albeit a weak one, was exercised to approve the
presence in the DNS.
The obvious counter-argument is that a SPAMMER could own the domain
they're using and put anything they want in the DNS. The argument
is valid to the extent that SPAMMERS are not taking steps to hide
their existence or identity. While there are many ways to slice
the "email pie" to find the bad parts (the SPAMMERS), I think we
can at least agree that connection sources who are attempting to
hide their existence or identity are SPAMMERS. For those cases,
this test is just one mechanism among many that is helpful in the
fight against SPAM.
Of course it's valid to ask how effective this is for the IETF. I
don't know offhand but I'm sure if we're interested in that
statistic we could probably arrange for it to be gathered and made
available.
> 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 using "anonymous" to mean that the origin of the connection is
not clearly identifying itself. Yes, it could "lie" to get past
this particular check but that's exactly the point. It's not even
trying to "do the right thing".
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.
No problem. I'm all for change, too, if folks believe that
something else is more appropriate.
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
Agree.
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.
I agree.
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)
This is all true. This is why these tests contribute to a SPAM
score via SPAMASSASSIN but are not otherwise definitive tests.
The only definitive test being employed here is the simple test of
whether or not a client is correctly configured, i.e., is it
identifying itself? This is a very minimum configuration setting.
In fact, it's darn near the first thing you have to set when
installing any email application, whether it's a client or a
server, which is "what is my name?" In my opinion if you can not
get your own name right then anything you do should be immediately
suspect.
Of course, 'getting it right' means doing two things. First, the
application has to know what its name is. Second, that name also
has to be somewhere it can be confirmed, in this case the DNS.
Yes, I agree, this test is weak, but it is a commonly accepted
practice.
Of course, the IETF could choose to do things differently if we
don't like this rule.
Given the above two facts, I don't see how checks that involve
only forward lookups from value (3), the HELO value, are useful.
I wouldn't do a forward lookup on 3 to compare to 4. Relaying
makes that impractical. However, it is a common practice to do the
forward lookup on 3 and compare it to the value in 2. This test
does not work well in all environments (perhaps many), but it can
be used to contribute to a SPAM score effectively.
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.
Agreed.
Given the above, I don't see how rejecting on failures to resolve
values (3) or (4) make sense from an anti-spam perspective.
As a general rule I agree. However, the specific test here is
whether or not the name exists. Testing for existence, even if it
is a lie, is a good thing. The credibility of the value is tested
later by SpamAssassin.
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.
Agree to all this.
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?
It is true that people can "lie" and this is checked in
SpamAssassin and contributes to the SPAM score of a message. The
only mechanism employed at connection time is the most basic
configuration check. If the origin of a connection can not make
any attempt to identify itself in a way that can be verified, even
weakly, then that origin is summarily suspicious.
Jim
What have I missed?
Thanks,
-Ekr