On Wed, Jan 14, 2009 at 09:04:58AM +0000, David Wilson wrote:
Perhaps you should review the SMTP protocol: sending a 5XX response
*refuses* delivery of a message. It does not transmit (or retransmit)
a message. It is difficult to see how one can be accused of "lob[bing]
a grenade" when one has never taken possession of it.
Because of the normal action of an MTA when it receives such an 5XX
response, i.e. it sends a non-delivery message, normally containing the
message, to the return path address. If that return path address is
forged, then the infection is bounced elsewhere. That is the grenade.
First, even if this is the case -- and it's rather unlikely that it is,
as I'll get to in a minute -- it is obviously disengenuous to
accuse the refusing system of being responsible for this situation.
And second, have you (rhetorical you) been paying attention to the
origination points of the vast majority of attempted malware deliveries
over the past decade? They're coming from places like this (seen within
the last hour here):
11.red-81-43-100.staticip.rima-tde.net [81.43.100.11]
12-216-204-70.client.mchsi.com [12.216.204.70]
122-82-124-91.pool.ukrtel.net [91.124.82.122]
1809ds4-fb.0.fullrate.dk [90.184.161.72]
78-0-202-32.adsl.net.t-com.hr [78.0.202.32]
89-180-255-125.net.novis.pt [89.180.255.125]
cable-87-116-168-96.dynamic.sbb.rs [87.116.168.96]
cpe-69-133-71-112.columbus.res.rr.com [69.133.71.112]
ip-90-187-210-98.web.vodafone.de [90.187.210.98]
Do you think any of those are actual mail servers? Do you think that
any of them actually are running an SMTP engine which does something
with rejected traffic? Do you think that any of them are running an SMTP
engine which even *notices* rejected traffic?
Malware authors have long since [mostly] outgrown the need to use existing
mail systems for distribution. Why should they limit themselves to a
small number of systems (~100K if the Leisi Conjecture is correct) when
they can use hundreds of millions? And why should they bother coding
elaborate, fully-functional, standards-compliant SMTP engines when
they don't care and have no reason to care about most of that functionality?
Third, you cannot know the state of a system which presents messages
carrying malware. It might be okay, except that its particular anti-virus
setup did not detect this particular virus at this particular time.
Or it might be fully-compromised, 0wned by the enemy, and repurposed
as a full-time virus distribution engine. Or anything in between, or
something quite different. Because you CANNOT know its state, you CANNOT
predict what it will do in response to any SMTP response code you send it.
It *might* generate an NDR. It *might* ignore it. It *might* try sending
the same message again. It *might* crash instantly. It *might* do all
kinds of other things. [1]
Because you can't know this, it's pointless to speculate, and even more
pointless to arbitrarily choose one possibility among many and then try
to address that one as if it were a certainty. It's clear that the
best you can do is to refuse the traffic, at which point you've done
your part not just for your own operation, but for the rest of the 'net
as well. (And optionally, depending on circumstances, refuse *all*
traffic from it, as I do from the hosts above, since it's clear that
100% of everything they will ever present will be spam and malware.)
Fourth, and this veers a bit off-topic, but do realize that not everyone
uses the markedly inferior operating systems which are routinely compromised
via malware authored by mere children. I consider any operating system
which requires anti-malware software to survive in the wild to be seriously
broken and therefore unworthy of any further consideration. ("The brakes on
this car don't work, but you can buy this add-on which will patch them...")
Yet, out of a sense of responsibility to the greater Internet community,
I've expended considerable time and money designing and deploying
anti-malware measures, NOT for my benefit, because I don't care about
malware and don't have to care, but for theirs.
However, the reach of those measures, like everything else I've done,
extends only as far as the perimeter of my own operation. That's also as
far as my responsibility extends. I can't affect what happens "out there",
other than perhaps indirectly via my limited power of persuasion,
and I certainly can't be held accountable for it.
On the other hand, who can we hold accountable for
cpe-69-133-71-112.columbus.res.rr.com [69.133.71.112]
and the other systems like it? I'll argue:
a) the putative (former) owner whose desk or lap it sits on
b) the new (real) owner(s) who have repurposed it
c) RoadRunner's network engineers
d) the vendor of the operating system it's running (do I even need
to mention which one passive OS fingerprinting indicates?)
So if we must get into a policy debate about responsibility, I'll be
happy to engage in discussion about which of a-d should be at the front
of the line, and which should bring up the rear.
---Rsk
[1] In the typical case of zombies like the ones I listed above, the
treatment of *any* SMTP response code is "ignore it". The SMTP engines
installed on such systems are designed to maximize attempted deliveries
per unit time, and one excellent way to do that is to ignore everything
sent back by the recipient MX.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg