RE: Time to check the rate limits on your mail servers
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of J.D. Falk Sent: Thursday, February 03, 2005 4:35 PM To: nanog@merit.edu Subject: Re: Time to check the rate limits on your mail servers
On 02/03/05, "Miller, Mark" <mark.miller@qwest.com> wrote:
How come it is always about controlling the symptoms and not the illness? The vast majority of these "spam drones" are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7.
Upgrading and/or replacing the OS for every Windows user on the planet is an educational issue. Keeping the network viable while you figure out how to do that is an operational issue.
..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home. -M<
On 02/03/05, "Hannigan, Martin" <hannigan@verisign.com> wrote:
Upgrading and/or replacing the OS for every Windows user on the planet is an educational issue. Keeping the network viable while you figure out how to do that is an operational issue.
..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home.
So you educate them as to why it would be a good idea to keep their computer secure. But in the meantime, their machine is spewing garbage -- which, as many have said, is the operational issue at hand. -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk. Adi
On Thu, 3 Feb 2005, Adi Linden wrote:
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating?
that doesn't work if you have more than one email address.
This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk.
auth is sufficient to make email traceable to your own customers.
Adi
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating?
that doesn't work if you have more than one email address.
Wouldn't address resolution take care of that if properly configured? Some implementations allow you to specify what email addresses the user is allowed to send from, that's something that needs to be managed carefully. -GSH
JJ> Date: Thu, 3 Feb 2005 15:41:34 -0800 (PST) JJ> From: Joel Jaeggli JJ> > How about using SMTP AUTH and verifying the envelope MAIL FROM to match JJ> > the actual user authenticating? JJ> JJ> that doesn't work if you have more than one email address. The words "overreaching" and "fallacious" come to mind. JJ> auth is sufficient to make email traceable to your own customers. End users also would appreciate the ability to _know_ a message is not forged. Alas, I doubt much has changed since last October's BCP38 discussions, so perhaps I should not hold my breath. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On Thu, 3 Feb 2005, Edward B. Dreger wrote:
JJ> auth is sufficient to make email traceable to your own customers.
End users also would appreciate the ability to _know_ a message is not forged.
The only way to be sure is via cryptographic signature. Barring that level of immediate traceability, SPF provides a very useful data point to that end (as its *only* purpose is curbing forgery). -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On Fri, 2005-02-04 at 09:53 -0500, Todd Vierling wrote:
On Thu, 3 Feb 2005, Edward B. Dreger wrote:
JJ> auth is sufficient to make email traceable to your own customers.
End users also would appreciate the ability to _know_ a message is not forged.
The only way to be sure is via cryptographic signature. Barring that level of immediate traceability, SPF provides a very useful data point to that end (as its *only* purpose is curbing forgery).
Attempting to detect spam trickled through thousands of compromised systems sent through the ISP's mail servers, SPF does nothing, and could actually damage the reputation of those domains that authorize the provider for their mailbox domain using SPF. These records can be read by the spammers and then exploited. Repairing this reputation could be next to impossible. With respect to forgery, authorization is not authentication. There is no consensus which mailbox-domain is checked, SPF (MAILFROM or HELO), Classic (MAILFROM or Other and HELO), or Sender-ID (PRA), so it is uncertain which mailbox-domain may have been checked for authorization, if any. False assurances could be worse than no assurances. White-listing for forwarded accounts or mailing lists to allow an SPF rule-set bypass means there is no certainty a check was ever made. -Doug
On 02/04/05, Douglas Otis <dotis@mail-abuse.org> wrote:
Attempting to detect spam trickled through thousands of compromised systems sent through the ISP's mail servers, SPF does nothing,
Nor is it purported to. Domain-based authentication schemes are intended to handle an entirely different problem.
and could actually damage the reputation of those domains that authorize the provider for their mailbox domain using SPF. These records can be read by the spammers and then exploited. Repairing this reputation could be next to impossible.
You touch on some basic realities here: 1. spam coming out of your network will affect your reputation. 2. spam coming out of your own mail machines will affect your reputation even more immediately. Neither are affected by any of the domain authentication schemes currently in play (SPF, SenderID, DomainKeys, etc.) The spam itself may include forgeries, but that's a different issue. -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
On Sat, 2005-02-05 at 09:39 -0800, J.D. Falk wrote:
On 02/04/05, Douglas Otis <dotis@mail-abuse.org> wrote:
SPF does nothing, and could actually damage the reputation of those domains that authorize the provider for their mailbox domain using SPF. These records can be read by the spammers and then exploited. Repairing this reputation could be next to impossible.
You touch on some basic realities here:
1. spam coming out of your network will affect your reputation.
2. spam coming out of your own mail machines will affect your reputation even more immediately.
Neither are affected by any of the domain authentication schemes currently in play (SPF, SenderID, DomainKeys, etc.) The spam itself may include forgeries, but that's a different issue.
SPF and Sender ID do not indicate who administers the machine. It is important to understand that SPF and Sender-ID entities are completely unrelated to server administration or ownership. Authentication, and not just authorization, is required to prevent forgeries. Yahoo's DomainKeys or Cisco's IIM could be enhanced to include a unique account identifier, perhaps directly derived from the access server, which would enable a means to directly confront this threat. DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed. Reputation is required to abate spam. SPF and Sender-ID CAN NOT support reputation because they REALLY CAN NOT prevent forgeries. There isn't even a consensus which entity should be checked with these schemes. -Doug
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed.
Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day? -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
On Sat, 5 Feb 2005, J.D. Falk wrote:
DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed.
Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day?
Isn't that called S/MIME and PGP? It hasn't scaled yet. I've received two S/MIME messages in my life, and a few more PGP messages. A problem is if the computer has been compromised, its likely the authentication information stored on the computer has also been compromised or will be when the user starts typing any missing information. Very few consumer-grade computers have advanced security devices installed. As I keep saying, a secure computer rarely DDOSes, spams or sends viruses. And when they do, its much easier to whack the owner. So how do we keep computers secure and fix the insecure ones?
On Sat, 2005-02-05 at 19:10, J.D. Falk wrote:
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed.
Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day?
Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale. -Doug
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
On Sat, 2005-02-05 at 19:10, J.D. Falk wrote:
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed.
Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day?
Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale.
Heh, you don't need to convince me that DomainKeys is a good idea. I just don't see how you're jumping from the issue of end-user authentication (which is not free from zombies, as others have explained already) to domain-level reputation. Where's the link? If you're talking about adding user-level signatures to something like DomainKeys (which we already have in s/mime), how do you propose to scale that to interact with the reputation determination for billions of messages per day? -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
On Sun, 2005-02-06 at 09:41, J.D. Falk wrote:
On 02/05/05, Douglas Otis <dotis@mail-abuse.org> wrote:
Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale.
Heh, you don't need to convince me that DomainKeys is a good idea. I just don't see how you're jumping from the issue of end-user authentication (which is not free from zombies, as others have explained already) to domain-level reputation. Where's the link? If you're talking about adding user-level signatures to something like DomainKeys (which we already have in s/mime), how do you propose to scale that to interact with the reputation determination for billions of messages per day?
Take something like the DomainKey, and add an opaque identifier to the signature, derived from a user authentication process. This could be from an access server or a verification that resolves a dynamic address assignment to a persistent identifier. DomainKeys can scale. Adding an optional opaque persistent identifier will also scale, as this information is already collected. The reason for adding this identifier is two fold. One, it can be used to guard against replay attacks. Two, to assist in identifying compromised systems. Blocking by the provider scales; the identifier makes it easier to locate the problem via abuse reports. The signature ensurers that the provider can accurately attribute abuse. In addition, the provider should want to include the identifiers to protect their reputation in the face of a replay attack, which they can not block otherwise. By convention, the provider can publish their own identifier blackhole-listing just to address the replay attack, whereas known compromised systems should be blocked outright. The signature protects the provider from possible blocking and blackhole-listing errors, as the users will not believe they were the cause of their own problem. -Doug
TV> Date: Fri, 4 Feb 2005 09:53:07 -0500 (EST) TV> From: Todd Vierling TV> The only way to be sure is via cryptographic signature. Barring that level False. You imply that a crypto signature is a perfect guarantee, and that nothing else can provide equal assurance. TV> of immediate traceability, SPF provides a very useful data point to that TV> end (as its *only* purpose is curbing forgery). SPF says "mail from this domain should only come from these MXes". It doesn't stop someone from forging a random @domain.tld address from an SPF-blessed Everquick MX. Now, let's say it's known that Everquick MXes authenticate users and only allow whitelisted "From: " email addresses. Step 1: SPF [or similar/better] confirms that the MX is allowed to send email on behalf of the claimed sender address. Discard message if it comes from a bogus MX. Step 2: The MX confirms that the user was authorized to use the claimed sender address. The message would never have been transmitted had the user not authenticated with the trusted MX. Please explain how the "trust chain" does not verify the sending user. "Malware will steal username/password" is not a valid answer, as the same can apply equally to crypto keys. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Please explain how the "trust chain" does not verify the sending user. "Malware will steal username/password" is not a valid answer, as the same can apply equally to crypto keys.
Now that we have established a "trust chain" an verify the sending user we have an easy way (shuffling through mail logs is by no means easy in my books) for support people to address SPAM complaints. Even better, due to the verified sender we can now send bounce messages and notifications to originator. Sure, it'll result in "I never send this..." type support calls but support can now say "Sure, your computer did behind your back...". Adi
AL> Date: Sat, 5 Feb 2005 13:11:11 -0600 AL> From: Adi Linden AL> Now that we have established a "trust chain" an verify the sending user we AL> have an easy way (shuffling through mail logs is by no means easy in my AL> books) for support people to address SPAM complaints. Note that I'm ignoring SMTP proxies that may munge headers. AL> Even better, due to the verified sender we can now send bounce messages AL> and notifications to originator. Sure, it'll result in "I never send AL> this..." type support calls but support can now say "Sure, your computer AL> did behind your back...". I hadn't thought of setting "Return-Path:" based on authenticated user... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
----- Original Message ----- From: "Edward B. Dreger" <eddy+public+spam@noc.everquick.net>
TV> Date: Fri, 4 Feb 2005 09:53:07 -0500 (EST) TV> From: Todd Vierling
TV> The only way to be sure is via cryptographic signature. Barring that level
False. You imply that a crypto signature is a perfect guarantee, and that nothing else can provide equal assurance.
Hi A cryptographic signature would be a perfect guarantee as it can be used for direct identification and authorisation if you were guaranteed that the only user of the signature was infact you and not the spyware on your machine. The implementation is everything. To prevent spyware using your signature you can for example use some sort of local signature engine and a fingerprint reader. It isn't possible to steal the private key because only the engine can decode it. Emails can only be signed with that signature by the engine, and the engine needs your fingerprint first. But who really wants to stick your thumb in the reader for every email you send? And I definatly don't want to start using rsa secureid for each email I send. By only having a signature engine you could atleast limit the amount of signed emails permitted to pass through to something like 1 for every 5 minute etc.. If you dont pass the email through the engine it won't be signed. So why would I want to use this engine then? Perhaps if Microsoft removed the existing way of signing emails with outlook and replaced it with this one. So, my point is that a cryptographic signature/SMIME would in fact work for the purpose it was made for on workstations depending on the implementation. Now that you are identified and authorised - I can still send you spam! How can I stop you from doing it? I can remove your authorisation. I can go visit you and beat you up. But its too late I already got your spam! If you have a default deny-all policy on your mailbox you might loose that $10m contract because you didn't reply in time to that email since it wasn't authorised. Can we afford the deny-all default policy then? It is your choice. If yes, then you really need something to send/receive authorisation requests if the recipient does not have you on its accept list. And I am pretty sure some smart spammer will abuse this service to send the actual spam with it if you permit text data from user-input. If you want something to be used globally it should also be possible to implement globally. Newsletters and similar emails generated by automated systems would be a problem. You just have to trust them to not spam you excessivly. Joergen Hovland
On Sat, 2005-02-05 at 19:18 +0000, Jørgen Hovland wrote:
----- Original Message ----- From: "Edward B. Dreger" <eddy+public+spam@noc.everquick.net>
TV> From: Todd Vierling
TV> The only way to be sure is via cryptographic signature. Barring TV> that level
False. You imply that a crypto signature is a perfect guarantee, and that nothing else can provide equal assurance.
To prevent spyware using your signature you can for example use some sort of local signature engine and a fingerprint reader. It isn't possible to steal the private key because only the engine can decode it. Emails can only be signed with that signature by the engine, and the engine needs your fingerprint first. But who really wants to stick your thumb in the reader for every email you send?
If each provider signed their messages AND included account identifiers (as used by their access servers), then the providers themselves or some third-party would have little trouble blackhole listing problematic systems. There would be NO danger that something in the customers system could be stolen. A blackhole A record of 127.0.0.1 by the provider at the following: <internal-identifier>._rl.<domain>.<tld> Or if by a third-party, it could be <internal-identifier>._rl.<domain>.<tld>.<third-party>.<tld> This mechanism would also prevent a replay attack on signatures as well as allow extraction of these problem accounts caused by compromised systems. These people would quickly learn they have a problem, if they use the mail services of the provider. If they do not, they should be blocked by the provider outright. To prevent bounce traffic unilaterally, BATV would be a better solution. SPF et al does not allow safe reputation assertions. A reputation assertion is the ONLY way this type of abuse can be prevented. Binding MAILFROM or the FROM with some IP address will not stop spam. Within two minutes, spammers will have adapted, and yet a tremendous expense and disruption will have taken place for little benefit. -Doug
JH> Date: Sat, 5 Feb 2005 19:18:53 -0000 JH> From: J�rgen Hovland JH> A cryptographic signature would be a perfect guarantee as it can be JH> used for direct identification and authorisation if you were No, it's not direct. You trust whoever signed the key. Note that I agree PGP key signing is less prone to attack than unsigned SPF. The severity of the difference is a matter for discussion... JH> guaranteed that the only user of the signature was infact you and JH> not the spyware on your machine. The implementation is everything. A cryptosig can ensure that the ISP didn't alter the message. AFAIK, most MUAs pull cryptosigs from the registry/configs. Could malware do the same? You bet. JH> To prevent spyware using your signature you can for example use some JH> sort of local signature engine and a fingerprint reader. It isn't Specifics, please. You'd need to ensure that the fingerprint reader would operate at a protection level that the spyware couldn't access. That's currently an unrealistic assumption. A worthy goal, but a bit of a stretch these days. JH> possible to steal the private key because only the engine can decode JH> it. Emails can only be signed with that signature by the engine, and JH> the engine needs your fingerprint first. But who really wants to JH> stick your thumb in the reader for every email you send? *shrug* Put a print reader on a keyboard... hold down finger/thumb a few seconds to authenticate... flush the queue for messages created prior to auth... [ snip ] JH> Now that you are identified and authorised - I can still send you JH> spam! How can I stop you from doing it? I can remove your Exactly. You can still send spam, but the sender is accurate. IMNSHO there is benefit in quickly determining *who* is responsible. I don't claim to have the FUSSP. The lack of such does not mean that partially-effective measures are worthless. (Hint: Nothing in the history of mankind has stopped murder. Should we discount all laws, punishments, et cetera?) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating?
that doesn't work if you have more than one email address.
You should know all your users email addresses. It shouldn't be too difficult to match the 'mail from' address with the user account. The only caveat would be that joe@hotmail.com would actually have to use the hotmail smtp server to send mail.
This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk.
auth is sufficient to make email traceable to your own customers.
And how is that? There isn't necessarily anything in an email indicating that it originated from an SMTP AUTH authenticated user. While a header could be added, it isn't a mandatory thing. Adi
You should know all your users email addresses.
You have got to be kidding.
Not kidding. I have a mail system that handles mail for the example.com domain. I use SMTP AUTH as the only means to relay through the server. My expectation from my customers is that they will utilize this mail service for their user@example.com communications. This means the mail server has knowledge of all 'mail from' addresses my users are allowed to use. Who says that Joe ISP has to provide an open SMTP relay to all customers on his IP space? Let's face it, it doesn't work! Even with throttling some SPAM will make it thorough and tha mail server will be black listed and unable to deliver mail to many destinations in no time. It's only a matter of time before owned PCs aquire the 'intelligence' to utilize SMTP AUTH to relay mail. So to clarify my position, my SMTP server handles mail for my users and noone else. My users are identified by their email address(es) on my mail server. Therefore, I can enforce that may mailserver reject relayed mail that does not have a 'mail from' address that corresponds to one of the valid email addresses for an authenticated users. I am addressing the dilemma with the average home user. If you own a bunch of domains you're in a whole different class. Make arrangement with your ISP to handle your mail, run your own mail server or buy hosting with email accounts. Point is, if you own a bunch of domains you're not the average home user that floods the world with crap without their knowledge. Adi
On Thu, 3 Feb 2005 17:36:31 -0600, Adi Linden <adil@adis.on.ca> wrote:
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk.
Ouch .. Then spammers may start using a From: matching the SMTP auth user, and effectively joe-jobbing the user.. Ick..
Adi
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk.
Ouch .. Then spammers may start using a From: matching the SMTP auth user, and effectively joe-jobbing the user.. Ick..
And that would be marvelous! At the very least it would give the user an incentive to clean up his PC. Alternately the email account could be revoked. Adi
JF> Date: Thu, 3 Feb 2005 20:37:29 -0500 JF> From: Jason Frisvold JF> Ouch .. Then spammers may start using a From: matching the SMTP auth JF> user, and effectively joe-jobbing the user.. Ick.. Exactly. The user then loses mail sending ability, but other services remain functional. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On Thu, 2005-02-03 at 14:55 -0800, J.D. Falk wrote:
On 02/03/05, "Hannigan, Martin" <hannigan@verisign.com> wrote:
..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home.
So you educate them as to why it would be a good idea to keep their computer secure.
But in the meantime, their machine is spewing garbage -- which, as many have said, is the operational issue at hand.
Solutions through diligent use of add-on products is not 100%. Many users spend $40 and diligently apply prophylactics, but still are compromised. Reinstalling over an existing installation does not ensure removal. Either way, this returns the OS to a vulnerable state, while costing several frustrating hours. Using a CD-ROM OS/App suite, such as Knoppix, sounds promising for this headache. It should be difficult to corrupt an OS or application when on Read-Only media. :) The number of zombies ensures rate limiting will not be effective either. Providers keeping their house in order in the face of this new strategy may be assisted by domain signed mail. This could serve to block compromised accounts with help from the provider themselves. Rejections from a third party will tell their clients they need a disinfectant. http://mipassoc.org/mass/ The wack-a-mole game needs a more agile mallet. -Doug
participants (12)
-
Adi Linden -
Douglas Otis -
Edward B. Dreger -
Guðbjörn S. Hreinsson -
Hannigan, Martin -
J.D. Falk -
Jason Frisvold -
Joel Jaeggli -
Jørgen Hovland -
Niels Bakker -
Sean Donelan -
Todd Vierling