Well, several things. don't confuse "filtering at the MX" with rejecting at the MX. Filtering may mean quarantining. An MX-located filter will typically reject the majority of spam, but will quarantine the rest.
Because filters vary, it's basically impossible to tell how your filter does it by simply looking at the quarantine.
I disagree with the implication that client-based spam filters are the most commonly implemented. That's not my experience at all. However, it's true to say that there's a significant number of mailboxes that are protected first by an MX-located filter and later by a client-based filter.
It would be great to solve the botnet problem. In fact, it's pretty easy for ISPs to detect compromised PCs. It would be great if more of them did this. However, ISP margins are predicated on automation and little or no support touch. Remediation and/or support is expensive and will typically eat up much or all the profit from a user subscription.
What? You do understand what a "spam filter" is, don't you?;-)
I know you think you do, but for quite some time now most spam has been filtered at the MX -- and most of that is rejected before the SMTP DATA stage or even before HELO.
And, respectfully, if you don't understand those three bits of jargon, I don't think you should be so dismissive.
DKIM is not an anti-spam technique, at least not directly. We need other pieces of the puzzle before it's useful for fighting spam. See m'blog for more.
Nope. The "Sender ID" patent covers the PRA algorithm, not SPF-classic. Yes, you should be aware that some recipients filter based on PRA (e.g. Hotmail/Live), but no Microsoft IP is infringed by publishing SPF records or filtering based on such records.
Simplistically, MARID died because it tried to achieve "broad consensus" amongst people who were OK with the PRA IP and those that weren't. Neither side could persuade the other to back down.
Fair comparative testing of spam control technologies is extremely difficult -- by some measures, it's impossible. Because some promising filter techniques rely on examining the real-time behaviour of the sending machine, it proves tricky to provide the exact same stream of email to all the filters at the same time.
For example, some filters attempt to fingerprint the sending machine's operating system -- the idea being that, say, a Windows 98 PC has no business submitting email direct-to-MX.
Before any more of you fire off an outraged e-mail informing me that Vista doesn't run SQL Server, go back and read the above paragraphs again: I'm talking about SQL Server 2005 Express, which is the desktop counterpart of SQL Server - not the server version.
Assume you posted these all at 2 am at night, at 8 the next morning all 30 people get to work and check their emails all at about the same time. Ouch
Well we don't know what mail server they were using, but that would be a problem with some popular servers that don't properly keep single copies of messages sent to multiple recipients CoughExchange5.5Cough. When I worked on OpenMail (now Scalix) this sort of load would have been no problem for a small server with a few thousand users.
It's a question of minimizing the disk I/O -- or more importantly minimizing the amount that the disk heads need to move.
That's just rubbish. Yes there are issues between versions sometimes, but it's just flat wrong to say "In some rare cases, you may succeed with importing simple documents from even earlier versions -- but you will need to spend a long time reformatting everything. MS Office is compatible only with the same version, and even only if both computers have the same default printer installed."
I'm no Microsoft apologist (check out my blog if you don't believe me), but whoever moderated this as Insightful, Informative, or Interesting should think long and hard.
OpenMail is no more. It was licensed to Scalix some time back. Scalix has taken it, given it a rather nice AJAX web client as well as other good things, and is giving it away (see the "Community Edition" on their site).
Slashdot Mirror
YAWN. Wake me up when I can refuel my gasoline car at home, overnight.
Great to see /. still hasn't figured out Unicode :-(
Yeah, and all the land-based animals would literally be drowning...
So what happens if there's a fault and the RSO hits the self-destruct button?
Car batteries fail after a few deep cycles. You need deep-cycle lead-acid batteries, which are much more expensive.
Also, £35 for 100Ah? The typical car battery is less than half that capacity, and retails for more like £50.
Blimey! Look at that! It's Sean Ellis!
And other co-class-of-1987 phrases punctuated with an exclamation mark.
Hello, old chap.
Mod. Parent. Up.
Shame on you for not RingTFA. How am I supposed to eat? ;-)
Richi Jennings, author of TFA here.
I have a couple of leads on the identity of the advertiser; I plan to name&shame once I have enough evidence.
However, as Bill rightly points out in his reply, it's Carbonite that's primarily to blame, for ignoring its own privacy policy.
Legal warning: IANAL, but I understand that freeze distillation is illegal in some jurisdictions.
Sadly, the change you outline is exactly what will be happening later this year. The airlines will be compelled to provide the data to the TSA.
Well, several things. don't confuse "filtering at the MX" with rejecting at the MX. Filtering may mean quarantining. An MX-located filter will typically reject the majority of spam, but will quarantine the rest.
Because filters vary, it's basically impossible to tell how your filter does it by simply looking at the quarantine.
I disagree with the implication that client-based spam filters are the most commonly implemented. That's not my experience at all. However, it's true to say that there's a significant number of mailboxes that are protected first by an MX-located filter and later by a client-based filter.
It would be great to solve the botnet problem. In fact, it's pretty easy for ISPs to detect compromised PCs. It would be great if more of them did this. However, ISP margins are predicated on automation and little or no support touch. Remediation and/or support is expensive and will typically eat up much or all the profit from a user subscription.
Richi Jennings.
What? You do understand what a "spam filter" is, don't you? ;-)
I know you think you do, but for quite some time now most spam has been filtered at the MX -- and most of that is rejected before the SMTP DATA stage or even before HELO.
And, respectfully, if you don't understand those three bits of jargon, I don't think you should be so dismissive.
Richi Jennings
Um, no. Consider that state-of-the-art spam filters reject the vast majority of spam, so it never actually gets sent.
Richi Jennings
ROTFL. Somebody helpfully omitted the phrase, "equivalent to the CO2 emissions of"
Richi Jennings
Hmm, well in my case, that distance would be about 30 ft.
Richi Jennings
Golly, I wish I had some mod points today...
Quite.
DKIM is not an anti-spam technique, at least not directly. We need other pieces of the puzzle before it's useful for fighting spam. See m'blog for more.
Nope. The "Sender ID" patent covers the PRA algorithm, not SPF-classic. Yes, you should be aware that some recipients filter based on PRA (e.g. Hotmail/Live), but no Microsoft IP is infringed by publishing SPF records or filtering based on such records.
Simplistically, MARID died because it tried to achieve "broad consensus" amongst people who were OK with the PRA IP and those that weren't. Neither side could persuade the other to back down.
Quite.
Fair comparative testing of spam control technologies is extremely difficult -- by some measures, it's impossible. Because some promising filter techniques rely on examining the real-time behaviour of the sending machine, it proves tricky to provide the exact same stream of email to all the filters at the same time.
For example, some filters attempt to fingerprint the sending machine's operating system -- the idea being that, say, a Windows 98 PC has no business submitting email direct-to-MX.
More at richij.com
It's a question of minimizing the disk I/O -- or more importantly minimizing the amount that the disk heads need to move.
I'm no Microsoft apologist (check out my blog if you don't believe me), but whoever moderated this as Insightful, Informative, or Interesting should think long and hard.
The document model just doesn't work for sophisticated applications
Not so, as Scalix has shown. Not at all dog slow, and very very interactive.
OpenMail is no more. It was licensed to Scalix some time back. Scalix has taken it, given it a rather nice AJAX web client as well as other good things, and is giving it away (see the "Community Edition" on their site).