Hashcash isn't a viable solution once you have a couple of mailing lists, it'd hit legitimate senders harder than the botnet operators.
Our current mail servers are a mix of dual 2.4GHz Xeons and older 1.2GHz PIII machines. Planned upgrades will see us cutting costs by consolidating servers on ESX. Meanwhile even todays lowend desktop machines are able to match our servers for compute and botnet operators have access to plenty of them.
The answer is zombies retrying indefinitely? I have a "legitimate bulk mailer" who effectively tarpits himself by retrying every 4 mins for 5 days on 45x for each message. Multiply that by the amount of zombies out there - and welcome to DOS city!
If botnet operators are going to give up because of greylists, is my "legitimate bulk emailer" going to monitor his mail queue or prune his address lists? These people are spammers, we already know they don't care.
TLS won't stop the botnet operators either, modern desktop PCs are powerful enough to do the certificate exchange. It's our servers that would struggle with TLS and some (most?) SME servers are in fact NAT'd behind the dedicated IP.
Nearly all MTA software is configured to reattempt delivery. Now, thanks to greylisting even Zombies are beginning to retry on temporary failure. This sucks if (like me) you always thought greylisting was pointless but are rejecting clients for lack of forward resolvable rDNS.
I'm not sure I want that to automatically give the go-ahead so that anyone can send spam from "Need-Viagra@mydomain.com" and "refinance-your-house@mydomain.com", etc..., from those domains.
SPF authorizes outbound mail servers for a domain, it doesn't authenticate anything. Preventing cross user forgery is a matter of policy for 3rd party relay providers, there's nothing schemes like SPF can do about it.
Basically this guy is proposing an automated whitelist (for domains without SPF records) via a local database.
At least I think what the paper is about, I gave up reading it earlier. It lacks a concise summary, doesn't read like a well researched paper and the diagrams don't even display without javascript.
No but it is the widest known example (use rtorrent myself), there's also skencil and a multitrack recording app using gstreamer. I should also add that Microsoft seem to agree we'll be seeing more of these apps if their work on the DLR is anything to go by.
You have a really good point about advertising though. Microsoft have a scorched earth style ad campaign for their dev tools. They even worked to counter the possibility that windows devs would be exposed to open source tools by creating their own me-too shared/open source community sites. I'm not at all sure how the Microsoft advertising spend could be countered in a way that'd appeal to the Microsoft faithful.
Java is cross platform, naturally it's going to be slower than.NET. Performance is at least comparable and it's perfectly possible to write bloated, poorly performing code in C/C++ (hello acrobat reader).
the OP is an example of how well entrenched MS languages are with many developers.
That's kind of the point I was making. Not just that the MSDN mentality is entrenched, that Microsoft devs are often woefully ignorant of the alternatives. "developers, developers, developers" was afterall about getting developers to target Microsoft platforms exclusively. Terrifying concept:-(
Microsoft has secured a very strong foothold in the programming world. Using the.net framework, you can create powerful, attractive, large applications very rapidly.
Oh come on! Java and python and were already well established when.NET was vaporware.
While, it hasn't taken hold so much in the gaming development world, xna and directx 10 may change this.
More Microsoft proprietary technologies? The problem here is your mindset and nothing else.
Any application can print to postscript using good old lpd, ps2pdf does the rest. If you're on Windows you can install PDFCreator and again, print to PDF from any app.
Once a month my consulting invoices are output as PDFs using enscript, a tiny shell script pulls the data from sqlite (previously Berkeley DB), converts to PDF and emails the client.
Perhaps now is a good time to push for better adoption of SPF
That just forces the spammers to register short lived domains. We need registrars to start validating registrant details, then it really is game over for the spammers.
The current answer is to reject connections to a mail server if the connecting host lacks a forward resolvable RDNS, has a bad (non FQDN / your domain) helo string or is a known dynamic IP. Unfortunately, once you begin doing this you also have to manually whitelist the occasional site who are incapable of configuring DNS for their outbound servers correctly. My users don't see any storm emails and the only place I see storm is in the server logs.
I hope to see more collaborations between Microsoft and the Linux community in the future, not limited to Mono, but going beyond that.
Beyond that into more threats of patent litigation, more ghost lawsuits, more FUD and even more heavy handed lobbying? Here's what I hope to see; Microsoft competing in the market without abusing its monopoly position (Re Java, flash, pdf...).
Most of us get Microsoft loud and clear, how strange that you do not.
MS Office will always win as long as the standard document format is *.doc (or the new equivalent).
That's what I mean, you don't change the de-facto file format of a monopoly by supporting it.
If the document standard can be changed to an open one, then whether it's the next day or the next year, MS Office is history because the product itself is just not that good technically.
A bigger question is: Who polls their email client at work anymore?
Guilty, I use pine and miss or ignore delivery notices. Not just if I'm away from my desk, also if I have the (xfce) terminal minimized or I'm working in an alternate tab.
Admittedly, I'm not the typical user; I'd prefer to use telnet than a so-called 'modern client'.
The issue appears to be that a dump of the servers physical RAM would contain connected IP addresses. Removing the addresses from a RAM dump would be much more complex than removing or obscuring such data in a system log file.
TFA is gibberish.
there really isn't any filtering that can be done on reverse DNS without MASSIVE false-positives.
Anything below res.rr.com or adsl.tpnet.pl [east|dsl-w|fios].verizon.net (for example) are residential dynamic IP allocations.
Many, many valid businesses are running mailservers without rDNS or with generic rDNS based on their IP number.
And they can expect to have mail rejected until they find an admin who has enough of a clue to comply with widely praticed receiver policies.
Also, manu valid servers send bogus names in their EHLO/HELO, including domain names ending in.local or servernames not present in external DNS.
Which is wrong according to RFC2821:
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
Our machines are supposed to be able to connect to one another.
An unfortunate side effect of zombies is that mail obviously sent using dynamic addresses is rejected. It's wrong to blame receivers for their policies, the blame lies with botnet operators and users who fail to take adequate security precautions.
Neither can you expect receivers to whitelist dynamic addresses, the solutions are:
Relay through your providers smarthost
Get a static IP
Get a VPS and relay through that
It sucks much less than expecting receivers to accept spam.
If you are running a simple SMTP server on a cheap DSL or cable connection, chances are your reverse DNS lookup isn't going to match your intended host name.
If you're running an MTA on a cheap connection you need to use your ISP's smarthost, mail that appears to come from dynamic addresses is increasingly rejected due to zombies.
Matching forward & reverse DNS (and sometimes helo) is an additional requirement for delivery to certain servers.
Slashdot Mirror
Hashcash isn't a viable solution once you have a couple of mailing lists, it'd hit legitimate senders harder than the botnet operators. Our current mail servers are a mix of dual 2.4GHz Xeons and older 1.2GHz PIII machines. Planned upgrades will see us cutting costs by consolidating servers on ESX. Meanwhile even todays lowend desktop machines are able to match our servers for compute and botnet operators have access to plenty of them.
The answer is zombies retrying indefinitely? I have a "legitimate bulk mailer" who effectively tarpits himself by retrying every 4 mins for 5 days on 45x for each message. Multiply that by the amount of zombies out there - and welcome to DOS city! If botnet operators are going to give up because of greylists, is my "legitimate bulk emailer" going to monitor his mail queue or prune his address lists? These people are spammers, we already know they don't care.
TLS won't stop the botnet operators either, modern desktop PCs are powerful enough to do the certificate exchange. It's our servers that would struggle with TLS and some (most?) SME servers are in fact NAT'd behind the dedicated IP.
Nearly all MTA software is configured to reattempt delivery. Now, thanks to greylisting even Zombies are beginning to retry on temporary failure. This sucks if (like me) you always thought greylisting was pointless but are rejecting clients for lack of forward resolvable rDNS.
SPF authorizes outbound mail servers for a domain, it doesn't authenticate anything. Preventing cross user forgery is a matter of policy for 3rd party relay providers, there's nothing schemes like SPF can do about it.
The author may be an anti-spam kook but the paper is so badly written I can't be bothered identifying which.
No but it is the widest known example (use rtorrent myself), there's also skencil and a multitrack recording app using gstreamer. I should also add that Microsoft seem to agree we'll be seeing more of these apps if their work on the DLR is anything to go by.
You have a really good point about advertising though. Microsoft have a scorched earth style ad campaign for their dev tools. They even worked to counter the possibility that windows devs would be exposed to open source tools by creating their own me-too shared/open source community sites. I'm not at all sure how the Microsoft advertising spend could be countered in a way that'd appeal to the Microsoft faithful.
Except the official bit-torrent client etc..? I suspect we'll be seeing more as powerful multi-core machines become commonplace.
Java is cross platform, naturally it's going to be slower than .NET. Performance is at least comparable and it's perfectly possible to write bloated, poorly performing code in C/C++ (hello acrobat reader).
That's kind of the point I was making. Not just that the MSDN mentality is entrenched, that Microsoft devs are often woefully ignorant of the alternatives. "developers, developers, developers" was afterall about getting developers to target Microsoft platforms exclusively. Terrifying concept :-(
Oh come on! Java and python and were already well established when .NET was vaporware.
More Microsoft proprietary technologies? The problem here is your mindset and nothing else.
OO.org may have rasterized the text, can you zoom in and see if the OO.org PDF pixelates?
Any application can print to postscript using good old lpd, ps2pdf does the rest. If you're on Windows you can install PDFCreator and again, print to PDF from any app.
Once a month my consulting invoices are output as PDFs using enscript, a tiny shell script pulls the data from sqlite (previously Berkeley DB), converts to PDF and emails the client.
Is having a save as PDF button really a big deal?
Free ring-ding?
Vista may actually be usable like that. Why aren't Microsoft sharing this upgrade with their paying customers?
That just forces the spammers to register short lived domains. We need registrars to start validating registrant details, then it really is game over for the spammers.
The current answer is to reject connections to a mail server if the connecting host lacks a forward resolvable RDNS, has a bad (non FQDN / your domain) helo string or is a known dynamic IP. Unfortunately, once you begin doing this you also have to manually whitelist the occasional site who are incapable of configuring DNS for their outbound servers correctly. My users don't see any storm emails and the only place I see storm is in the server logs.
Beyond that into more threats of patent litigation, more ghost lawsuits, more FUD and even more heavy handed lobbying? Here's what I hope to see; Microsoft competing in the market without abusing its monopoly position (Re Java, flash, pdf ...).
Most of us get Microsoft loud and clear, how strange that you do not.
I'll have to watch the popes speech so I can laugh at the hypocrisy.
That's what I mean, you don't change the de-facto file format of a monopoly by supporting it.
+1
I hope they don't support .doc or blob-in-XML. That would really dint Microsoft format lock-in, even with a moderate user base.
Guilty, I use pine and miss or ignore delivery notices. Not just if I'm away from my desk, also if I have the (xfce) terminal minimized or I'm working in an alternate tab.
Admittedly, I'm not the typical user; I'd prefer to use telnet than a so-called 'modern client'.
The issue appears to be that a dump of the servers physical RAM would contain connected IP addresses. Removing the addresses from a RAM dump would be much more complex than removing or obscuring such data in a system log file. TFA is gibberish.
Anything below res.rr.com or adsl.tpnet.pl [east|dsl-w|fios].verizon.net (for example) are residential dynamic IP allocations.
And they can expect to have mail rejected until they find an admin who has enough of a clue to comply with widely praticed receiver policies.
Which is wrong according to RFC2821:
HTH.- Relay through your providers smarthost
- Get a static IP
- Get a VPS and relay through that
It sucks much less than expecting receivers to accept spam.If you're running an MTA on a cheap connection you need to use your ISP's smarthost, mail that appears to come from dynamic addresses is increasingly rejected due to zombies.
Matching forward & reverse DNS (and sometimes helo) is an additional requirement for delivery to certain servers.