On Tue, 1 Aug 2006, John Rudd wrote: > Not directly stopping spam, but helping to close holes that are > manipulated by spammers, and make it easier to track them: > > 1) Require Virus Scanning on all SMTP transactions, on the recipient's > side of the transaction (ie. the "Server") (to help minimize zombie > PCs). Any SMTP server which accepts a virus laden email, for which > their anti-virus engine already had an update for that virus, should be > held accountable on every level for any damage done by that virus > instance. Any SMTP server which doesn't run a virus scanner would be > accountable for every virus that passes through their system.
Infeasible, too many players, too many technically unsophisticated players. > 2) Require Domain Keys on all messages Infeasible, too many players, too many technically unsophisticated players. > 3) Require accurate reverse DNS records for all IP addresses in use by > a given IP block Feasible and desirable, only ISPs need to be involved. > 4a) maybe generalize #4 to include various other RFC issues (matching > PTR and A records is an RFC requirement, after all), such as the things > tracked at RFC-Ignorant Less feasible, too many players. How about: domain registrars are required to block any domain they have registered that does not have working (i.e. read-by-a-human) postmaster@ and abuse@ aliases? > 5) Require ISP's to channel their customer's email through their own > mail servers (which will have some impact upon SPF tracking as well) > and not allow any non-business customers, nor any dynamic customers > (business or commercial), to directly connect to other mail servers. Totalitarian regimes will *love* that one. ISPs will hate it. > 6) establish a global RBL that has 4 aspects: DNSBL (like Spamhaus), > URIBL (like SURBL), a Domain Key blacklist, an RFC-Ignorant type black > list (covering items 3, 4, and 4a above, as well as what RFC-Ignorant > covers now), and a blacklist of servers which don't maintain anti-virus > filters. I preferred the idea of requiring ISPs to maintain DNSBLs for their dynamic ranges. Simple and effective. > 6a) to go with #6, an international body for reporting spam incidents, > which would be used to feed the RBL Bureaucratic overhead ensures that one is a nonstarter. > 6b) to go with #6a, a requirement that email clients make it "user > friendly" to forward messages with full/raw headers to the body in #6a I'm reluctant to suggest lots of "requirements" (read: laws) that dictate behavior by individuals or requirements for software vendors. Such is too easy and tempting a target for legislative abuse - and what legislator, anywhere, understands these technical subjects at the level necessary to pass effective yet limited legislation? 'course, legislating requirements for ISPs is an equally slippery slope... -- John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/ [EMAIL PROTECTED] FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- [Small arms] are fundamentally dangerous and their removal from the equation either by control, neutralisation or removal is essential. The first step is to gain information on their numbers and whereabouts. -- the UN, who "doesn't want to confiscate guns" -----------------------------------------------------------------------
