[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. --
Dave Rand wrote:
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
-- Scott Francis scott@ [work:] v i r t u a l i s . c o m Systems Analyst darkuncle@ [home:] d a r k u n c l e . n e t West Coast Network Ops GPG keyid 0xCB33CCA7 illum oportet crescere me autem minui
participants (3)
-
dlr＠bungi.com -
Eric A. Hall -
Scott Francis