[Dshield] ISP's not blocking egress 25/tcp (was: spoofed address)
Erik van Straten
emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl
Thu Jan 22 12:20:26 GMT 2004
Hi Chuck, SORBS, list,
On Wed, 21 Jan 2004 15:24:24 -0500 Chuck Lewis wrote:
> Also, and you smarter folks here please correct me, I think I've read/heard
> that a real easy way to vastly reduce spam is if ISP's would validate the
> address(s) that stuff comes from ?
It's not that simple. Currently backdoored DSL PC's directly submit
spam to the intended recipient's mailserver, entirely bypassing the
PC's Inet Service Provider MTA (Mail Transfer Agent, mailserver).
ISP's could force the use of their MTA's by blocking outbound SMTP
traffic (some already do), but some customers (like me) may want to
run their own MTA. Many customers object to any port-block, so it is
not in the interest of ISP's to do this (unless they get sued more
often for not taking action on misbehaving customers).
Also, blocking 25/tcp egress traffic and forcing the use of an
address like <joe@*.isp.tld> prevents customers from legitimately
using other sitenames, and may break mail forwarding (which,
unfortunately, spf.pobox.com does too). However, issues like these
can probably be fixed (I'm not sure about SPF).
Actually the situation is worse. If ISP's block egress 25/tcp and
force the use of their MTA's, then spammers will be pushed to use
that route if they backdoor a PC behind such a block. I can assure
you, they will (the ISP could introduce egress rate-limiting and
filtering which would be an emormous improvement). However, spammers
do send spam to spamtraps, which gets the ISP's mailserver(s) listed
on blacklists. One such "misstep" tends to suffice.
Some email blacklists are totally unreasonable, and therefore
counterproductive. They do not distinguish between backdoored DSL
PC's and mailservers that send huge amounts of legitimate mail on a
daily basis (like listservers). Therefore ISP's will be hesitant to
even consider blocking egress SMTP traffic. Thus, those type of
blacklists effectively do NOT help fighting spam; IMHO They Make
| Click: Check Entry
| Scroll down to "Database of servers sending to spamtrap addresses"
| Click one of the "Detail" buttons
| Click Yes on the security alert (untrusted CA and hostname mismatch)
| Read what it says
Note: 184.108.40.206 = mailhost1.tudelft.nl, one of the main Delft
We do not live in a perfect world. We do have compromised PC's on our
campus network, and we're fighting like h*ll to get these fixed, and
Note that many spamtraps are horribly misconfigured. They respond to
spams that come with spoofed originator addresses, and do NOT supply
a null return-path. Because of the spoofed originator address, the
bounce (generated by the spamtrap) is sent to an MTA that was NOT
involved before. If that bounce cannot be delivered, that MTA *must*
(RFC2821) inform the sender, which is the spamtrap. Kaboom.
So it is possible that the spam that caused 220.127.116.11 to get
blacklisted, originated from a PC not on our campus, was sent to
us by the spamtrap, and was legitimately returned to that spamtrap
because it could not be delivered on our campus. But then, it may
also very well have been a compromised PC or server on our campus,
that did send spam via 18.104.22.168.
I have been advocating blocking egress 25/tcp traffic on our campus,
with the exception of some legitimate mailservers (like mine :).
However, because of some issues (that can probably be fixed), and
perhaps because our main MTA is blacklisted, this measure is not yet
effective (it certainly does not help). Thank you SORBS.
Is anyone aware of advantages or complications of blocking outbound
SMTP that I missed?
Note: it is not my intention to start a flamewar which blacklist is
good/bad. Anyone who wants to do that, at least change the subject.
Erik van Straten
Sysadmin of a small research group
Delft University of Technology
More information about the list