ietf-clear
[Top] [All Lists]

[ietf-clear] "Registering" unauthorized MTAs

2004-10-13 07:23:55
Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
From: John Leslie
Tony Finch <dot(_at_)dotat(_dot_)at> wrote:

These include using made-up hostnames or hostnames without CSA records.

I don't understand why that's an attack worth securing against. Simply,
the single UDP DNS query is made, and returns NXDOMAIN. There is no
danger of misinterpreting this as CSV-authorized. At worst, we're no
worse off than before CSV.

We need to be better off than before to make it useful.  Otherwise, it
appears that the protocol is geared to facilitating acceptance, which
is not a compelling problem for recipients.

   Recipients face a two-sided problem. In addition to needing measures
to reject large quantities of spam, they need to deal with problems
caused by false rejections.

   We should not be trying to sell CSV as a "rejecting more" tool, IMHO.

   Granted, it can show _less_ false rejections; but false rejection is
in the eye of the beholder -- and there assuredly will be cases where
the controlling domain considers the use of a subdomain in EHLO to be
unauthorized while the actual recipient considers the email desirable.

   If we accomplished all that Tony seems to be asking for, we'd still
be creating more false rejections in the eyes of senders and recipients.
The strength of CSV in rejection probably _is_ better than many existing
anti-spam measures, but it cannot be perfect.

   OTOH, the strength of CSV in documenting actual authorization is as
good as DNS itself. Tied in with a well-designed, scalable accreditation
system, CSV can provide arbitrarily-good levels of spam control. This,
IMHO, is what we should be selling -- not CSV by itself as a spam-control
tool.

   As an ISP, I would find it _very_ attractive to have a tool which
allowed me to bypass existing blacklists for email which is clearly
authorized by domains with excellent reputations. Currently I have to
deal with users who _both_ want me to filter more spam and want me to
let through the stuff they consider good. Support calls are expensive!

I would hope that the reputation check recommended by CSV could report
that somejunk.dotat.at is covered by a directive from dotat.at to treat
subdomains without their own CSV record as "unauthorized". That's the
second UDP DNS query (or very likely a query to a database in memory);
and the "attack" fizzles right there.

The particular way that a reputation service finds that directive is
certainly open to discussion...

I don't think that reputation services are suitable for domain policy
statements. 

   Perhaps I should introduce you to Doug Otis, who has recently been
arguing (in private email) that such services should _only_ repeat
domain policy statements. ;^)

   (That's not entirely fair to Doug. A more accurate statement is that
he claims there will be situations where lawyers won't let them do
anything else.)

   I don't want to open that particular can of worms any farther than
necessary; but I will state my opinion that _some_ reputation services
clearly _will_ repeat domain policy statements for some domains; and
_some_ receiving SMTP servers will find that information useful.

There are potentially too many of them and they should have
nothing to do with the domain itself.

   I'm confused. What's left for them to do if we limit them that way?

It is probably best for a domain to publish policy directly, and I
suspect that is what Tony is getting at with his questions. 

   I'm delighted if a domain publishes its policy directly.

CSV records have the appearance of a policy statement for the domain,

   True, so far as it goes: they're policy for the exact domain of the
DNS query. Currently, at least, they say nothing about subdomains.
There is room for expansion in the SRV fields; so it _is_ possible to
add statements about subdomains. We can certainly discuss that; but I
will advise some caution in doing so -- and I'd be far happier if we
didn't put that in the critical path of getting CSV's first publication
as a RFC. (YMMV.)

so they should stand alone and be complete for the problem space they
cover. 

   I don't think I agree. CLEAR's charter calls for designing low-level
tools. We should be _very_ careful about requests to turn CSV into a
"complete" solution to any problem.

I may well misunderstand the overall goal, so please educate me on this
if I have it wrong.

   I can't say you're wrong; I've tried to give my view of the situation.
CSV sets out to document authentication, authorization, and accreditation.
I see it as something which _could_ be deployed as it stands, and expanded
as we gain experience with it. I, at least, would use it to bypass
blacklists (and move some existing blacklists to reject at SMTP time
instead of merely being another input to Spam Assassin). But the actual
use of CSV is not what we should be discussing.

   No doubt there are others who believe it wouldn't be deployed unless
we can show it to reject spam. I know from experience how hard it is to
change people's beliefs. Even if I succeed in convincing people that
the "benefit" of rejecting some existing spams would be short-lived, I
won't have changed that belief.

   But I do cherish a hope that we can keep issues separate. As it stands,
it will reject some existing spam. I won't be using that fact in any of
_my_ sales pitches, but neither will I try to stop others from doing so.
What I _will_ do is try to make sure we're clear in our design goals,
and don't promise more than we can deliver.

So that made-up-name.cam.ac.uk or not-an-mta.cam.ac.uk don't turn up in
blacklists because they are routinely used by malware.

I must be missing something.

What harm is there if made-up-name.cam.ac.uk appears on a RHSBL?
You never intended it to send email in the first place. At worst, it
seems to me, it would save you the trouble of creating a SRV record
for it...

Having sub-domains show up as spew sources could affect the reputation
of the base domain.

   True, some reputation services do stupid things...

   Presumably, if you were contacted with complaints about spew from
a subdomain, you would add a CSV "not authorized" record for that
subdomain. (Well, I would, anyway.)

   What would that accomplish?

   (I wouldn't expect it to accomplish much of anything. If the spew was
actually from anything I actually control, I'd block it. If not, I'd
return a polite note saying what action I took and explaining why it's
really not under my control; but that I'm religiously careful about the
things I _do_ authorize with CSV. If the complaint was from a reputation
service which offered me a way to state "this set of subdomains is
specifically disclaimed by JLC.net", I'd take advantage of it.)

   The fact is, we're at the mercy of reputation services, even when they
do stupid things. We should not, IMHO, be spending our efforts trying to
make CSV proof against stupidity.

OK it isn't binary, but it does allow you to reject with certainty a
lot of obviously criminal lying.

This is a side-effect. We shouldn't spend much time worrying about
what percentage of obviously criminal lying it catches.

In that case, I really miss the point of the protocol. If it doesn't help
reject trivial HELO forgeries in a reliable manner, why would I, as a
recipient, want to use it? 

   I've tried to explain that.

   In brief, existing blacklists create false rejections. Being able to
bypass the blacklist when it would lead to false rejections is a big win.
(Bigger, IMHO, than any benefit of rejecting a few HELO forgeries.)

Given a HELO name and the lack of a CSV record, how do I know if the
base domain publishes CSV records at all without doing an expensive
zone-cut algorithm? 

   A most interesting question.

   Actually, Doug and I are discussing how to make zone-cut cheaper.
(I'm nervous about reporting any of that discussion until I have a better
understanding of actual behavior of DNS servers other than "bind" and
the available DNS resolvers in the field.)

   But, that aside, zone-cut may not even correctly direct you to the
base domain. And whether they publish CSV records at all shouldn't be
taken as a strong indication whether they intend to publish CSV for
every subdomain that legitimately sends email.

If I know that the base domain publishes CSV records and this sub-domain
doesn't have one, I can use it as a tool to reject. 

   Indeed you could. And there are zone-cut algorithms that are known to
work correctly.

   But, IMHO, you'd be wrong to reject subdomains on that basis.

   (To be clear: however wrong I believe such a practice to be, the CSV
spec does _not_ prohibit such a practice, nor do I believe it should.
So long as this practice leads to a SMTP-time rejection, I believe the
situation _would_ tend to resolve itself.)

Without that, I can't.  What am I missing?

   I'm not sure you're missing anything.

   I think perhaps you're reading too much into some text in the spec
which needs to be fixed to make it clear what we do and do not promise.
Could you point out the text which leads you to expect that automatic
rejection of SMTP sessions where there is no SRV record for the domain
in the EHLO string is desirable?

--
John Leslie <john(_at_)jlc(_dot_)net>