[In the message entitled "Re: Stealth Blocking" on May 24, 9:46, "Eric A. Hall" writes:]
Returning to operational traffic:
> One thing that I think *will* help, particularly in the short term, is
> port 25 blocking of dialup ports. It's my personal opinion that this
> will have the greatest impact on spammers who abuse open relays. I've
> watched this happen over the last few months, as various large networks
> have secured their dialup ports. It's impressive.
TCP rate-limiting on outbound traffic to *:25 would also be extremely
effective, particularly on unclassified customer traffic, and without the
heavy-handed nature of denying all dial-up traffic. Rate-limiting doesn't
interfere with low-volume legitimate mail, but it really cramps spam.
I'm not sure how effective rate limiting will be. Many spammers send one
copy of the spam to an open relay, but use many (2 to 50) recipients.
I'm unaware of a product that could limit (say) based on the number of
connections from a given dialup port. Also, based on several providers
information, one dialup account is being used by several, or many,
spammer's machines at the same time, so even a per-IP port limit
wouldn't have as much effect as you might think.
One other way to do this might be to do port 25 blocking on new customers,
but allow customers to get unblocked on request after they have been around
a while... Isn't that the approach that AT&T used, to great success?
It's also interesting to note that at least one dialup reseller actively
markets to spammers, and attempts to negotiate unblocked dialups with the
various providers.
I'm not sure how effective rate limiting will be. Many spammers send
one copy of the spam to an open relay, but use many (2 to 50)
recipients.
Rate-shapers would also work on the relays. The idea is that if ISPs would
implement a default rate-limit (let's say 4kb/s) that it wouldn't
interfere with normal use. It would interfere with spam distribution
because it would slow down the big runs dramatically.
The negative side effect is that it cripples people who use email as a
file transfer protocol.
One other way to do this might be to do port 25 blocking on new
customers, but allow customers to get unblocked on request after
they have been around a while...
That would be nice as well and is something I've advocated. ISPs seem
unwilling to do this, and it would seem that implementing a default
low-bandwidth rate limit would mean less maintenance.
On Thu, May 24, 2001 at 10:23:23AM -0700, Eric A. Hall exclaimed:
The negative side effect is that it cripples people who use email as a
file transfer protocol.
fortunately, SMTP != FTP. It's a tossup whether it's more irritating to find 5
spams in my inbox or 1 5MB attachment from a salesdroid that things cc:ing a
mailing list with his latest Excel spreadsheet is a good idea. The more that
can be done to introduce people to the concept of using the right tool for the
job, the better. SMTP is not the right tool for the job of transferring large
files.
</pet peeve>
That would be nice as well and is something I've advocated. ISPs seem
unwilling to do this, and it would seem that implementing a default
low-bandwidth rate limit would mean less maintenance.
I can't figure why anybody would be unwilling to do this ... just make it a
part of your ToS that email takes one week to set up after the initial account
setup. Have the account order/setup date in a database, and a cron job that
runs daily to activate accounts with setup dates > 1 week previous.