Re: IM2000 RNASP -- identifying message stores to recipients

>It
>would be easy to publish a list of such domain names to avoid (known spam
>operations, etc).

Really?  I worry about this (for both IM2000 *and* SMTP).  It *seems*
easier at first, but, which is larger, the set of all possible domain
names, or the set of all possible IPv4 addresses?  Therefore, which is
easier for spammers *on the whole* to create and dispose of rapidly?

(It's tempting to think of an IP address, especially an IPv6 address,
as "cheap".  But we really do pay for each one, since we *must* have
at least one to get onto the Internet, whether we share it with
others.  We are therefore often unaware of its actual cost to us,
versus the explicit cost of having to own a domain name, since that's
optional for most purposes and a purchase we make ourselves.  Yet it's
likely that far, far more people and organizations own more domain
names than IP addresses than the other way around, especially if the
pertinent definition of "own", which includes all the subdomains of a
purchased domain names that are actually deployed, is used.)

An incoming SMTP connection requires an rDNS lookup to determine a
host name for it, if one exists.  That's overhead, and it's not
necessarily reliable information anyway.

(I believe rDNS is rarely useful for handling incoming email after
all, though it's helpful for logging and double-checking
configurations; my own qmail setup looks it up, but just logs it to
system log files and email headers, does no filtering based on it
whatsoever, yet manages to easily block the vast majority of incoming
spam and vermin.  It used to temporarily block no-rDNS injections,
but, on somebody's suggestion, I disabled that, discovered many of
them were legitimate bounces of joe jobs that could be easily
dispensed with, and the remaining spam and vermin I've since learned
to easily block without rDNS.)

We tend to assume DNS services are trustworthy, but, aside from issues
of security and reliability within the DNS implementation *itself*,
there's always the possibility that, starting at an arbitrary point in
the tree (say, the foobar.whatever.com heirarchy), the utility of DNS
for blacklisting fades away.  Reasons for this might include the
operator of the DNS at that point is a spamware enabler, or the system
running it has been taken over and become a zombie.

Either way, anything...foobar.whatever.com can be created and serve up
spam via an outgoing message store for as long as that works, so
blacklisting just that domain name does little more than tell the
spamware that it's time to gin up a new name under the
foobar.whatever.com heirarchy.

So you can't just look at a particular "leaf" in the tree, without
being sure you can trust each of the branches, starting from the root
(.), that lead to it, to not spawn arbitrary, short-lived subdomain
names.

The same goes for IPv4 addresses as well, but since they're limited,
their owners (and customers) have added incentive to keep the ones
they own "pure", lest they be blacklisted.  The metrics for listing a
branch (say, a /24 branch) are clearer: if you have N distinct /32
addresses within a /24 branch that are transmitted spam, and no others
that transmit legitimate email, given that you already know the
maximum for N is 254, you can easily decide whether N has reached the
point that *you* will blacklist the entire /24, on the theory that
*all* addresses in that range are probably hijacked, or hijackable.

I've tended to shy away from suggesting IPv4 addresses instead of
domain names be listed in blacklists, because I don't "own" my dynamic
IP address, yet I do own three domain names that point to it.

But I can't justify blacklists having to special-case my sort of
situation by using domain names as a basis to punch holes through IP
blacklists; after all, a bazillion random domain names can be
theoretically be resolved to a given IPv4 address, times 256 for a /24
IPv4 address, so it would actually be potentially very expensive to
whitelist known-good domain names, and even more expensive to
blacklist known-bad ones.

And, when I consider what I (or someone else) might actually want to
block, it's not the *domain* name, rather, the computer system, plus
any other systems under that owner's control, that is what I want to
block, and that is more closely coupled (when considering economics as
well as technologies) to IPv4 addresses than domain names.

(It's true that a domain name might well resolve to several distinct
IPv4 addresses, and that discovering one to be a source of spam is
probably a good indicator that the others are as well.  But is that
true *enough*?  If, of three IPv4 addresses to which example.com
resolves, each runs different OS and mail-server software, and only
one gets turned into a zombie, it's perhaps a *feature* that, upon
blacklisting that one, the other do *not* get blacklisted.  Of course,
that should be taken into account for IP address grouping, e.g.
blacklisting an entire /24 because "enough" addresses within it have
recently committed offenses; they may have nothing to do with each
other, in terms of ownership and type of OS/server software.)

So I've come to believe that it's actually easier for
generally-untrusting systems, like SMTP servers and IM2000 recipient
agents, to use IPv4 addresses as keys into their blacklisting data
bases, as most tend to do today anyway.

And the blacklisting criteria should include "Time of Most Recent
Offense" parameters that allow IPv4 addresses to "fall off" the
blacklist, on a schedule that each site determines for itself.

IM2000 has a substantial technological advantage over SMTP in that it
can take its own sweet time determining whether the host that holds
the outgoing message (the SMTP client injecting it or the IM2000
outgoing message store serving it) is trustworthy before transmitting
mail content: with SMTP, delays in making that determination result in
connections timing out and subsequently redelivery attempts, and
nobody easily benefits from sites being blacklisted *after*
notification in SMTP, whereas those who wait until they actually read
their email to pull it via IM2000 benefit quite naturally from this
scenario.

OTOH, SMTP can more easily tie up offending site resources by
tarpitting incoming SMTP connections, at the SMTP protocol level as
well as at the TCP level for each such connection.  And it can do that
according to a weighting for *degree* of offense, so the occasional
offense just slows things down a bit for that site (which becomes a
serious problem for *that* site, to the extent its occasional offense
is committed against a great many hosts, while the tarpitting site
doesn't see much negative effect due to employing its mild form of
tarpitting).

SMTP thus allows a response that takes more advantage of an
"opponent's" thrusts, in the form of push-style email injection, while
IM2000 offers more of an inherently passive, you-go-your-way-and-I'll-
go-mine, response.


Anyway, what I'm thinking, then, is that maybe ServiceLocation
*should* be as JdBP apparently proposes -- a fairly vanilla host:port
specification, where host is either a domain name or an IP address.

It seems superfluous to demand that an outgoing message store also
have a domain name, which would imply that every "pull" operation
require a DNS lookup even when it isn't actually needed.

Beyond that, I suggest the focus on blacklisting and other reasons to
share information on data stores be either on IP addresses or via
chain-of-trust relationships for domain names, starting with the root.
(That's different from web-of-trust, which is a more general idea in
that it supports arbitrary roots; we already implicitly accept
chain-of-trust as a necessity on the Internet.)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>