Hallam-Baker, Phillip wrote:
Agree with your conclusion but your statement is not quite accurate.
I know that. I had composed a footnote outlining split-routing in my
original email, but removed it because it would confuse the issue
precisely for the reasons you yourself outline below, without
invalidating anything I said.
Since you raise it, I'll elaborate.
You said:
Some spammers have in fact developed schemes that involve spoofing the
source IP address of TCP sessions, but only where both IP addresses were
under spammer control.
<details of split-routing elided>. Precisely. Both IP addresses are
under spammer control, the listing still has precisely the desired
effect (blocking the undesirable email), and FPs are no more likely than
if the "alleged source" really was the true source.
Now if there were plausible circumstances where, say, infesting a real
MTA with split-routing malware was any more likely or preferable than
infesting a real MTA with non-split-routing spamware, it could be of
concern. But there isn't.
Split-routing requires very intimate and synchronous real-time
bidirectional communications between both IP addresses of the split. I
believe that most if not all implementations were where both IPs were on
the same machine, both IPs were "legitimately held" by the spammer (not
by infection). That scenario is no longer feasible at typical BOT volumes.
I don't know if it is still widely used but when is was being used the
disruption caused to the network was cosiderably higher than for normal
spam as you can expect.
It is not widely used any longer. At best, the technique is of value in
very limited circumstances ("effectively free/super cheap accounts with
associated real IPs", eg: AOL "first month free" disks). Secondly, it
also requires there to be a more "valuable" asset (the true source, a
paid high bandwidth account) that the spammer is trying to protect.
With BOTs, there is no "paid high bandwidth account" to protect, or at
least, not by these means - all parts of the spam-sending exercise, and
much of the immediately visible portions of the web content delivery are
expendable (eg: domain tasting, expendible intermediate proxies, etc).
Secondly, the volumes that spammers need to send to get any return are
too high for this technique to be feasible.
At its height, a number of people noted that the only known mass-use of
this technique was via AOL. The CBL once listed over 20,000 AOL "ipt"
(end-user IPs) that were also outbound port 25 blocked by AOL. Yes,
there was some confusion (including that of AOL admin staff) of how this
was possible, but _not_ because it was interfering with legitimate email
- their non-spamming customers _couldn't_ send email that way anyway.
However, once they understood what the issue was, the fix (block inbound
port 25) was accomplished in very short order. If anything, the
juxtaposition of a CBL listing of the port 25-blocked AOL "split-end"
<grin> greatly speeded up resolution of the entire issue - certainly a
lot easier than whack-a-mole of thousands of individual accounts.
We've seen this situation a few times since then in a small way (none in
the last year or longer), but established practise is tending to
eliminate this as spammer-economy-viable (eg: see MAAWG Port 25
considerations document). In fact, I think the AOL experience is one of
the prompters of that document's existance.
Aside from unusual situations like AOL (back then), it is no longer a
useful technique for spammers to exert effort on, and even if it was,
the distinction is moot, because the effect/consequences of a DNSBL
listing of the back-haul of a split-routed connection is identical to a
non-split-route connection.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf