Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Dec 9, 2005, at 4:09 PM, Robert Bonomi wrote: 1) Malware detection has a 0% false positive. If there is a 'false positive' detecting malware, it is a near certainty that the "legitimate" message so classified does *NOT* have a FORGED ADDRESS. When there is some percentage of false-positive detection, there will be a number of messages that will fall into the "should not have been rejected" category, where indeed the return-path is not likely to have been forged, and a DSN would be of value to the sender. When a DSN is sent, the sender will be able to take corrective action. There is also a percentage of messages where malware detection is valid, but nonetheless the return-path is also valid. (Perhaps overwritten by the provider.) You are judging this situation based upon only the wrong choice as having been made. AV filtering is not the only situation where a DSN exploit is used, and there is no way to be sure about a choice of discarding the DSN. Discarding DSNs _will_ degrade the integrity of email delivery. As the recipient of the DSN is _always_ the best judge whether the DSN was sent to a forged return-path, why not take advantage of that superior knowledge? Automate the process so the DSN recipient is able to immediate rejects _all_ invalid DSNs. Overall, email transactions will be faster, and DSN exploits will soon disappear. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Douglas Otis wrote: On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote: None of these are my problem. I am a non-involved third party to the malware detection software, so I should not be a party to its outgoing spew. I have not requested the virus "warnings" (unsolicited), they are being sent via an automated trigger (bulk, by extension of the viruses also being bulk), and they are e-mail -- UBE by definition. Whether they are also formatted as DSNs or delivered like DSNs doesn't take away their UBE status. This is a third-party acting in good faith, No it isn't. This is a third-party acting in their own interest with absolutely zero concern for how their actions affect others. The third party WANTS to return the DSN so it can advertise its filtering service. There is NO other possible reason or excuse for this. The third-party obviously has a vested interest in justifying and continuing this reprehensible behavior. you want them to toss the DSNs, because you _think_ the number of otherwise valid DSNs to be inconsequential (whether or not malware is actually detected). We KNOW the percentage of valid DSNs tossed by this action will be 0, or very very very close to 0. We know that if there were a significant percentage of DSNs that were desired by the "sender" then it would be just as easy for you to give those DSNs to the purported recipient so that they can notify the "sender" themselves. If the purported recipient doesn't want to see the DSNs because the false positive rate is 0 or close to 0, then you can be quite sure that the "senders" (most of whom never "sent" the message) certainly don't want to see them either. Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem? Because other systems aren't perfect is not an acceptable reason to let your system continue to do bad things. How would the third-party acting in good faith know who really sent the message? If the filtering system has any knowledge (or *should* have such knowledge) regarding the message received to indicate that the sender is forged, then it should not send a DSN to the sender address. Period. It should either discard the message and not generate a DSN or it should give the DSN to the purported recipient. If the purported recipient doesn't want to get a notice, then the system shouldn't inflict the notice on anyone else either. (Do you know what "cost shifting" means, and why it's considered bad, and why it is illegal in some forms?) In this case however, it is in keeping with a general expectation that a DSNs will be sent when a message can not be delivered. If this party wanted to save costs, they would toss the DSN. And lose the opportunity to market their product in the guise of sending a "desired DSN" to someone whose address they are 99.999% certain was forged by the virus? We all know that email marketing is very low cost (low cost mostly due to cost shifting, as noted above) so they would have to replace this low cost marketing technique with real marketing at a much higher cost. How can this entity know whether the DSN is going to the correct party? See above. How can this be called cost shifting? See above. DSNs with spoofed return-paths will not go away even after getting all the AV filters performed within the session sometime in the few years. No, they will go away by dropping DSNs on the floor when there is a high likelihood that the sender is forged. jc
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > > None of these are my problem. I am a non-involved third party to the > > malware detection software, so I should not be a party to its outgoing spew. > This is a third-party acting in good faith, Wow, you're one twisted individual. Can I have a hit of whatever you're smoking? I could use a fun hallucination tonight. (I'll settle for reading your posts, because they're becoming increasingly comical.) > How would the third-party acting in good faith know who really sent the > message? If they don't know, they have no business telling a random third party. And if they do drag in an innocent bystander, they are therefore *not* acting in good faith. > In this case however, it is in keeping with a general expectation that a DSNs > will be sent when a message can not be delivered. If this party wanted to > save costs, they would toss the DSN. > > How can this entity know whether the DSN is going to the correct party? In the case of malware, YOU KNOW IT IS FORGED in every case in recent history. What more do you need? > How can this be called cost shifting? If I am overburdened with other people's crap that never should have hit me, then I am bearing the *cost* of their abuse. And yes, spewing anything (whether you think it's a DSN or not) at me in bulk, when it has nothing to do with me, is abuse. I can only deduce that you're clueless, you have an ulterior motive (hmm...), or you haven't been using e-mail for very long. In any case, you are reflecting a *really* bad image on your mail domain (and thus your employer) by being so completely lost in your own world. I stand by my T. Roll conclusion. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Juniper DNS cache
On Fri, Dec 09, 2005 at 05:42:17PM -0500, Peering wrote: > Dumb question...anyone know how to clear the DNS cache on a Juniper > M-20? I looked all through the JUNOS documentation on their website and > looked through all the available commands and couldn't find anything. Juniper does not operate as a caching nameserver, therefore it has no DNS cache. It will send new queries to its configured nameservers every time, so if something isn't updating, it is the nameservers you are using. This question would probably be better suited for the Juniper-NSP mailing list (http://puck.nether.net/juniper-nsp/) too. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
> From [EMAIL PROTECTED] Fri Dec 9 17:10:00 2005 > Cc: "Steven J. Sobol" <[EMAIL PROTECTED]>, "Geo." <[EMAIL PROTECTED]>, > nanog@merit.edu > From: Douglas Otis <[EMAIL PROTECTED]> > Subject: Re: SMTP store and forward requires DSN for integrity (was > Re:Clueless anti-virus ) > Date: Fri, 9 Dec 2005 15:08:49 -0800 > To: Todd Vierling <[EMAIL PROTECTED]> > > > > On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote: > > > > None of these are my problem. I am a non-involved third party to > > the malware detection software, so I should not be a party to its > > outgoing spew. > > > > I have not requested the virus "warnings" (unsolicited), they are > > being sent via an automated trigger (bulk, by extension of the > > viruses also being bulk), and they are e-mail -- UBE by > > definition. Whether they are also formatted as DSNs or delivered > > like DSNs doesn't take away their UBE status. > > This is a third-party acting in good faith, "In good faith" is _HIGHLY_ debatable. "On blind faith" (that the sender address infor is accurate) is much closer to an accurate description. The aforementioned third parties, being experienced professionals, and even 'experts', in the field *SHOULD* KNOW BETTER than to act in that matter. How can they claim to be experts in the field and _NOT_ be aware of the _probability_ (not just the "possibility) of the sender address being spoofed? AND, *as*experts* in that area, it is incumbant on _them_ to 'act responsibily' on behalf of their clients/customers who are "not so knowledgable" about such matters. > How would the third-party acting in good faith know who really sent > the message?
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
> From [EMAIL PROTECTED] Fri Dec 9 13:59:30 2005 > nanog@merit.edu > From: Douglas Otis <[EMAIL PROTECTED]> > Subject: Re: SMTP store and forward requires DSN for integrity (was > Re:Clueless anti-virus ) > Date: Fri, 9 Dec 2005 11:58:15 -0800 > To: Todd Vierling <[EMAIL PROTECTED]> > > > > On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: > > > >1. Virus "warnings" to forged addresses are UBE, by definition. > > This definition would be making at least two of the following > assumptions: FALSE TO FACT. Notice the qualifier "forged", regarding the address to which the notification is being sent. > > 1) Malware detection has a 0% false positive. If there is a 'false positive' decting malware, it is a near certainty that the "legitimage" message so classified does *NOT* have a FORGED ADDRESS. In addition, _IF_ a false positive occurs, the *sender* can do nothing about the situation -- resending the message, for example, will *NOT* have any better chance of getting through. The _right_ person to notify in such a situation is the RECIPIENT. They have a chance of 'influencing' the people who set the policies (that resulted in that false postive) in regard to getting the policy _changed_. Thus, this is an invalid straw-man argument. One down. > 2) Lack of DSN for email falsely detected containing malware is okay. *IF* the sender address _is_ forged (a _necessary_ pre-condition for Todd's statement to be applicable, then the fact remains that that 'false positive' indication is going to someone who DID NOT REQUEST such notification, either explicitly (by signing up for it), nor implicitly (by actually _sending_ the message in question). Thus, this is an invalid straw-man argument. Two down. > 3) Purported malware should be assumed to use a forged return-path. I can't imagine why anyone could *possibly* think that that might be the case! Note: It does happen to be an assumption that does turn out to "coincide with the actual facts of the situation" in a _very_large_ share of the cases. In the last three years of rejecting (SMTP transaction-time) _anything_ that contained anything that 'looked like' either an MS-executable format attachment, or a ZIP file, I have not seen a *SINGLE* such message that did have an accurate return path. Available statistical data from other sources shows a "not quite that extreme" proportion. The _lowest_ numbers I've seen put the proportion at well over 90% -- basis the numbers of messages encountered. A trivial, surface-level, analysis of the goals of virus-writers shows that virus writers, in general, have *every* reason to obsure the "source" of the message, and _no_ reason for the message to "clearly identify" the actual message source. That once the virus-writer "community" figured out how to send messages with spoofed origin information, the _virtually_every_ virus released after that point *does* use such spoofing -- for the express purpose of making it 'as difficult as possible' to identify the true source of the infection-carrying message. It is also an "obvious fact" that people who are in the *business* of selling malware detection systems, have a business interest in "identifying" and "classifying" malware. "What it does", and "how it works" ARE (or should be) reasonable and expected parts of their identificaton/analysis/classificaiton process. Thus, 'malware detection system' vendors -- of all people -- should be expected to know _more_ about whether or not a particular 'detected' malware (regardless of whether or not it was a 'false positive' detection) is one that forges the 'pooint of origin' information that would be used to route a DSN. Thre is no need for the authors/sellers of 'malware detection systems' to "assume" any specific behavior as a 'default' assumption. They *SHOULD* *KNOW* the actual of every virus that they have an 'identification signature' for. thus there is no need to assume anything, they can act case-by-case on "actual", factual data. Thus, this is an invalid straw-man argument. Three down. > 4) The return-path can be validated prior to accepting a message. "wHO CARES" ABOUT the return-path? if you make the malware determination *at*the*exterior*gateway** to your network, *during* the SMTP transaction, you have a 'reliable' path back to the system that tried to deliver it _to_ you. If *they* don't know (reliably) who the actual sender of that message is, that is _their_ problem. If you _cannot_ make a real-time "malware" determination during the _gateway_ SMTP transaction, and the gateway has "accepted for delivery" the questionable message, then when the 'malware' determination is made, the message should be simply _delivered_, according to site policy -- directly to the bit-bucket. As this _does_ meet the 'delivery' requirements of the relevant RFCs, thre is no need to send a failure notification 'backwareds' to anywhere. Thus, this is an invalid straw-man argument. four down
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > [AV notifications are] a third-party acting in good faith Perhaps in your world. Definitely not in mine. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote: None of these are my problem. I am a non-involved third party to the malware detection software, so I should not be a party to its outgoing spew. I have not requested the virus "warnings" (unsolicited), they are being sent via an automated trigger (bulk, by extension of the viruses also being bulk), and they are e-mail -- UBE by definition. Whether they are also formatted as DSNs or delivered like DSNs doesn't take away their UBE status. This is a third-party acting in good faith, albeit performing a check better done within the session. In your view, there is less concern about delivery integrity, and so related DSNs should be tossed. Being done within the session would be ideal, of course. When their architecture does not support this approach, you want them to toss the DSNs, because you _think_ the number of otherwise valid DSNs to be inconsequential (whether or not malware is actually detected). Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem? How would the third-party acting in good faith know who really sent the message? (Do you know what "cost shifting" means, and why it's considered bad, and why it is illegal in some forms?) In this case however, it is in keeping with a general expectation that a DSNs will be sent when a message can not be delivered. If this party wanted to save costs, they would toss the DSN. How can this entity know whether the DSN is going to the correct party? How can this be called cost shifting? Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Besides this being another rewording of the classic "victim must fend for him/herself" mantra, and a complete misrepresentation of the problem of scale in implementing BATV the way you describe, you're calling these "DSN exploits" -- not "DSNs" -- here. This is a remarkable argument. DSNs with spoofed return-paths will not go away even after getting all the AV filters performed within the session sometime in the few years. In fact, in session filtering will likely increase costs related to email by making all exchanges take longer to complete. BATV can refuse invalid DSNs before the data phase, after expending a few microseconds to make and check tags. The cost savings provided by a BATV approach can be rather large which will only increase the scalability of email. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Micheal Patterson" <[EMAIL PROTECTED]> To: "Douglas Otis" <[EMAIL PROTECTED]>; "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Steven J. Sobol" <[EMAIL PROTECTED]>; "Geo." <[EMAIL PROTECTED]>; Sent: Friday, December 09, 2005 4:01 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) - Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Steven J. Sobol" <[EMAIL PROTECTED]>; "Geo." <[EMAIL PROTECTED]>; Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus "warnings" to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. Case in point Doug.. Current versions of Sober.U are sending mail from: [EMAIL PROTECTED] (xx's to hide the actual host). I have a slew of these in my detected malware folder. I suppose that you'd prefer, by your reasoning, that I be sending DSN's to these addresses, knowing full well that it won't make it and just clutter up comcast's smtp gateway with DSN's. I'm sure that they'd like that very much. Mike P. And before anyone points out that the mx for comcast would not see that message, I know that on this particular host, they would not. I also realize the the DSN would sit in my outbound queue until it was purged after 5 days due to non-delivery. The point remains the same for this example as if it were addresses from [EMAIL PROTECTED] or [EMAIL PROTECTED] The originator is forged and the DSN is unable to get to the originating sender. Mike P.
Juniper DNS cache
Title: Juniper DNS cache Dumb question…anyone know how to clear the DNS cache on a Juniper M-20? I looked all through the JUNOS documentation on their website and looked through all the available commands and couldn't find anything. Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Leaving aside from the question of if virus-infected DSNs are UBE and thus "spam" or not... Todd Vierling wrote: If you want to notify someone about a filtered malware instance, notify the intended *recipient*, and provide that user with the email address of the alleged sender. If it's a false positive, the intended recipient of the filtered mail can contact the other party to fix the situation. Oh, but I know the response already: "But our users don't want to see those notices, they're not much better than the viruses getting through, all that spam to delete." And an otherwise non-involved third party should be burdened with this crap because...? this is the crux of the matter. When your filtering system determines that the message contains a virus, the filter KNOWS (or should know, and with a high degree of certainty) the message is unwanted and the "sender" is forged. Your recipient/customer doesn't want to see the message OR the DSN. So why send either on to someone else?! It is a reprehensible practice to send the notice off to the "sender" by claiming that an RFC says this is what you should do with a generic DSN. It is NOT a good practice, it IS network abuse. It is reprehensible to knowingly or "innocently" design software to do this, or to use software that does this by default unless you make very certain that you have disabled this "feature" and that it STAYS disabled whenever you upgrade or otherwise change the software configuration. All of this is crystal clear without needlessly arguing or trying to determine if DSNs of virus infected email are "spam" or not. It was sent to your recipient/customer and if they don't want it then treat it the same way you treat all other email they don't want (spam filtering). jc
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Steven J. Sobol" <[EMAIL PROTECTED]>; "Geo." <[EMAIL PROTECTED]>; Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus "warnings" to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. Case in point Doug.. Current versions of Sober.U are sending mail from: [EMAIL PROTECTED] (xx's to hide the actual host). I have a slew of these in my detected malware folder. I suppose that you'd prefer, by your reasoning, that I be sending DSN's to these addresses, knowing full well that it won't make it and just clutter up comcast's smtp gateway with DSN's. I'm sure that they'd like that very much. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Steven J. Sobol" <[EMAIL PROTECTED]>; "Geo." <[EMAIL PROTECTED]>; Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus "warnings" to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. While there could be best practices created for AV filtering, it seems unlikely to be effective. Simplistic filters for DSNs also seem counter to ensuring the integrity of email delivery. Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Why expect others to fix this problem, when there is a solution that one could make the investment in to deploy. This will reduce this problem over the long term. The BATV alternative would not cause otherwise valuable DSNs to be lost, nor make assumptions about the quality of malware detection. If you can't trust AV handling of DSNs, why trust their detections? Would you rather see emails simply disappear? I would rather see the problem stop at the source instead of the current issue being used as a crutch to attempt to get people to go to BATV or Mass-Rep (as described in your draft). There's an old military comm saying that fits perfectly here. "Clean House". For those of you ex comm folks, you'll probably recognize it. For those of you who don't, it simply means, fix your stuff before you point blame at the distant end for the problem. 2. It is the responsibility of the *SENDER* not to send UBE. When the recipient is a legitimate email provider, it could seriously lower the integrity of email delivery for these providers to toss DSNs because many fall into a category you want to define as UBE. While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution. -Doug Do you not comprehend what's really being said here Doug? Yes, blocking / rejecting of a DSN is a BAD thing and should never be done. Rejecting of a notification of malware != the same thing. If the reciever of "your" DSN didn't sent the message, then it's no longer a DSN.. It's now officially, by definition, UBE from YOU to the incorrect originator now isn't it. This is the case in the majority of malware notifications by anyone / anything that generates them. More than likely, the viri / trojan writer is "depending" on them to help propogate their ilk because they too can be network admins and are aware that DSN's don't get tossed. What better method to get them out to the masses but to have our main feeds, and huge pipes help them along? I mean, really, who's better to help them? Mom and dat with the 56k dialup or us with the DS3's - OC12's to help them along? Look at the big picture Doug instead of 45 degrees to the left and right. You hate spam, I hate spam, I don't send DSN's to senders because I know that roughly 90% of them are bogus. You feel that's bad. You have the right to disagree. I have the right to deny traffic that is in response to traffic that didn't originate from my network(s) regardless of your belief. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > > 1. Virus "warnings" to forged addresses are UBE, by definition. > > This definition would be making at least two of the following assumptions: > > 1) Malware detection has a 0% false positive. > 2) Lack of DSN for email falsely detected containing malware is okay. > 3) Purported malware should be assumed to use a forged return-path. > 4) The return-path can be validated prior to accepting a message. None of these are my problem. I am a non-involved third party to the malware detection software, so I should not be a party to its outgoing spew. I have not requested the virus "warnings" (unsolicited), they are being sent via an automated trigger (bulk, by extension of the viruses also being bulk), and they are e-mail -- UBE by definition. Whether they are also formatted as DSNs or delivered like DSNs doesn't take away their UBE status. If you want to notify someone about a filtered malware instance, notify the intended *recipient*, and provide that user with the email address of the alleged sender. If it's a false positive, the intended recipient of the filtered mail can contact the other party to fix the situation. Oh, but I know the response already: "But our users don't want to see those notices, they're not much better than the viruses getting through, all that spam to delete." And an otherwise non-involved third party should be burdened with this crap because...? (Do you know what "cost shifting" means, and why it's considered bad, and why it is illegal in some forms?) The more important part is that the afflicted products usually DO know the forgery status of the malware it is detecting -- so there should be nearly no question as to when "warnings" would be UBE. That notwithstanding, the probability of a forgery case is better than 99%, so the assuption for anti-malware products should now be "forged unless proven otherwise". Hell, I'd give that forgery probability a Five Nines these days. > 5) SMTP should appear to be point-to-point. There are ways to limit the scope of this problem as it applies to non-virus-warning bounces, without going to direct point to point delivery. There are schemes by which a 5xx reject can propagate up a delivery path without requiring a bounce to be generated. *This* is the direction SMTP should be headed, and it need not be forcibly point to point. This too is irrelevant when considering the Five Nines probability above. > 6) MTAs with AV filters are the only problem. Not the only problem, but they are currently taking up the vast majority of the problem space of blowback UBE instances. They aren't always constant, but when a worm surge starts, the blowback floods. > Defending against DSN exploits with BATV will remove this vector, which in > turn will end DSN exploits attempts over the long term. Besides this being another rewording of the classic "victim must fend for him/herself" mantra, and a complete misrepresentation of the problem of scale in implementing BATV the way you describe, you're calling these "DSN exploits" -- not "DSNs" -- here. Maybe the clue is finally sinking in? Nh: > If you can't trust AV handling of DSNs, why trust their detections? You can claim that these virus "warnings" are DSNs all you want. Just like politicians' talking points, just saying it a lot doesn't automatically make it true. Prove it, to wit: Since I never sent the original virus-worms that triggered the UBE in question, exactly how is one of these virus "warnings" is a *valid* DSN, and not UBE...? (Here's a hint for the boys and girls at home: DSNs are supposed to go to the real, original sender.) If the general case for e-mail borne viruses weere non-forged senders, I could buy the DSN argument. But that's not the general case at all. > While I agree whole heartily this malware notification problem stinks, > there is a much safer and surer solution. Yes, there is: Notify the intended recipient of the virus, not the (almost surely forged) sender. Don't cost shift the burden onto third parties, and don't try to rebrand spew that *never* hits the real original sender as some kind of "DSN". "Paging a T. Roll to the white courtesy clue-phone" -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Douglas Otis wrote: On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus "warnings" to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. Near enough so that reject at SMTP data phase will cover all legitimate cases that may exist. 2) Lack of DSN for email falsely detected containing malware is okay. 1 dropped email is NOT worth thousands of to-forged addresses DSN's The admins that care will design their systems to reject by smtp DATA pohase 3) Purported malware should be assumed to use a forged return-path. Yup, thats true of everything in the wild today. 4) The return-path can be validated prior to accepting a message. Exactly, only then is DSN's acceptable to otherwise near guaranteed incorrect destinations. 5) SMTP should appear to be point-to-point. Obeying the SMTP standard should not generate crap unneedlessly. That means reject virus at data phase, discard them afterwards since the DSN violated the much more important rule not spewing crap at innocent 3rd parties. 6) MTAs with AV filters are the only problem. To generalize it: Systems which generate DSN's to known incorrect destinations are the EXACT problem discussed here. Currently that fits all "scan after receipt of messafe" av systems that send DSN's While there could be best practices created for AV filtering, it seems unlikely to be effective. Simplistic filters for DSNs also seem counter to ensuring the integrity of email delivery. Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Why expect others to fix this problem, when there is a solution that one could make the investment in to deploy. This will reduce this problem over the long term. The BATV alternative would not cause otherwise valuable DSNs to be lost, nor make assumptions about the quality of malware detection. I havent been keeping on top of the sender/return path verification scene. But blacklisting abusive systems to create pressure on admins to turn the spewage off is the current time honored mechanism. If you can't trust AV handling of DSNs, why trust their detections? One is fairly easy to measure. The other SHOULD be fairly easy to turn off. Would you rather see emails simply disappear? I would rather my MTA return the DSN it generates when it receives your MTA's smtp rejection to the data command contents. 2. It is the responsibility of the *SENDER* not to send UBE. When the recipient is a legitimate email provider, it could seriously lower the integrity of email delivery for these providers to toss DSNs because many fall into a category you want to define as UBE. While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution. Blocklisting them should even things out eventually. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Matt Ghali" <[EMAIL PROTECTED]> To: "Micheal Patterson" <[EMAIL PROTECTED]> Cc: Sent: Friday, December 09, 2005 1:49 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Fri, 9 Dec 2005, Micheal Patterson wrote: They may not a choice if those that are being hammered with their auto-generated DSN's deem it unusually high traffic rate and simply black list the domains using these devices. AOL.com comes to mind and a few others in the recent weeks that are hammering me with notifications that weren't sent by anyone within my network. I especially appreciate the ones from Yahoo!, who apparently do not bother checking domainkeys at all before generating bounces. gg. matto [EMAIL PROTECTED]< I like the ones from aol.com that also include all of the other addresses that the initial hit was sent to within their domain. Some of them are upwards of 10 pages of nothing but email addresses. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus "warnings" to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. While there could be best practices created for AV filtering, it seems unlikely to be effective. Simplistic filters for DSNs also seem counter to ensuring the integrity of email delivery. Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Why expect others to fix this problem, when there is a solution that one could make the investment in to deploy. This will reduce this problem over the long term. The BATV alternative would not cause otherwise valuable DSNs to be lost, nor make assumptions about the quality of malware detection. If you can't trust AV handling of DSNs, why trust their detections? Would you rather see emails simply disappear? 2. It is the responsibility of the *SENDER* not to send UBE. When the recipient is a legitimate email provider, it could seriously lower the integrity of email delivery for these providers to toss DSNs because many fall into a category you want to define as UBE. While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Micheal Patterson wrote: They may not a choice if those that are being hammered with their auto-generated DSN's deem it unusually high traffic rate and simply black list the domains using these devices. AOL.com comes to mind and a few others in the recent weeks that are hammering me with notifications that weren't sent by anyone within my network. I especially appreciate the ones from Yahoo!, who apparently do not bother checking domainkeys at all before generating bounces. gg. matto [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: SMTP store and forward requires DSN for integrity (wasRe:Clueless anti-virus )
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Geo." <[EMAIL PROTECTED]>; Sent: Friday, December 09, 2005 11:03 AM Subject: RE: SMTP store and forward requires DSN for integrity (wasRe:Clueless anti-virus ) On Fri, 2005-12-09 at 11:16 -0500, Todd Vierling wrote: On Fri, 9 Dec 2005, Geo. wrote: > If everyone would just standardize on at least the first part of every > virus > notification being the same thing, say: > > XXX VIRUS NOTIFICATION: blah blah blah > > where XXX is some error number, we could all easily control virus > notifications at the receiving end, allowing or blocking, as the > recipients > choice. Have you not even read the rest of the prior thread? It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, which I must receive all the way through the DATA phase in order to block. That's the problem: just like other forms of UBE, virus-worm warnings (to forged addresses) *do not scale*. I don't care what kind of duck the UBE looks like. Content is irrelevant. It still looks, walks, and quacks like a UBE duck. There is a solution you can implement now that gets rid of these tens of thousands of virus and abuse laden DSNs you see every day before the data phase. It could be seen as less than altruistic to bounce content of suspected malware, so perhaps one should not expect standardization of DSN content either. There are many languages to deal with as well. It's only a solution if it's available for all accepted MTA's that currently exist. According to MIPA, the only currently available BATV "equipped" mta's are Exim and NetQmail. I'll admit that I'm not up to par on the BATV project but damn, if you can't find information on it through a google search, or you find very limited information on it, then how can you say that it's ready for implementation now? Also, regardless of it's status, why should I have to redo my entire mail system to deploy BATV because others can't play nice on the net? With BATV, the slogan could be a quote from Socrates "Know thyself." With BATV, you should stop blaming others for _your_ inability to deal with a DSN problem. Calling DSNs UBE is not a solution, although traffic from AV applications seems to be approaching that definition. If it has a null return-path, that is all you should need. -Doug When DSN's become autogenerated by systems that are not MTA's then those messages should no longer be considered DSNs should they. My "inability" to deal with a DSN problem? Please allow me to assure you that I have various methods of dealing with bogus DSN's within my network infrastructure. Regardless of that, why should I have to accept traffic not destined for my network? That is, afterall, what is happening when a DSN is sent to a forged originating address is it not? Truth of the matter is that I don't have to accept it at all. Your belief that I have the inability to deal with the problem is a misconception on your part. One has various methods in place already to deal with the problem at a very basic level. One can merely filter traffic at their upstream provider, place restrictions on their local MTA, firewall appliance or router. Those of us that see that DSN's are becoming UBE are trying to get the issue resolved before it comes to that. It will either happen or filters will go live. It's just that simple. Mike P.
Re: Viral Cure Could 'Immunise' The Internet
In message <[EMAIL PROTECTED]>, "Christ opher L. Morrow" writes: > > >On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: > >> >> >> Thought folks might find this interesting >> >> http://www.newscientist.com/article.ns?id=dn8403 >> >> Viral Cure Could 'Immunise' The Internet, New Scientist >> >> Excerpts: A cure for computer viruses that spreads in a viral fashion >> could immunise the internet, even against pests that travel at lightning >> speed, a mathematical study reveals. > >I think they call this 'welchia'... I don't recall it doing all that many >'good' things, unless 'raising customer traffic rates' qualifies as >'good'. > Besides, it's *unauthorized*. I don't want random strangers deciding when my machine should be patched. I think, in this forum, we all know that patches can have bad side effects. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Geo." <[EMAIL PROTECTED]> To: Sent: Friday, December 09, 2005 10:59 AM Subject: RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, << I hear you but you and I both know AV companies are not going to give up the automated spamming feature that easily. A standard message beginning they might be willing to impliment in a relatively short time and AV software is constantly updated so this could make a difference and happen relatively quickly. As for the quantity you receive, its nothing compared to the amount of spam those infected machines are soon going to be generating. George Roettger Netlink Services They may not a choice if those that are being hammered with their auto-generated DSN's deem it unusually high traffic rate and simply black list the domains using these devices. AOL.com comes to mind and a few others in the recent weeks that are hammering me with notifications that weren't sent by anyone within my network. That's the problem that I'm looking at George, the amount of traffic that those systems will be generating in the future. Including the bogus DSN's that are a direct result of that initial burst traffic. Mike P.
Re: Viral Cure Could 'Immunise' The Internet
On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: Excerpts: A cure for computer viruses that spreads in a viral fashion ^^^ could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Nobody remembers Nachi/Welchia and the damage it did to networks while curing blaster? Nice intention. Bad idea. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: "Geo." <[EMAIL PROTECTED]> To: Sent: Friday, December 09, 2005 9:57 AM Subject: RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) While AV scanning may be done during the session, it would also require additional steps to also contain _all_ upstream activity within the same session as well, when attempting to achieve an apparent point-to-point operation. If SMTP were point-to-point, this would be evolving into the IM model where the message queue or storage would always be at the sender. Such mode of operation will increase the average transaction time needed for email.<< You know, the problem we are trying to solve is virus notification blowback, etc. So instead of changing the system why not work with it. If everyone would just standardize on at least the first part of every virus notification being the same thing, say: XXX VIRUS NOTIFICATION: blah blah blah where XXX is some error number, we could all easily control virus notifications at the receiving end, allowing or blocking, as the recipients choice. A simple standard message format and all the problems and complaints go away. George Roettger Netlink Services Standardizing the DSN is an exercise in futility. Mainly because it still requires the message to pass through your outbound pipe and into my inbound pipe, hit my server port where my server starts processing that traffic. What has been accomplished here? Providing me a mechanism to block the notification if it's for a virus? For systems that are sending out notifications with forged addresses, this becomes UBE and provisions are already in place in the mta via access or in worst cases, the border firewall or even the border router for dealing with the originating network itself. If a system is incapable of determining the validity of the sender address, then that address should not be getting a DSN from any system regarding a virus, trojan or other malware. One can say, well *this* system is going into place or *that* system is in place at these locations, but it's simply not good enough. It's not standardized. There is currently no 100% tried and true method of dealing with this that is *standard* through out the net. So, the next best thing is to simply not send the DSN for viri / trojan infection at all. What was the quote from Wargames? Oh yes, "The only winning move is not to play". Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > > Actually, I get about ten to twenty times as much virus blowback as I get > > spam from trojan-zombie boxes. > I am having difficulty understanding why a one time investment in > Bounce-Address Tag Validation which can be in operation immediately and offer > 100% "blowback" protection from _all_ sources using trivial resources is not > being considered? I may be considering it. I may be implementing it right now. I may have already implemented it. Who's to know? It doesn't matter, because the use of recipient-side filtering or rejection of blowback is irrelevant to my point. > The more who lock their back door, the fewer times you will > find miscreants checking to see that it is locked. That doesn't mean that I should have thousands of people coming up to my back door 24 hours a day, nor should I have to watch my back door to shoo them away all day long. (Read: "That analogy doesn't fly.") I can police my network in any way I choose. I can have dozens of locks on my virtual doors -- and I do. That still doesn't take away culpability from the UBE sender, and thus has no relevance to the discussion at hand. Let me state this again in exactly two sentences so that you may understand my point, provided there is enough thin skull available for it to penetrate: 1. Virus "warnings" to forged addresses are UBE, by definition. 2. It is the responsibility of the *SENDER* not to send UBE. If this is still not clear, you're working in the wrong industry. === On Fri, 9 Dec 2005, Steven J. Sobol wrote: > I'd like someone UNBIASED to take up his side of the discussion, please. > I'm really not inclined to listen to an AV employee explain why they > should be spamming us. "What he said." -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Dec 9, 2005, at 9:59 AM, Steven J. Sobol wrote: On Fri, 9 Dec 2005, Todd Vierling wrote: I'd like someone UNBIASED to take up his side of the discussion, please. I'm really not inclined to listen to an AV employee explain why they should be spamming us. I am not aware of any of our products that exhibits the behavior touted as offensive. Nevertheless, there is a solution that does not require any services or products from yet another vender. This is a DSN exploit problem that has a BATV solution, independent of third- party behavior. : ) -Doug
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 10 Dec, 2005 Analysis Summary BGP routing table entries examined: 176382 Prefixes after maximum aggregation: 99292 Unique aggregates announced to Internet: 85551 Total ASes present in the Internet Routing Table: 21109 Origin-only ASes present in the Internet Routing Table: 18376 Origin ASes announcing only one prefix:8708 Transit ASes present in the Internet Routing Table:2733 Transit-only ASes present in the Internet Routing Table: 73 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 20 Prefixes from unregistered ASNs in the Routing Table:10 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 12 Number of addresses announced to Internet: 1487247552 Equivalent to 88 /8s, 165 /16s and 152 /24s Percentage of available address space announced: 40.1 Percentage of allocated address space announced: 60.4 Percentage of available address space allocated: 66.4 Total number of prefixes smaller than registry allocations: 84709 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:37050 Total APNIC prefixes after maximum aggregation: 15698 Prefixes being announced from the APNIC address blocks: 34782 Unique aggregates announced from the APNIC address blocks:16957 APNIC Region origin ASes present in the Internet Routing Table:2433 APNIC Region origin ASes announcing only one prefix:701 APNIC Region transit ASes present in the Internet Routing Table:367 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 208250048 Equivalent to 12 /8s, 105 /16s and 164 /24s Percentage of available APNIC address space announced: 77.3 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 93025 Total ARIN prefixes after maximum aggregation:56083 Prefixes being announced from the ARIN address blocks:72439 Unique aggregates announced from the ARIN address blocks: 27647 ARIN Region origin ASes present in the Internet Routing Table:10395 ARIN Region origin ASes announcing only one prefix:3871 ARIN Region transit ASes present in the Internet Routing Table: 958 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 278863872 Equivalent to 16 /8s, 159 /16s and 32 /24s Percentage of available ARIN address space announced: 69.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 74/7, 76/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 34544 Total RIPE prefixes after maximum aggregation:23346 Prefixes being announced from the RIPE address blocks:31538 Unique aggregates announced from the RIPE address blocks: 21154 RIPE Region origin ASes present in the Internet Routing Table: 7406 RIPE Region origin ASes announcing only one prefix:3881 RIPE Region transit ASes present in the Internet Routing Table:1225 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to I
Re: Viral Cure Could 'Immunise' The Internet
On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: > Keep in mind the study was done by physicists, who while brilliant, > cannot be bothered with operational realities that prevent their > equations from being elegant. > > Still an interesting hypothesis on how to leverage network structure to > fight infections - this assumes you buy into the whole Internet is > "scale free" argument to begin with. And you buy the argument that computer viruses are dumb. Malware is not naturally occuring and is not random. Crime on the Internet is becoming more lumpy.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Dec 9, 2005, at 9:22 AM, Todd Vierling wrote: Actually, I get about ten to twenty times as much virus blowback as I get spam from trojan-zombie boxes. That's because the virus blowback comes from otherwise "reputable" MTAs, whereas the spam comes form zombies that are often already blacklisted, or are in known dynamic pools that are blocked here. Thus the zombies get blocked long before DATA, but the "reputable" MTAs sending the backscatter don't get caught so early. I am having difficulty understanding why a one time investment in Bounce-Address Tag Validation which can be in operation immediately and offer 100% "blowback" protection from _all_ sources using trivial resources is not being considered? The more who lock their back door, the fewer times you will find miscreants checking to see that it is locked. -Doug
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Todd Vierling wrote: > > On Fri, 9 Dec 2005, Douglas Otis wrote: > > > There is a solution you can implement now that gets rid of these tens of > > thousands of virus and abuse laden DSNs you see every day before the > > data phase. > > And it is *my* responsibility to reject UBE that shouldn't have been > generated in the first place, because...? If I mentioned this yesterday, forgive me: A MAPS employee should know better than to suggest that. However, Maps was bought by Dave Rand and I believe Dave Rand sold out to Trend Micro. If this is correct, then perhaps Doug Otis should bow out of this conversation, seeing as how he works for one of the big AV vendors. I'd like someone UNBIASED to take up his side of the discussion, please. I'm really not inclined to listen to an AV employee explain why they should be spamming us. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Geo. wrote: > I hear you but you and I both know AV companies are not going to give up the > automated spamming feature that easily. I don't doubt that. Their generated UBE is often commercial in nature, too, because they usually carry an advertising link along with the spew. > A standard message beginning they might be willing to impliment I have enough regex filters, thank you. I don't plan to encourage yet more UBE by standardizing it -- think [YOU-]CAN-SPAM for antivirus apps. I should not have to waste the bandwidth cost at DATA for yet more UBE. > As for the quantity you receive, its nothing compared to the amount of spam > those infected machines are soon going to be generating. Actually, I get about ten to twenty times as much virus blowback as I get spam from trojan-zombie boxes. That's because the virus blowback comes from otherwise "reputable" MTAs, whereas the spam comes form zombies that are often already blacklisted, or are in known dynamic pools that are blocked here. Thus the zombies get blocked long before DATA, but the "reputable" MTAs sending the backscatter don't get caught so early. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > There is a solution you can implement now that gets rid of these tens of > thousands of virus and abuse laden DSNs you see every day before the > data phase. And it is *my* responsibility to reject UBE that shouldn't have been generated in the first place, because...? Blocking the UBE is not the solution; it is a bandage over a bleeding artery. The solution is not to generate the UBE in the first place. You'll note that, again, I am very explicitly not equating these to DSNs. As I said before in N forms, I don't care what color of shirt the virus "warning" wears; if sent to a forged address, it is UBE and deserved to be treated as such. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: > There is a solution you can implement now that gets rid of these tens of > thousands of virus and abuse laden DSNs you see every day before the > data phase. Why should the burden/cost/hassle be placed on me to do this? In many cases, it isn't even one of my users sending the stuff! -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Geo. wrote: > I hear you but you and I both know AV companies are not going to give up the > automated spamming feature that easily. Then maybe we should bring market pressure to bear on them. Personally, I run Exim and ClamAV and don't have that problem. If they're going to spam - and I'm sorry, we're not talking about DSNs here, we're talking about obnoxious AV vendors telling us how great their product is - then either we should try to convince people to stop using those vendors or at least beat up on the vendors to fix their brokenness. Is anyone here a customer of any of the vendors that play this game? -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 2005-12-09 at 11:16 -0500, Todd Vierling wrote: > On Fri, 9 Dec 2005, Geo. wrote: > > > If everyone would just standardize on at least the first part of every virus > > notification being the same thing, say: > > > > XXX VIRUS NOTIFICATION: blah blah blah > > > > where XXX is some error number, we could all easily control virus > > notifications at the receiving end, allowing or blocking, as the recipients > > choice. > > Have you not even read the rest of the prior thread? > > It doesn't matter what the notifications look like. There is no reason that > my SMTP server should be subject to more than TEN THOUSAND of these damned > things every day, which I must receive all the way through the DATA phase in > order to block. That's the problem: just like other forms of UBE, > virus-worm warnings (to forged addresses) *do not scale*. > > I don't care what kind of duck the UBE looks like. Content is irrelevant. > It still looks, walks, and quacks like a UBE duck. There is a solution you can implement now that gets rid of these tens of thousands of virus and abuse laden DSNs you see every day before the data phase. It could be seen as less than altruistic to bounce content of suspected malware, so perhaps one should not expect standardization of DSN content either. There are many languages to deal with as well. With BATV, the slogan could be a quote from Socrates "Know thyself." With BATV, you should stop blaming others for _your_ inability to deal with a DSN problem. Calling DSNs UBE is not a solution, although traffic from AV applications seems to be approaching that definition. If it has a null return-path, that is all you should need. -Doug
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
>>It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, << I hear you but you and I both know AV companies are not going to give up the automated spamming feature that easily. A standard message beginning they might be willing to impliment in a relatively short time and AV software is constantly updated so this could make a difference and happen relatively quickly. As for the quantity you receive, its nothing compared to the amount of spam those infected machines are soon going to be generating. George Roettger Netlink Services
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Geo. wrote: > If everyone would just standardize on at least the first part of every virus > notification being the same thing, say: > > XXX VIRUS NOTIFICATION: blah blah blah > > where XXX is some error number, we could all easily control virus > notifications at the receiving end, allowing or blocking, as the recipients > choice. Have you not even read the rest of the prior thread? It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, which I must receive all the way through the DATA phase in order to block. That's the problem: just like other forms of UBE, virus-worm warnings (to forged addresses) *do not scale*. I don't care what kind of duck the UBE looks like. Content is irrelevant. It still looks, walks, and quacks like a UBE duck. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Viral Cure Could 'Immunise' The Internet
On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: > > > Thought folks might find this interesting > > http://www.newscientist.com/article.ns?id=dn8403 > > Viral Cure Could 'Immunise' The Internet, New Scientist > > Excerpts: A cure for computer viruses that spreads in a viral fashion > could immunise the internet, even against pests that travel at lightning > speed, a mathematical study reveals. I think they call this 'welchia'... I don't recall it doing all that many 'good' things, unless 'raising customer traffic rates' qualifies as 'good'.
Re: Viral Cure Could 'Immunise' The Internet
On Fri, Dec 09, 2005 at 10:46:50AM -0500, [EMAIL PROTECTED] wrote: > Keep in mind the study was done by physicists, who while brilliant, > cannot be bothered with operational realities that prevent their > equations from being elegant. The Form Factor of a Cow: Summary http://graphics.cs.uiuc.edu/~garland/CMU/cow-formfac.html "For evaluating thermal radiant exchange between a cow and her surroundings, the cow can be represented by an equivalent sphere..." Eric, trained theoretical physicist who is bothered daily by the operational realities of his network...
RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
>>While AV scanning may be done during the session, it would also require additional steps to also contain _all_ upstream activity within the same session as well, when attempting to achieve an apparent point-to-point operation. If SMTP were point-to-point, this would be evolving into the IM model where the message queue or storage would always be at the sender. Such mode of operation will increase the average transaction time needed for email.<< You know, the problem we are trying to solve is virus notification blowback, etc. So instead of changing the system why not work with it. If everyone would just standardize on at least the first part of every virus notification being the same thing, say: XXX VIRUS NOTIFICATION: blah blah blah where XXX is some error number, we could all easily control virus notifications at the receiving end, allowing or blocking, as the recipients choice. A simple standard message format and all the problems and complaints go away. George Roettger Netlink Services
Re: Viral Cure Could 'Immunise' The Internet
Keep in mind the study was done by physicists, who while brilliant, cannot be bothered with operational realities that prevent their equations from being elegant. Still an interesting hypothesis on how to leverage network structure to fight infections - this assumes you buy into the whole Internet is "scale free" argument to begin with. - Original Message - From: Simon Waters <[EMAIL PROTECTED]> Date: Friday, December 9, 2005 10:34 am Subject: Re: Viral Cure Could 'Immunise' The Internet > > On Friday 09 Dec 2005 14:57, you wrote: > > > > a mathematical study is going to come up with a result that is more > > meaningful. > > The story is badly headlined. > > The study is saying how many "canaries" do we need to keep the > Internet safe, > or how big the immune system needs to be, not about a viral cure > as such. > > It says to keep the infection rate of new malware down to a > fraction of a > percent we'd need about a million or so machines looking for > malware (on some > assumptions). > > Should convince someone that we need to change the assumptions. > Hopefully the > modelling says something about what factors it is sensitive to. > > It does however remind me of the comparison of engineering and > science, a > scientist will earn a living by taking a really difficult problem > and spends > many years solving it, an engineer earns a living by finding > really > difficult problems and side stepping them. >
SMTP store and forward requires DSN for integrity (was Re: Clueless anti-virus )
On Fri, 2005-12-09 at 09:25 +, Simon Waters wrote: > But the point of this discussion is that SMTP will have to evolve to be a > point to point system (or functional equivalent). The days of store and > forward in intermediate MTAs should die as quickly as possible (which as our > forwarding demonstrates may be quite slowly alas). The problem is that many > of the antivirus gateways behave like new intermediate MTAs, especially when > for many of the organisations involved it could easily be done during SMTP > transactions. While AV scanning may be done during the session, it would also require additional steps to also contain _all_ upstream activity within the same session as well, when attempting to achieve an apparent point-to-point operation. If SMTP were point-to-point, this would be evolving into the IM model where the message queue or storage would always be at the sender. Such mode of operation will increase the average transaction time needed for email. As SMTP may pass messages through multiple administratively separate MTAs where acceptance criteria may differ, unless all connections needed to complete the transaction are active simultaneously, refusal at any point will require use of a DSN or delivery integrity is lost. A common exploit used by abusers is to find where acceptance criteria differs between MTAs. Abusers depend upon this to generate DSNs that act as a delivery vehicle of abusive messages masquerading as DSNs with spoofed return-paths. While simulating point-to-point operation would be one (expensive) approach at solving this problem, some have suggested the use of SPF records to qualify the return-path before accepting the message. The qualified return-path approach has several problems. It may require more than 100 sequential lookups to fully resolve a complete address list, which is often open-ended. These address lists remain open-ended, as there are many legitimate cases where this qualification still fails. As of yesterday, there is no record in use with a scope specifically defined to qualify the return-path. BATV on the other hand solves the DSN exploit without waiting for anyone else to adopt some practice. Although there is a small window where the BATV return-path could be replayed, such illegal activity can be traced. Neither Sender-ID nor DKIM will solve this serious exploit either. While many AV products are a nuisance as they enable this DSN exploit which actually spreads viruses (#$%&*), solving this problem does not require changing the nature of SMTP and dramatically affecting every email system, or even hoping everyone qualifies the return-path prior to acceptance. BATV is really a simple and effective solution that should be put in place now. -Doug
Re: Viral Cure Could 'Immunise' The Internet
On Friday 09 Dec 2005 14:57, you wrote: > > a mathematical study is going to come up with a result that is more > meaningful. The story is badly headlined. The study is saying how many "canaries" do we need to keep the Internet safe, or how big the immune system needs to be, not about a viral cure as such. It says to keep the infection rate of new malware down to a fraction of a percent we'd need about a million or so machines looking for malware (on some assumptions). Should convince someone that we need to change the assumptions. Hopefully the modelling says something about what factors it is sensitive to. It does however remind me of the comparison of engineering and science, a scientist will earn a living by taking a really difficult problem and spends many years solving it, an engineer earns a living by finding really difficult problems and side stepping them.
Re: Viral Cure Could 'Immunise' The Internet
[EMAIL PROTECTED] wrote: Thought folks might find this interesting http://www.newscientist.com/article.ns?id=dn8403 Viral Cure Could 'Immunise' The Internet, New Scientist Excerpts: A cure for computer viruses that spreads in a viral fashion could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Most conventional anti-virus programs use "signatures" to identify and block viruses. But experts must first analyse a virus before sending out the fix. This means that rapidly spreading viruses can cause widespread damage before being stopped. Source: Viral Cure Could 'Immunise' The Internet, Kurt Kleiner, NewScientist, 05/12/01 Sounds like: "I make your computer part of my botnet - only to prevent you from becomming part of somebodyelses botnet." How do I discriminate a real virus from a preventive one? I mean, how do I forge my virus so that you believe it is a preventive one? How about biology? AIDS works by attacking the immune system. If we had no white blood vessels there would be no AIDS. Some vermin does already use Anti Virus Systems to spread. Ok, if they use their preventive virus to kill all windows out there and replace it with a linux? Yes, that might be an idea. That would really stop the virus. ;) -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr
Re: Viral Cure Could 'Immunise' The Internet
At 9:30 -0500 12/9/05, [EMAIL PROTECTED] wrote: Thought folks might find this interesting http://www.newscientist.com/article.ns?id=dn8403 Viral Cure Could 'Immunise' The Internet, New Scientist Excerpts: A cure for computer viruses that spreads in a viral fashion could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Most conventional anti-virus programs use "signatures" to identify and block viruses. But experts must first analyse a virus before sending out the fix. This means that rapidly spreading viruses can cause widespread damage before being stopped. Source: Viral Cure Could 'Immunise' The Internet, Kurt Kleiner, NewScientist, 05/12/01 This has been thought of many times. My spin around this was attached to DARPA's Active Network (http://www.darpa.mil/ato/programs/AN/). The eternal question in security is "what are you defending against?" Because of that, security will always have a strong reactionary element. I can't cite any, but I recall hearing some claims that viruses in the past were meant to fix problems or highlight in a benign way the presence of problems. It's been tried in real life, I don't see that a mathematical study is going to come up with a result that is more meaningful. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
Re: Viral Cure Could 'Immunise' The Internet
[EMAIL PROTECTED] wrote: Thought folks might find this interesting http://www.newscientist.com/article.ns?id=dn8403 Viral Cure Could 'Immunise' The Internet, New Scientist Excerpts: A cure for computer viruses that spreads in a viral fashion could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Most conventional anti-virus programs use "signatures" to identify and block viruses. But experts must first analyse a virus before sending out the fix. This means that rapidly spreading viruses can cause widespread damage before being stopped. Source: Viral Cure Could 'Immunise' The Internet, Kurt Kleiner, NewScientist, 05/12/01 Skynet becoming self-aware anyone? -- Andre
Viral Cure Could 'Immunise' The Internet
Thought folks might find this interesting http://www.newscientist.com/article.ns?id=dn8403 Viral Cure Could 'Immunise' The Internet, New Scientist Excerpts: A cure for computer viruses that spreads in a viral fashion could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Most conventional anti-virus programs use "signatures" to identify and block viruses. But experts must first analyse a virus before sending out the fix. This means that rapidly spreading viruses can cause widespread damage before being stopped. Source: Viral Cure Could 'Immunise' The Internet, Kurt Kleiner, NewScientist, 05/12/01
The Cidr Report
This report has been generated at Fri Dec 9 21:46:44 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
02-12-05173338 115455
03-12-05173496 115437
04-12-05173359 115462
05-12-05173453 115444
06-12-05173453 115376
07-12-05173358 115368
08-12-05173369 115518
09-12-05173462 115525
AS Summary
21018 Number of ASes in routing system
8719 Number of ASes announcing only one prefix
1924 Largest number of prefixes announced by an AS
AS8151 : Uninet S.A. de C.V.
91245568 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 09Dec05 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 175158 1158105934833.9% All ASes
AS8151 1924 537 138772.1% Uninet S.A. de C.V.
AS4323 1184 236 94880.1% TWTC - Time Warner Telecom
AS18566 8828 87499.1% COVAD - Covad Communications
AS4134 1004 249 75575.2% CHINANET-BACKBONE
No.31,Jin-rong Street
AS721 1056 313 74370.4% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS22773 589 35 55494.1% CCINET-2 - Cox Communications
Inc.
AS855564 66 49888.3% CANET-ASN-4 - Canadian
Research Network
AS19916 563 65 49888.5% ASTRUM-0001 - OLM LLC
AS7018 1458 963 49534.0% ATT-INTERNET4 - AT&T WorldNet
Services
AS3602 532 104 42880.5% SPRINT-CA-AS - Sprint Canada
Inc.
AS6197 969 579 39040.2% BATI-ATL - BellSouth Network
Solutions, Inc
AS11492 632 252 38060.1% CABLEONE - CABLE ONE
AS17676 470 101 36978.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS17488 428 70 35883.6% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS6467 406 49 35787.9% ESPIRECOMM - e.spire
Communications, Inc.
AS812370 27 34392.7% ROGERS-CABLE - Rogers Cable
Inc.
AS4755 603 275 32854.4% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS4766 616 289 32753.1% KIXS-AS-KR Korea Telecom
AS9498 415 91 32478.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS15270 347 30 31791.4% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS9583 835 520 31537.7% SIFY-AS-IN Sify Limited
AS14654 2926 28697.9% WAYPORT - Wayport
AS16814 295 31 26489.5% NSS S.A.
AS6167 326 63 26380.7% CELLCO-PART - Cellco
Partnership
AS9929 319 56 26382.4% CNCNET-CN China Netcom Corp.
AS5668 489 227 26253.6% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS11172 396 135 26165.9% Alestra
AS18101 280 23 25791.8% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS6140 431 189 24256.1% IMPSAT-USA - ImpSat
AS1239 833 592 24128.9% SPRINTLINK - Sprint
Total 19508 61811332768.3% Top 30 total
Possible Bogus Routes
24.246.0.0/17AS7018 ATT-INTERNET4 - AT&T WorldNet Services
24.246.78.0/24 AS25994 NPG-001 - NPG Cable, INC
24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services
64.17.32.0/24AS13488 CBWU-13488 - Continental B
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Thursday 08 Dec 2005 18:08, Douglas Otis wrote:
>
> When accepting messages from anonymous sources, seldom does one know
> the source.
On the contrary, short of the tricks played on AOL to defeat their original
antispam system, TCP means you always know the source.
We manage to filter out ~98% of the unwanted email here with very nearly 100%
accuracy at the SMTP transaction stage with low processor overhead on our new
email servers. At which point any backscatter from what gets through is
trivial, although alas there still is a little due to evil practices of the
past in then forwarding email elsewhere.
But the point of this discussion is that SMTP will have to evolve to be a
point to point system (or functional equivalent). The days of store and
forward in intermediate MTAs should die as quickly as possible (which as our
forwarding demonstrates may be quite slowly alas). The problem is that many
of the antivirus gateways behave like new intermediate MTAs, especially when
for many of the organisations involved it could easily be done during SMTP
transactions.
The remaining issue is how much resource it costs to do your spam/malware
detection, but I believe trying to do anything beyond policy enforcement ("no
EXE/PIF/SCR here please") in terms of malware detection in the MTA is a
mistake, especially when you only really need to protect the thick(!)
clients, and they still need to be protected when the content is
zipped/encrypted/novel/zipped+encrypted+novel etc.
This thread on the other hand should move to Spam-L.
