Re: Why are we here? What are our goals?

[J C Lawrence wrote:]
(A real kick-a** email, thanks!)

>The whole system exists in service of the human behind the MUA, and yet
>that human has no direct way of influencing the solution stack that is
>supposedly working on his behalf.  This is, in IBM terms, Broken As
>Designed.  Currently MXes accept mail for their users with no way of
>knowing if that mail is desired or not (and thereby operate with
>horrible inefficiency), or of communicating that information back over
>the transport layer.

That's indeed correct.  I've long (since around the late '70s) felt
that propagation of such information outward is just as important to a
proper network as propagation inward; I mean, we do this as humans,
e.g. telling close friends and/or family members who to trust, and to
what extent, as we deem necessary.

>Yeah, this sounds like firewall rules territory.  The parallel is
>direct: firewalls are concerned with accepting and (variously) rejecting
>packet streams, just as email systems are for messages.  The difference
>is that firewall policies don't currently generally propagate and have
>little reason to.

On the contrary, there is essentially no difference between what
you're advocating and what firewall policies should be able to do: in
both cases, leaf nodes have lots of incentive to propagate policy
information upward into the "tree", which is a specific form of the
general case where nodes propagate policy information outward to the
"net".

I haven't kept up on the literature, but it seems to me that one
important tool for resisting DOS and dDOS attacks is precisely the
ability to propagate firewall policy upwards.

On the [email protected] list earlier this week, I posted about
experiments I was making having my qmail-smtpd program (an SMTP
"daemon" that is run once, as a unique spawned process, per incoming
SMTP connection) respond to spam and vermin it recognizes during the
DATA phase by sleeping for 4 minutes before issuing the first of a
long, multi-line temporary rejection message, and sleeping for about
45 seconds in between each message.

It was cool watching my max concurrency go from maybe around 10 on a
busy day to the low 90s.  Of course, most spamware/verminware
disconnects upon seeing the first line of the rejection message, if
not earlier, so instances of qmail-smtpd talking to those clients
would abort after the four-minute sleep.

But later I realized that "if not earlier" *meant* something: that, in
fact, it was entirely possible most or all of the spamware/verminware
that disconnected "prematurely" (before QUIT or even the end of a
multi-line message) was doing so immediately after sending the final
"\r\n.\r\n" of the DATA phase.  (If they don't care about the result,
why wait for it?)

So I tested the effects of this on a "legit" system via telnet to port
25.  Sure enough, I can close that telnet session immediately after
the DATA/. phase, and netstat shows the connection in "FIN_WAIT2"
state for only about a minute, while, on the server side, qmail-smtpd
sleeps, not aware that the TCP stack has that connection in
"CLOSE_WAIT" state.

Long story short, sleeping before returning the first line of the
result *does* tie up spamware/verminware resources (mainly, a free
port number for an outgoing connection) for about a minute longer, but
that's about it.  (So, to save my own server's plentiful resources, I
reduced the initial sleep to one minute.)

However, what if my *kernel* could be told, a la firewall rules, but
by programs such as qmail-smtpd, to "tarpit" the incoming TCP packets,
ACK'ing them only after a delay (and maybe randomly NACK'ing some,
just to be ornery)?

That's an example of propagating policy information upward and
outward.

And there's no reason it can't continue from there.  I don't know for
sure, but presumably some big ISP's switches/routers/whatever actually
handle the ACK'ing of inbound packets destined for their customers'
computers, keeping the packets around until they see the ACKs coming
back from their clients?  (Just don't know TCP well enough to be sure
that's possible; maybe it isn't.)

If that's the case, then it's rather pointless to have my own machine
"tarpit" incoming TCP connections, except the ones coming from within
my own neighborhood's network segment assuming those stay on the
segment, because the actual SMTP client isn't bearing much of an
additional burden as a result: my upstream ISP would be bearing it.

Continuing, if I indeed trust my upstream ISP, and can tell it to
tarpit a given incoming TCP connection, that could be a win-win
situation for both myself and my upstream ISP.

Seems to me that as long as they can easily implement and track such
info, an ISP would generally prefer to know its own customers'
firewall info (via propagation) to avoid having to clog up its own
internal bandwidth with packets that will be dropped or refused.

So, seriously, you're really on to something here, I think.

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>
--Fix qmail's qmail-smtpd so it doesn't crash on a big header line:--
		   <http://www.qmail.org/netqmail/>