Have you ever try to run 2 instances of qmail on one machine for example?
I do this all of the time -- two instance, one "outward facing" one "inward facing", with different patch sets, configurations, and roots --/var/public/qmail/var/private/qmail.
Of course, this mandates having two source trees, each with their own "conf-*" files.
qmail is very rigid and unfriendly to make configuration tricks and connections to anything not usual.
I agree 100%. But I consider that to be a feature.
IMHO, the whole point of qmail (of anything DJB-ish) is to do one thing, do it well, and do it correctly, where correctly means following the RFC, but erring on the side of security and reliability.
Even qmail wouldn't help you in this instance. Any MTA would relay the email through to sendmail.
True. Any MTA that does not do header sanitizing can relay the email through to a vulnerable MTA.
In fact, if you have to have vulnerable sendmail servers running on the "inside" of your enterprise, then running the patched version of Sendmail is "safer" (for certain definitions of "safe") than running qmail, as the patch will "sanitize" incoming mail, removing exploit code:)
Given more details about the exact nature of the exploit, it might be possible to add an additional filter layer to qmail to find and remove the headers that allow the exploit, similar to how virus scanning is commonly implemented on qmail systems?
QMail is fine for a four- or five-user machine, but the installations who currently require Sendmail's power for their mail service needs would likely be happier with Postfix [postfix.org]. It's far more powerful than QMail, while still being easy to set up and use.
Please define "poweful". Are you saying that Sendmail and Postfix inherently offer more options to do unusual routing and rewriting, or that they are more capable of routing a high volume of messages?
Look, how long have we known that running a mail system as root is dangerous, stupid, unnecessary, and avoidable?
Great, so instead of getting root instantly with a single exploit, I get a shell as a non-privileged user, and have to waste another five minutes pulling over a platform-specific exploit to leverage that access to get root.
Why not take the SecureOS approach, and run the SMTP listener in a restricted capabilities role, where all your SMTPd can do is "accept()" TCP sessions on port 25, request DNS lookups, and queue messages to disk?
Most of my machines are on a non-capability-enabled OS, so I run qmail-smtpd in a chroot environment as a non-root UID. I've tried to take the same approach with Sendmail, but it requires considerably more effort and more system resources (launching new 'sendmail' instances from tcpserver is one culprit).
I'm on hold with Cisco now, but it appears that the exploit code would make it past the PIX "protocol fixup" for SMTP. Not that I expect "fixup" on a PIX to offer much protection.
However, there are a number of SMTP proxy applications which do "deeper" checking of the message, and which would serve to protect vulnerable servers. Most of these are expensive, and slow.
Realistically, my solution for my servers is as follows:
Upgrade sendmail to the latest release.
Make configuration changes to run sendmail as a non-root user.
Investigate running sendmail 'chroot'.
My problem right now is that the company-accepted standard for spam filtering is milter based, and can only run under Sendmail. If I "hide" the sendmail listener behind another MTA that directly faces the Internet, then my spam filter is ineffective, as I would lose all of the benefit of being able to reject senders and messages based on the remote IP (RBL) and other checks.
The worst drawback of putting the anti-spam Sendmail filter "inside" is that since the message has already been accepted by one of our mail servers, if the spam filter chooses to reject the message, it needs to generate and deliver a "bounce" message, just in case the reject was a "false-positive", to notify the sender.
If the spam filter is on the outermost edge and can talk directly to the sending host, it can return a 5xx "reject" SMTP result code, and it's up to the sending host to generate and deliver the bounce.
Great. The week they make me replace all of my quick little qmail relays with Sendmail, out comes a new vulnerability.
If only I could find a sweet little qmail patch to clean up the exploit code, perhaps I can convince management to let me bring back Qmail as a front-end processor to protect Sendmail.
My credit history is a long run of usually breaking even (and sometimes not), and a few years of decent income and fixing past debts.
You realize that this should actually make you look MORE like an "average american citizen", thus reducing your "terrorist quotient" and making you less likely to be flagged?
The government is looking for people who stand out as unusual, lack a long credit history, or show a sudden change in their banking and purchasing patterns.
I'd almost guarantee that I'll flag as yellow or red if I'm going on vacation.
And I'd almost guarantee that you won't. You're might think you are unusual, but as far as the government computers are concerned, you're like thousands of other citizens out there.
With your history, you might have a difficult time getting a car loan, but you won't have any trouble getting on an airliner.
We are working on a project called "Stations of the cross".
I have several domain names that appear on many of the "million address" CDs and other popular spam lists, but which longer any legitimate recipients/users.
We are also working on obtaining access to true "realtime" RBL lists of currently abused open relay servers. Assistance would be appreciated.
The core of "stations of the cross" is a custom DNS server.
This server is authoritative for these oft-spammed domains, and each time a request is made for an MX record, it returns (with a short TTL) a unique randomly generated list of MXes, each address on the list being a known open relay.
So when a spammer or relay first goes to deliver a message, the system will select an open relay off the list of MXes, and hands off the message to that host. Being an open relay, the host accepts the message for my domain, then goes to do a DNS lookup for the MX record. The relay receives a (different) list of other open relays...
Usually, you can get a message to traverse a dozen or more open relays (most sendmail systems default to a maximum "hop count" of 25), after which the message will bounce.
Since the only traffic my server has to deal with is DNS queries and responses, this is very low-overhead for me, but depending on the size of the spammail, very high overhead for the open relay servers.
We are still working on the next generation of ChuckMail, code-named "ChuckieMail".
This slowly replies to the spammer to hold open the connection, meanwhile it launches assorted scanning and attack tools against the originating IP...
The current version is quite primitive -- when it sees a new connection, it runs 'atq' to check if a job is pending, and if not, uses "sudo nmap -og -O" to determine the remote OS, then "at" to launch the appropriate attacks based on OS and open services.
qmail-spamthrottle is a patch to qmail which I have found quite helpful in fending off the high-volume spammers, particularly the "dictionary attack" type of spam run.
In a "dictionary attack", the spam sending software tries every likely recipient, from aabraham to zzebra. Usually they are looking more to generate a list of valid email addresses (these sell for a premium) than to actually deliver spam.
This causes a problem for qmail, as the default behavior is to accept any RCPT TO, then generate a bounce when the local delivery agent realizes the users does not actually exist.
What would you request of legitimate senders of high-volume commercial email to make your job easier?
The question:
How can a legitimate "secure confirmed double-opt-in" mailing list operator avoid getting labeled as a spammer?
Currently, a company that follows all of the "guidelines" and does everything right, still stands a good chance of getting listed on SPAMCOP and other RBL lists based on a handful of complaints from clueless customers.
BCDE.COM maintains an nation-wide network of high-volume web sites. Access to the most basic site features is free, but all value-added features require that the user register -- The registration page includes very clear notice that that the "cost" of registration, of access to advanced features, is that the user will receive marketing email from BCDE.COM.
If you choose to "unregister", BCDE.COM will stop sending you email, and you will no longer be able to access the advanced site features.
Filling out the form on the site is just step one -- based on the form, an email is sent to the email address supplied, re-iterating the terms on the form, and providing a URL to "confirm" opt-in. The URL includes a secure hash to prevent spoofed confirmations. Once an address has been sent a registration request, it cannot be sent another request for a week (to prevent using the form as a flood attack).
Daily, BCDE.COM and their ISP(s) receive complaints from users and from SPAMCOP about the confirmation email, about the marketing email, about the "spamvertised" sites hosted at A.BCDE.COM which are promoted in the marketing email.
99.999% of the user base has no problem with this business model, and would prefer this approach to actually paying a subsciption fee for access to the "value add" site features.
How can an ISP known that a sending site that their customers complain about, or a customer that other ISPs complain about, is a legitimate business that is following all the "rules"?
What kind of strategies have you seen work. For instance, in particularly bad instances I'm prone to send an e-mail to spam@isp.net, abuse@isp.net, or admin@isp.net, but usually never even get a response. Is there a better thing to do?
None of those addresses deliver to a human-monitored email address on most of the domains I run. Usually, the only address you can always assume will exist at all is 'postmaster@isp.net', and the mail volume to that address is usually so high that it's easy for one message to get lost in the shuffle.
Many (most) responsible large ISPs have a single preferred contact for abuse (SPAM) complaints. Many domains choose to register their preferred abuse contact at www.abuse.net.
Filing and pursuing a lawsuit costs big buck$$$
on
Kevin Mitnick Answers
·
· Score: 1
Plus, correct me if I'm wrong, but as a convicted criminal, isn't he not allowed to benefit monetarily from his crimes? So even if he did manage to sue Markoff, the gov't would get the money, not him.
Interesting question.
I'd assume that "suing Markoff" would be interpreted as benefiting from Markoff's crimes, not Mitnick's...
For example, If you are arrested, are beat up by a cop, and are then convicted of the original crime, that doesn't preclude you from suing the cop and the police department for their unlawful actions.
RFC 821 shows in an example "550" may mean "Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access]" and "552" can mean "Requested mail action aborted: exceeded storage allocation".
Examination of
RFC821 and RFC2505 shows that any 55x error is (paraphrase) a permanent negative result code indicating that the receiving system cannot accept the message.
The third digit allows for fine gradation of replies, and "552" is a common return code from a spam filter.
This is a design decision -- in many cases, you don't want your anti-spam filter to return a result that could be interpreted to mean:
"What you just sent me triggered a threshold limit, if you take out some exclamation points and only mention viagra once, I might let it through next time"
We've been talking with the Open Group on a couple of different approaches to implement the concept of "trusted servers" for SMTP.
One approach would be to use TLS with certificates signed by trusted anti-spam certification agents, and give TLS mail priority over plain-old cleartext SMTP.
Basically, nearly all current anti-spam techniques (one exception being whitelisting) work on the concept of "marking down" certain messages or sending hosts as being less trusted. Our goal is to use TLS and other approaches to apply the concept of "elevating trust", of elevating the trust level of certain hosts and messages.
I want the opposide: A cell phone station that plugs into my land line, so I can use my mobile phone on land line rates. (Cell phone rates here are criminal!) I can't see any technical reason why this wouldn't work.
Motorola actually had this back in the early 90's. Basically, they just built in the internals of a cordless phone into a standard cell phone. The prototypes I saw looked exactly like the original "flip phone", except the case was black instead of grey.
You'd set up a base station at home that looks and functions exactly like any portable wireless phone base, and when you are at home, your "cell phone" would just be another extension of your home phone line.
The same Motorola facility also had a way-cool "microcell" attached to the local office PBX, so your cell phone would work just like your desk phone when on the local Motorola campus.
There are medium range (10-15 foot) taser guns now that can KO an intruder.
True, such devices exist.
False, they are not nearly as effective as you might hope, or all law enforcement officers would trade in their sidearms for "Less than lethal" tasers.
All of the concealed carry permit holders I know also carry a pocketknife, MACE (pepper spray), and a cell phone.
No trajectory/windspeed issues
The taser fires a barbed projectile with wires attached. All of the same trajectory/windspeed issues, plus worries about a dead battery. The only issue avoided is the problem of "overpenetration" and innocent bystanders.
you don't have any chance in heck of a dead child - give or take maybe.001%, say if you shot someone who has a pacemaker (but I'm sure a bullet is just as harmful to them).
The problem is, they are called "less than lethal" devices for a reason.
Any chemical/electrical/restraint/incapacitation device that will work reliably against an enraged knife-wielding 240-lb weightlifiting meth-head is going to have a high probality of killing a child or the elderly. Any device that "doesn't have a chance in heck" of killing a child, is going to be less than fully effective against the aformentioned enraged meth addict who is singlemindly trying his best to gut you while you attempt to subdue him with your little toy taser.
So why aren't we looking more into these technologies?
Who says we are not? However, firearms are simple mechanical devices based on centuries old technology. That level of reliability and effectiveness is difficult to beat when you are being charged by a big heavy adult male criminal wielding a big sharp knife (even older technology).
Switzerland and Norway have very high firearms ownership rates, and very low firearm murder rates.
Doesn't seem like firearms make for a safer country.
Another bogus argument. Nobody can say what the murder rate in the US would be if there were no firearms. However, if you compare the US homicide rate excluding gunshot deaths, it is still higher than the total murder rate in most other western nations.
Take the guns away, and Americans would still murder one another at a higher rate than other "civilized" countries.
I feel safer when travelling/living in Canada or in Europe than when travelling/living in the US.
More fallacies. The culture and the ethnic makeup of the USA all differ significantly from the monochromatic culture of Canada and Europe.
Funny thing, the violent crime rate in affluent ethnically monolithic (white) US suburbs is strikingly similar to the rates in similarly affluent European towns.
Are there better sources for researching dates?
on
Googling For Dates?
·
· Score: 2
Google won't find anything beyond the charade an individual has created on a home page...or makes up in a blog, for that matter.
Usefulness depends on the person you are googling.
The 'pageranking' mechanism makes the charade harder to conduct.
Google works pretty well on me (not that anybody ever wants to "research" me), even finding some web pages from the mid-nineties that I'd rather forget:)
OTOH, the various "online investigation services" and even the full background check used for "pre-employment screening" only find one small aspect of a person, and mostly info you'd want to have before hiring or marrying somebody, but probably not the stuff you really need to know before the third date.
Remember when they declared PGP to be a munition and banned it's export??
They didn't "declare PGP to be a munition". The laws have clearly stated that cryptographic technology is munitions. When the laws were written, most encryption "technology" was special-purpose hardware, and the laws made sense.
When PGP was invented, the laws were pre-existing. Zimmerman et all went out of their way to challenge these laws and their application of sofware.
What do you think will happen when you begin to send PGP encrypted email to/from your friends?
Why would ANYONE want to hide anything?
I've been exchanging encrypted email with friends and co-workers for many, many years now. Nothing "has happened to us".
Face it, the government really doesn't give a damn what the average American citizen does or thinks, or what the citizens communicate to other citizens.
Some big corporations care, but only to the extent that your actions impede their efforts to turn a profit.
An OpenBSD database of "known good" signatures would have to be SHA-1:)
Many (most?) of the OpenBSD users I know have custom environments, the first thing they do with a new release is 'make world', resulting in all new binaries with checksum signatures unique to their environment.
I've been privately building up a database of "known bad", MD5/SHA1 signatures from known examples of trojaned binaries, worm DLLs, and the like.
sdscsyslogd-1.0.0 RC4 does not compile on Solaris 8, nor on FreeBSD.
The 'configure' script does not report any problems, and correctly detects the operating system. FreeBSD has some problems with the 'sed' substitutions for "include/const.h".
Using GCC on either platform, the compile pukes in "src/util/netaddr.h". It appears that SDSC syslogd can only successfully compile on Linux, due to use of Linux-specific socket structure declarations in this file?
gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I../../src -g -Wall -Wno-inl ine -Wstrict-prototypes -O2 -pedantic -c `test -f config.c || echo './'`config. c In file included from../../src/message/message.h:25, from../../src/outputmod/outputmod.h:23, from../../src/include/chaninfo.h:23, from config.c:19: ../../src/util/netaddr.h:98: field `sa' has incomplete type ../../src/util/netaddr.h:99: warning: ISO C doesn't support unnamed structs/unio ns ../../src/util/netaddr.h:99: warning: no semicolon at end of struct or union ../../src/util/netaddr.h:99: parse error before numeric constant ../../src/util/netaddr.h:100: warning: built-in function `sin' declared as non-f unction ../../src/util/netaddr.h:102: parse error before '}' token ../../src/util/netaddr.h:102: warning: ISO C does not allow extra `;' outside of a function In file included from../../src/include/chaninfo.h:23, from config.c:19: ../../src/outputmod/outputmod.h:75: field `sendTo' has incomplete type ../../src/outputmod/outputmod.h:82: confused by earlier errors, bailing out
After all, if one person posts the times of the programs that they want to record, then everyone can have automated recording
like Tivo.
Any volunteers for this open source database?
Yeah, but do you trust your fellow geeks to provide correct cable lineups and accurate show listings?
The last thing I need is to sit down to watch the latest episode of "Sopranos" and instead see the opening credits of "Barney and Friends". Or vice-versa.
I'm tempted to build something similar (with hotswap drives) to handle storing surveillance camera output on a disk, and perhaps feeding selected frames (based on motion detection) offsite.
Basically, a video capture card, a minimal OS, and two dedicated storage drives capable of holding 24 hours of good quality B&W video each.
If something interesting happened yesterday, I can swap out the quiescient "yesterday" drive for a fresh disk (hotswap) and save/copy/analyse the old data, without having to mess with the running system or the currently active drive that is being used to save today's footage.
Seems simple enough, shouldn't even really need to have an OS, just enough smarts to capture frames and write them to disk. I've heard of people converting old TiVo units to this purpose, but no dedicated hardware that fits my description.
I can't think of any reason to prefer PGP to GnuPG, and there are some reasons (already pointed out) for preferring GnuPG to PGP.
So, overall, I can't why anyone would use PGP.
You might not see any reason to prefer PGP to GnuPG, but there are many reasons why a business user my prefer to deploy PGP:
Technical support.
Well-designed GUI interfaces.
Directory integration with NDS, LDAP, AD, etc.
Key Escrow and additional decryption key (ADK) support.
Includes a non-intrusive and reliable MS-Outlook (not just OE) plugin.
Yes, I know the whole idea of key escrow and ADK are seen as horrible invasions of privacy by personal users, however, these features have a valid business purpose in a corporate enterprise deployment and are mandatory for certain types of business communication.
Actually, AOL's broadband service is known to have issues with a number of "non-standard" services and protocols.
I know from dealing with support calls from my users that many VPN clients cannot function on AOL Broadband. Given that Xbox Live operates much like a VPN, I can see how they would encounter similar problems.
For my VPN users with AOL broadband, we have had no success getting any assistance from their technical support, and the only solution has been to suggest to the user that they switch providers...
Slashdot Mirror
I do this all of the time -- two instance, one "outward facing" one "inward facing", with different patch sets, configurations, and roots -- /var/public/qmail /var/private/qmail.
Of course, this mandates having two source trees, each with their own "conf-*" files.
I agree 100%. But I consider that to be a feature.
IMHO, the whole point of qmail (of anything DJB-ish) is to do one thing, do it well, and do it correctly, where correctly means following the RFC, but erring on the side of security and reliability.
True. Any MTA that does not do header sanitizing can relay the email through to a vulnerable MTA.
In fact, if you have to have vulnerable sendmail servers running on the "inside" of your enterprise, then running the patched version of Sendmail is "safer" (for certain definitions of "safe") than running qmail, as the patch will "sanitize" incoming mail, removing exploit code :)
Given more details about the exact nature of the exploit, it might be possible to add an additional filter layer to qmail to find and remove the headers that allow the exploit, similar to how virus scanning is commonly implemented on qmail systems?
Please define "poweful". Are you saying that Sendmail and Postfix inherently offer more options to do unusual routing and rewriting, or that they are more capable of routing a high volume of messages?
Why not take the SecureOS approach, and run the SMTP listener in a restricted capabilities role, where all your SMTPd can do is "accept()" TCP sessions on port 25, request DNS lookups, and queue messages to disk?
Most of my machines are on a non-capability-enabled OS, so I run qmail-smtpd in a chroot environment as a non-root UID. I've tried to take the same approach with Sendmail, but it requires considerably more effort and more system resources (launching new 'sendmail' instances from tcpserver is one culprit).
However, there are a number of SMTP proxy applications which do "deeper" checking of the message, and which would serve to protect vulnerable servers. Most of these are expensive, and slow.
Realistically, my solution for my servers is as follows:
My problem right now is that the company-accepted standard for spam filtering is milter based, and can only run under Sendmail. If I "hide" the sendmail listener behind another MTA that directly faces the Internet, then my spam filter is ineffective, as I would lose all of the benefit of being able to reject senders and messages based on the remote IP (RBL) and other checks.
The worst drawback of putting the anti-spam Sendmail filter "inside" is that since the message has already been accepted by one of our mail servers, if the spam filter chooses to reject the message, it needs to generate and deliver a "bounce" message, just in case the reject was a "false-positive", to notify the sender.
If the spam filter is on the outermost edge and can talk directly to the sending host, it can return a 5xx "reject" SMTP result code, and it's up to the sending host to generate and deliver the bounce.
If only I could find a sweet little qmail patch to clean up the exploit code, perhaps I can convince management to let me bring back Qmail as a front-end processor to protect Sendmail.
Oh well, it's off to patch I go.
You realize that this should actually make you look MORE like an "average american citizen", thus reducing your "terrorist quotient" and making you less likely to be flagged?
The government is looking for people who stand out as unusual, lack a long credit history, or show a sudden change in their banking and purchasing patterns.
And I'd almost guarantee that you won't. You're might think you are unusual, but as far as the government computers are concerned, you're like thousands of other citizens out there.With your history, you might have a difficult time getting a car loan, but you won't have any trouble getting on an airliner.
I have several domain names that appear on many of the "million address" CDs and other popular spam lists, but which longer any legitimate recipients/users.
We are also working on obtaining access to true "realtime" RBL lists of currently abused open relay servers. Assistance would be appreciated.
The core of "stations of the cross" is a custom DNS server. This server is authoritative for these oft-spammed domains, and each time a request is made for an MX record, it returns (with a short TTL) a unique randomly generated list of MXes, each address on the list being a known open relay.
So when a spammer or relay first goes to deliver a message, the system will select an open relay off the list of MXes, and hands off the message to that host. Being an open relay, the host accepts the message for my domain, then goes to do a DNS lookup for the MX record. The relay receives a (different) list of other open relays...
Usually, you can get a message to traverse a dozen or more open relays (most sendmail systems default to a maximum "hop count" of 25), after which the message will bounce.
Since the only traffic my server has to deal with is DNS queries and responses, this is very low-overhead for me, but depending on the size of the spammail, very high overhead for the open relay servers.
This slowly replies to the spammer to hold open the connection, meanwhile it launches assorted scanning and attack tools against the originating IP...
The current version is quite primitive -- when it sees a new connection, it runs 'atq' to check if a job is pending, and if not, uses "sudo nmap -og -O" to determine the remote OS, then "at" to launch the appropriate attacks based on OS and open services.
qmail-spamthrottle is a patch to qmail which I have found quite helpful in fending off the high-volume spammers, particularly the "dictionary attack" type of spam run.
In a "dictionary attack", the spam sending software tries every likely recipient, from aabraham to zzebra. Usually they are looking more to generate a list of valid email addresses (these sell for a premium) than to actually deliver spam.
This causes a problem for qmail, as the default behavior is to accept any RCPT TO, then generate a bounce when the local delivery agent realizes the users does not actually exist.
The question:
Currently, a company that follows all of the "guidelines" and does everything right, still stands a good chance of getting listed on SPAMCOP and other RBL lists based on a handful of complaints from clueless customers.
BCDE.COM maintains an nation-wide network of high-volume web sites. Access to the most basic site features is free, but all value-added features require that the user register -- The registration page includes very clear notice that that the "cost" of registration, of access to advanced features, is that the user will receive marketing email from BCDE.COM.
If you choose to "unregister", BCDE.COM will stop sending you email, and you will no longer be able to access the advanced site features.
Filling out the form on the site is just step one -- based on the form, an email is sent to the email address supplied, re-iterating the terms on the form, and providing a URL to "confirm" opt-in. The URL includes a secure hash to prevent spoofed confirmations. Once an address has been sent a registration request, it cannot be sent another request for a week (to prevent using the form as a flood attack).
Daily, BCDE.COM and their ISP(s) receive complaints from users and from SPAMCOP about the confirmation email, about the marketing email, about the "spamvertised" sites hosted at A.BCDE.COM which are promoted in the marketing email.
99.999% of the user base has no problem with this business model, and would prefer this approach to actually paying a subsciption fee for access to the "value add" site features.
How can an ISP known that a sending site that their customers complain about, or a customer that other ISPs complain about, is a legitimate business that is following all the "rules"?
None of those addresses deliver to a human-monitored email address on most of the domains I run. Usually, the only address you can always assume will exist at all is 'postmaster@isp.net', and the mail volume to that address is usually so high that it's easy for one message to get lost in the shuffle.
One suggestion -- try the abuse contact database at The Network Abuse Clearinghouse.
Many (most) responsible large ISPs have a single preferred contact for abuse (SPAM) complaints. Many domains choose to register their preferred abuse contact at www.abuse.net.
Interesting question.
I'd assume that "suing Markoff" would be interpreted as benefiting from Markoff's crimes, not Mitnick's...
For example, If you are arrested, are beat up by a cop, and are then convicted of the original crime, that doesn't preclude you from suing the cop and the police department for their unlawful actions.
Examination of RFC821 and RFC2505 shows that any 55x error is (paraphrase) a permanent negative result code indicating that the receiving system cannot accept the message.
The third digit allows for fine gradation of replies, and "552" is a common return code from a spam filter.
This is a design decision -- in many cases, you don't want your anti-spam filter to return a result that could be interpreted to mean:
One approach would be to use TLS with certificates signed by trusted anti-spam certification agents, and give TLS mail priority over plain-old cleartext SMTP.
Basically, nearly all current anti-spam techniques (one exception being whitelisting) work on the concept of "marking down" certain messages or sending hosts as being less trusted. Our goal is to use TLS and other approaches to apply the concept of "elevating trust", of elevating the trust level of certain hosts and messages.
You'd set up a base station at home that looks and functions exactly like any portable wireless phone base, and when you are at home, your "cell phone" would just be another extension of your home phone line.
The same Motorola facility also had a way-cool "microcell" attached to the local office PBX, so your cell phone would work just like your desk phone when on the local Motorola campus.
False, they are not nearly as effective as you might hope, or all law enforcement officers would trade in their sidearms for "Less than lethal" tasers.
All of the concealed carry permit holders I know also carry a pocketknife, MACE (pepper spray), and a cell phone.
The taser fires a barbed projectile with wires attached. All of the same trajectory/windspeed issues, plus worries about a dead battery. The only issue avoided is the problem of "overpenetration" and innocent bystanders. The problem is, they are called "less than lethal" devices for a reason.Any chemical/electrical/restraint/incapacitation device that will work reliably against an enraged knife-wielding 240-lb weightlifiting meth-head is going to have a high probality of killing a child or the elderly. Any device that "doesn't have a chance in heck" of killing a child, is going to be less than fully effective against the aformentioned enraged meth addict who is singlemindly trying his best to gut you while you attempt to subdue him with your little toy taser.
Who says we are not? However, firearms are simple mechanical devices based on centuries old technology. That level of reliability and effectiveness is difficult to beat when you are being charged by a big heavy adult male criminal wielding a big sharp knife (even older technology).Switzerland and Norway have very high firearms ownership rates, and very low firearm murder rates.
Another bogus argument. Nobody can say what the murder rate in the US would be if there were no firearms. However, if you compare the US homicide rate excluding gunshot deaths, it is still higher than the total murder rate in most other western nations.Take the guns away, and Americans would still murder one another at a higher rate than other "civilized" countries.
More fallacies. The culture and the ethnic makeup of the USA all differ significantly from the monochromatic culture of Canada and Europe.Funny thing, the violent crime rate in affluent ethnically monolithic (white) US suburbs is strikingly similar to the rates in similarly affluent European towns.
Google works pretty well on me (not that anybody ever wants to "research" me), even finding some web pages from the mid-nineties that I'd rather forget :)
OTOH, the various "online investigation services" and even the full background check used for "pre-employment screening" only find one small aspect of a person, and mostly info you'd want to have before hiring or marrying somebody, but probably not the stuff you really need to know before the third date.
When PGP was invented, the laws were pre-existing. Zimmerman et all went out of their way to challenge these laws and their application of sofware.
I've been exchanging encrypted email with friends and co-workers for many, many years now. Nothing "has happened to us".Face it, the government really doesn't give a damn what the average American citizen does or thinks, or what the citizens communicate to other citizens.
Some big corporations care, but only to the extent that your actions impede their efforts to turn a profit.
Many (most?) of the OpenBSD users I know have custom environments, the first thing they do with a new release is 'make world', resulting in all new binaries with checksum signatures unique to their environment.
I've been privately building up a database of "known bad", MD5/SHA1 signatures from known examples of trojaned binaries, worm DLLs, and the like.
sdscsyslogd-1.0.0 RC4 does not compile on Solaris 8, nor on FreeBSD.
../../src/message/message.h:25, ../../src/outputmod/outputmod.h:23, ../../src/include/chaninfo.h:23, ../../src/include/chaninfo.h:23,
The 'configure' script does not report any problems, and correctly detects the operating system. FreeBSD has some problems with the 'sed' substitutions for "include/const.h".
Using GCC on either platform, the compile pukes in "src/util/netaddr.h". It appears that SDSC syslogd can only successfully compile on Linux, due to use of Linux-specific socket structure declarations in this file?
gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I../../src -g -Wall -Wno-inl
ine -Wstrict-prototypes -O2 -pedantic -c `test -f config.c || echo './'`config.
c
In file included from
from
from
from config.c:19:
../../src/util/netaddr.h:98: field `sa' has incomplete type
../../src/util/netaddr.h:99: warning: ISO C doesn't support unnamed structs/unio
ns
../../src/util/netaddr.h:99: warning: no semicolon at end of struct or union
../../src/util/netaddr.h:99: parse error before numeric constant
../../src/util/netaddr.h:100: warning: built-in function `sin' declared as non-f
unction
../../src/util/netaddr.h:102: parse error before '}' token
../../src/util/netaddr.h:102: warning: ISO C does not allow extra `;' outside of
a function
In file included from
from config.c:19:
../../src/outputmod/outputmod.h:75: field `sendTo' has incomplete type
../../src/outputmod/outputmod.h:82: confused by earlier errors, bailing out
The last thing I need is to sit down to watch the latest episode of "Sopranos" and instead see the opening credits of "Barney and Friends". Or vice-versa.
Basically, a video capture card, a minimal OS, and two dedicated storage drives capable of holding 24 hours of good quality B&W video each.
If something interesting happened yesterday, I can swap out the quiescient "yesterday" drive for a fresh disk (hotswap) and save/copy/analyse the old data, without having to mess with the running system or the currently active drive that is being used to save today's footage.
Seems simple enough, shouldn't even really need to have an OS, just enough smarts to capture frames and write them to disk. I've heard of people converting old TiVo units to this purpose, but no dedicated hardware that fits my description.
Yes, I know the whole idea of key escrow and ADK are seen as horrible invasions of privacy by personal users, however, these features have a valid business purpose in a corporate enterprise deployment and are mandatory for certain types of business communication.
I know from dealing with support calls from my users that many VPN clients cannot function on AOL Broadband. Given that Xbox Live operates much like a VPN, I can see how they would encounter similar problems.
For my VPN users with AOL broadband, we have had no success getting any assistance from their technical support, and the only solution has been to suggest to the user that they switch providers...