Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
This is pointless argument, please stop There are those who think they are right in spamming people with reports of a virus they didn't send and the rest of the planet who think they are mad and wish they'd get a clue. 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? because that superior knowledge has already thrown them all away without looking any slight chance of one being valid is wasted If the AV systems that know they are dealing with forged senders, which they do, just dropped them then the volume of potentially valid ones may be low enough that we wouldn't just bin them all If you make it hard we will ignore it. brandon
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Robert, sorry I missed the full conversation, and don't have time to read the whole thread, but based on your mail alone a few words of agreement... Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command (which is why I have gone to great lengths to ensure this happens at $employer, and at SORBS).. Failure to have the resources available to perform the virus scanning will result in the messages being delivered to the recipient as a broken message (attachment stripped). There is certainly NO EXCUSE for ANYONE to bounce virus warning messages to ANY user whether local or remote, particularly when the anti virus software will identify the virus and the virus is KNOWN to forge the sender address. As such anyone bouncing large numbers virus warning messages are game for having their servers blocked, and I will not apologise to anyone getting caught by a SORBS automated spamtrap getting a virus warning message (though I will remove them promptly when notified of such an entry). Regards, Mat
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Matthew Sullivan wrote: Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command rfc2821 was written prior to this problem we should also take the rfc in context and differentiate between email sent between individuals for which the responsibility applies, and email generated by systems (spam, virus bounces) in which we the providers carry some responsibility to drop them (okay, it would be better if they didnt exist in the first place, but thats not reality) if they can be identified in the best interests of the user to not do this is like saying we have a responsibility to ensure end to end delivery of packets in a DoS attack just because the rules governing routing and ip stacks dont explicitly cover the use of sinks and filters. Steve
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Date: Fri, 9 Dec 2005 15:08:49 -0800 From: Douglas Otis [EMAIL PROTECTED] Subject: Re: SMTP store and forward requires DSN for integrity On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote: [ ... ] 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, It's amazing Mike, can you pass me that crack-pipe ! *any* anti-virus vendor has not only signatures of a specific virus but also a good understanding of what the virus does and how it spreads. If the vendor doesn't, well, they'd better retire from the AV business, because as a vendor they should be able to tell me that. (you know, me customer, you vendor, I give money for features I want) If you want to send DSN's telling people they send out a virus, do so only for viruses which are known *not* to forge or even better, which don't have any SMTP engines of their own. Well, how many of those still wander round ? And how many of those can be found by *outbound* scanning on mailservers at the originating party ? [ ... ] Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem? Right now dumb AV filtering is akin to a Smurf amplifier. Essentially the AV vendors are DDoS'ing each and every mailserver out there. Great, now a little question, why not inform the recipient of the mails that the AV solution stopped another virus heading their way ? Would be great advertising, see Mr CIO, you have 500 new mails in the last hour, 490 are about how our mailserver stopped all them viruses ! Last month alone, my Spam folder (at work) counted over 80% AV mails. Guess how large that folder has become because of that ? I've jumped from around 1GB normally up to almost 3GB. That jump can be attributed to AV filters everywhere. You'd almost think the AV vendors have a rather large stock in bandwith and storage providers. [ ... ] 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. Save costs ? Sure I wanna save costs. And mind you the most expense isn't in the storage for e-mail for my end users, it's in the cost of me making sure we don't get blacklisted by every other selfrespecting mailserver in the world. Hence we drop virus mails, we log them, and the *recipients* can get a mail telling them a virus was stopped. However we put that into a seperate IMAP folder and not in the INBOX. There's no need to Spam both sender and recipient. The recipient on our end can check to see if a message towards them was stopped if they were expecting something. Now viruses aren't the only scourge, I know, but the AV vendors are hard underway to destroy e-mail as a communications tool, where previously this was the doing of Spammers. I don't think any AV vendor would consider themselves more evil then Spammers, Phishers or scriptkiddies, but they will be if they don't act more responsibly. Regards, JP Velders
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
From [EMAIL PROTECTED] Sat Dec 10 06:58:38 2005 Date: Sat, 10 Dec 2005 12:57:34 + (GMT) From: Stephen J. Wilcox [EMAIL PROTECTED] Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Sat, 10 Dec 2005, Matthew Sullivan wrote: Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command rfc2821 was written prior to this problem Systems which 'silently discard' virus-infected messages for policy reasons are not in violation of RFC 2821, nor even the obseleted 821. Delivery of a message does NOT require that the message hit a person's in box. Trivial proof: mail to an 'autoresponder'. 'Delivery' of any message is handled in accordance with 'policy' established at the receiving site. If policy dictates that that message be routed to the bit-bucket, rather than to the user's mailbox, that message *IS* considered 'delivered', within the context of RFC 2821. we should also take the rfc in context and differentiate between email sent between individuals for which the responsibility applies, and email generated by systems (spam, virus bounces) in which we the providers carry some responsibility to drop them (okay, it would be better if they didnt exist in the first place, but thats not reality) if they can be identified in the best interests of the user to not do this is like saying we have a responsibility to ensure end to end delivery of packets in a DoS attack just because the rules governing routing and ip stacks dont explicitly cover the use of sinks and filters. Steve
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: When there is some percentage of false-positive detection, I'm *loving* your crack-induced comedy. Troll it up, bay-bee! Show me the false positive rate. If you can prove any site with more than 0.1% FP on malware detection with any off the shelf product, I'll give you a magic cookie. Abusing the rest of the world does *not* justify saving the single, incredibly improbable, FP in comparison. Abuse is abuse; it's not up to millions of receiving hosts to put up with the abuse happily because of your hallucinogenic false positive. Put down the crackpipe and walk away from the keyboard before you say something else your employer will regret. (These might be your opinions, but it's telling if a company continues to employ someone who doesn't understand said company's market at all, in spite of any disclaimers.) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 2005-12-10 at 15:40 +0100, JP Velders wrote: *any* anti-virus vendor has not only signatures of a specific virus but also a good understanding of what the virus does and how it spreads. If the vendor doesn't, well, they'd better retire from the AV business, because as a vendor they should be able to tell me that. (you know, me customer, you vendor, I give money for features I want) With the high prevalence of viruses having a forged return-path, the concern is largely about _false_ detections. These are not actual numbers, but perhaps more realistic than figures suggested previously. Imagine the false positive error rate for an email AV filter runs about 1 in 1000 malwares. While indeed this may not be a tragedy having a few valid emails lost without notice in an AV effort, this loss is not required when valid DSN recognition is deployed. The AV filter then bounce technique has been used for many years, where DSNs must be filtered at the DSN recipient. Rather than seemingly fruitless complaining, automate this process to refuse invalid DSNs before the data phase, and prevent the DoS effects. This automation will also recover the valid 1 in 1000 DSNs. This BATV automation would also ensure no DSNs with forged return-paths, created at any point where acceptance criteria differs between MTAs, will be accepted before the data phase. BATV should be almost as effective as a DNS-BL. You can even use automate BATV refusals by others to add to your own temp BL. Now viruses aren't the only scourge, I know, but the AV vendors are hard underway to destroy e-mail as a communications tool, where previously this was the doing of Spammers. I don't think any AV vendor would consider themselves more evil then Spammers, Phishers or scriptkiddies, but they will be if they don't act more responsibly. Consider forged DSN automated detection before data phase as an opportunity to improve upon the integrity of email delivery, while also preventing the DoS situation. BATV can be implemented where the implementer sees the benefits immediately. When widely deployed, the back-scatter problem dissolves, as forged DSNs will not serve as an exploit, but rather acts as a trap. Once again valid DSNs regain their rightful respectability as needed in any store and forward system. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Douglas Otis wrote: With the high prevalence of viruses having a forged return-path, the concern is largely about _false_ detections. These are not actual numbers, but perhaps more realistic than figures suggested previously. Imagine the false positive error rate for an email AV filter runs about 1 in 1000 malwares. While indeed this may not be a tragedy having a few valid emails lost without notice in an AV effort, this loss is not required when valid DSN recognition is deployed. The loss is also not required when virus/malware scanning is done during the SMTP conversation. Google for QHPSI. Messages don't have to disappear and bogus DSNs don't have to be sent. People just need to modernize their MTAs. The AV filter then bounce technique has been used for many years, where DSNs must be filtered at the DSN recipient. Rather than seemingly Like many other things on the internet, just because it's been in place for many years doesn't mean its a good idea or still a viable system. will also recover the valid 1 in 1000 DSNs. This BATV automation would also ensure no DSNs with forged return-paths, created at any point where acceptance criteria differs between MTAs, will be accepted before the data phase. BATV should be almost as effective as a DNS-BL. You can even use automate BATV refusals by others to add to your own temp BL. That still leaves our (the people not sending bogus DSNs) systems having to do lots of work (validating signitures) to decide how to handle DSNs that should never have been sent. Interesting that you should mention DNSBLs. I've seen people asking for DNSBLs of bogus DSN senders for years. I hope the integration of AV filtering and MTAs will improve before we see widespread use of bogus DSN sender DNSBLs. Unfortunately, for some people, experiencing pain is the only way they can be convinced to clean up their problems. -- 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 )
On Fri, Dec 09, 2005 at 09:03:10AM -0800, 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. BATV is not a solution. It's a band-aid. It fails to address the underlying problem and instead focuses on merely trying to cope with one of the symptoms of that problem. And it also places the burden on the people who are NOT PART OF THE PROBLEM, and who therefore should not be the ones tasked with solving it. The solution isn't to try to figure out what to do with UBE generated by broken mail systems, broken anti-spam systems, broken anti-virus systems, and the like; the solution is to fix those systems so that they don't generate it. The best place to stop spam is as near its source as possible goes the maxim, and THE best place IS its source. This is not hard. It's been discussed at extraordinary length on spam-l, and one of the outcomes of those discussions is that while there are some edge cases that can be tough (depending on mail system architecture) those are a tiny minority, and the overwhelming majority can be dealt with quickly and easily. I would strongly suggest that anyone wishing to continue this discussion (a) read the archived discussion thoroughly and (b) take it up on spam-l, where it's probably more appropriate and where huge amounts of relevant clue exist among participants. ---Rsk
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
MS Date: Sat, 10 Dec 2005 22:54:24 +1100 MS From: Matthew Sullivan MS RFC 2821 states explicitly that once the receiving server has issued a 250 MS Ok to the end-of-data command, the receiving server has accepted MS responsibility for either delivering the message or notifying the sender MS that it has been unable to deliver. RFC2821 also says that a message MUST And RFC 1034/1035 (I forget which) specifies an RD bit which, in reality, is rather useless. Following RFCs is good for compatibility. However, RFCs are hardly infallible word from on high. Sometimes they require revisiting and revision. 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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
DO Date: Fri, 9 Dec 2005 15:08:49 -0800 DO From: Douglas Otis DO This is a third-party acting in good faith, albeit performing a check better DO done within the session. In your view, there is less concern about delivery DO integrity, and so related DSNs should be tossed. Being done within the DO session would be ideal, of course. When their architecture does not support Let's use some hyperbole: Say that the latest megaworm chucks out spam at speeds resembling SQL Slammer. The return-path specified is your email address. Millions of MXes send _you_ bogus DSNs in good faith. Is this acceptable? If not, where do you draw the line -- and does that line apply to others, too? 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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Edward B. Dreger wrote: Let's use some hyperbole: Say that the latest megaworm chucks out spam at speeds resembling SQL Slammer. The return-path specified is your email address. Millions of MXes send _you_ bogus DSNs in good faith. That's not exactly hyperbole. My antivirus-spew counter on my 9-user SMTP server rolled past 1M more than a year ago. Per incident, it isn't more than 1M; moire like ~50k, but that is still well beyond DDoS level. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
mary wrote: mta test anyone? [snip Eicar signature] You didn't attach it. If you had, I'm pretty sure Exim (running an ACL plugged into ClamAV) would have caught it before it got to my Inbox. Clam detects Eicar just fine. : What you did was include it inline in a text/plain MIME part in your message, where it isn't likely that it could do any harm even if it *was* a real virus. -- 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 )
[snip Eicar signature] You didn't attach it. If you had, I'm pretty sure Exim (running an ACL plugged into ClamAV) would have caught it before it got to my Inbox. Clam detects Eicar just fine. : :) I did receive two your message contains a virus replies. One was a Panda GateDefender, sounds Windowsish. What you did was include it inline in a text/plain MIME part in your message, where it isn't likely that it could do any harm even if it *was* a real virus. nods real harm/mass traffic not intended -m
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: 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: 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, 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 )
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, 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, 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, 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, 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 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 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
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 )
- Original Message - From: Geo. [EMAIL PROTECTED] To: nanog@merit.edu 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 )
- Original Message - From: Geo. [EMAIL PROTECTED] To: nanog@merit.edu 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: 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]darwin 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 (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 )
- Original Message - From: Matt Ghali [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED] Cc: nanog@merit.edu 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]darwin 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 )
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 )
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 )
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu 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 )
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu 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 )
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: Micheal Patterson [EMAIL PROTECTED] To: Douglas Otis [EMAIL PROTECTED]; Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu 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]; nanog@merit.edu 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.
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 )
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 )
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! /sarcasm 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. 5) SMTP should appear to be point-to-point. An
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: 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 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
