Re: SMTP store and forward requires DSN for integrity
On 12 Dec 2005, at 15:50, John Levine wrote: And BATV will never be widely deployed because it breaks every single system out there that keys off the return path. And there are a lot of these systems. I keep hearing that, but other than a few ezmlm lists and the occasional tired fax gateway, I never run into them. Where are they? I can't enumerate them all for you - I don't know them all. That's the point though - you can't know all the systems you may be breaking by changing the way your MAIL FROM works. Here's a few that I've told you about before: Whitelist/Blacklist entries Quarantine systems Anything based on .qmail files Some auto-forwarders Auto-responders Now you can potentially whitelist around these issues (to some extent), but while that works for geek mail systems it doesn't scale up very well. I know you (personally) whitelist around some problem systems in your implementation but can you expect Grandma to do that? Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: SMTP store and forward requires DSN for integrity
On 10 Dec 2005, at 16:54, Douglas Otis wrote: The BATV is a few lines of code that adds a private tag with a time limit set in days. BATV helps dramatically by eliminating the DATA phase and all that is involved in handling messages. In addition, once BATV becomes more widely deployed, the DSN refusal offers an alert about accepting more such messages from that IP address. BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. And BATV will never be widely deployed because it breaks every single system out there that keys off the return path. And there are a lot of these systems. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: SMTP store and forward requires DSN for integrity
I agree with nearly all of your analysis, but want to add a few small points of my own. On Sun, Dec 11, 2005 at 04:53:03AM -0600, Micheal Patterson wrote: > Can BATV correct this? Possibly. After reading further and thinking about it: I believe the answer isn't "possibly", but "almost certainly not". Consider the ~100M zombies (hijacked Windows systems) out there. Mail traffic emitted by any malware resident on them is externally indistinguishable from mail traffic emitted by their former owners (operating under the misconception that it's still "their" computer). Nos suppose for a moment that we had Email Magic Bullet Technology (EMBT) which enabled us to trace any/all messages back to their origination point. And suppose that 100,000 sites out there (using some form of reliable malware detection) independently using EMBT conclude that they have received copies of the Microsoft Windows virus du jour from [EMAIL PROTECTED] at IP address 1.2.3.4. Thus all 100,000 sites are now in a position, if they wish, to emit a DSN addressed to [EMAIL PROTECTED] stating "you have virus blah blah version blah blah" etc. My first observation is that emitting these DSNs, even *with* EMBT, is a pointless exercise. Doing so increases, yet again, the volume of useless mail traffic traversing the Internet. It's just more self-promoting spam from AV vendors -- it's not like anyone actually _reads_ this stuff. And even if they did: who's going to read 100,000 messages? My second observation is that the combined volume of these DSNs may constitute a rather effective DDoS on example.com's MXs. My third observation is that such DDoS attacks could easily be redirected against third party mail servers by manipulation of MX records. 4. (I got tired of saying "my Nth observation") I'm beginning to conclude that any technology which causes A, in response to traffic from B, to generate traffic to C, is probably not a good idea. 5. Keep in mind that malware resident on a hijacked system is in complete control of the box and thus has access to any cryptographic keys in use as well as any incoming mail being retrieved with POP/IMAP. So even if we presume the existence of a clueful and attentive user (then why is the box in a hijacked state?) there is no guarantee that the DSNs will actually be presented to the user. 6. How is a recipient of a DSN to know that it's authentic? After all, the fact that EMBT enables someone to generate a DSN in response to received virus-contaminated traffic doesn't prevent anyone else from generating a DSN in response to...nothing. Consider a piece of malware which generates such DSNs and its impact on an EMBT. 7. All of the problems cited above become much more interesting if the hijacked box isn't an end-user system, but a mail server. 8. (similar to observation 4) Adding more positive feedback loops to an Internet-wide mail system that already carries far too much junk traffic is a bad move. We need to dampen, not amplify. ---Rsk
Re: SMTP store and forward requires DSN for integrity
On 12/11/05, Micheal Patterson <[EMAIL PROTECTED]> wrote: > If malware detection systems would not generate a DSN to the originator > upon detection in the first place, there would be no need to reduce > those transactions as there would be no transactions to reduce. The That is a big if. No shortage of broken software / appliance etc products put out by different vendors Even if they do introduce patches for current versions or release new versions that dont backscatter to spoofing viruses, there's a huge installed base of crap old versions of this stuff. So, fixing that lot is not going to be easy. Sending BATV signed email out and accepting bounces to BATV'd addresses does tend to make sense in a limited set of use cases (IF you send email only from a single server / set of servers, and control the sending client . geeks with pine on *bsd or webmail service providers, or mailing list services that anyway do VERP) Upgrade MTAs around the world? Which MTAs around the world receive bounces bound for your domain, and to your servers? And which MTAs send legitimately send out email with your domain? If you are SURE that all that is covered, try BATV and it will work rather well for you. If you aren't - dont bother about it. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: SMTP store and forward requires DSN for integrity
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Andrew - Supernews" <[EMAIL PROTECTED]> Cc: Sent: Saturday, December 10, 2005 3:54 PM Subject: Re: SMTP store and forward requires DSN for integrity On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. I agree with most of your statements. AV filters should be done within the session when possible, etc. Your statement regarding BATV is not correct however. There are two ways BATV reduces SMTP transaction volume when dealing with forged DSNs. "... BATV reduces SMTP transaction volume when dealing with forged DSNs." If malware detection systems would not generate a DSN to the originator upon detection in the first place, there would be no need to reduce those transactions as there would be no transactions to reduce. The solution, to me, seems so simple, I must be overlooking something or not comprehending fully what the issue truly is. I thought that the initial problem was with AV mechanisms sending out DSN's to incorrect sender addresses. Please, if I'm so far off base, would someone be so kind as to email me off list and clear this up for me? Honestly Doug, you do realize that your reluctance to stop the problem at the source conveys to everyone on this list the impression that you're only trying to gain support for your proposal don't you? Let's take the malware and av scanners out of the picture for a moment. There was a time, long ago, where malware didn't exist in the email network. At that time, when a message was undeliverable, a DSN was sent to the originator of the message. It happens. Typo's and such. No one complained. Why? Because legitimate email, in order to function requires a valid email address for both parties. Why would they falsify it if they wish to communicate? Now, let's look at it as of "today". If someone sends someone a virus, intentionally, it's main purpose is to get to as many systems as it possibly can, as fast as it can to allow the software to propagate before it's detected by AV software. Do you REALLY think that the initial sender wishes to be told that he sent a virus? Do you really believe he/she wishes to even be known or contacted by you in any way? Of course not. Then why do these systems still attempt to send these notices? Well after all logical reasoning has indicated that the sender is forged. The software of today has no way of knowing if the originating system is the actual system that's introduced it into the wild or a carrier. It has no way to validate the email address of the sender. Can BATV correct this? Possibly. But at what cost Doug? How much will it cost them to get the latest and greatest so that they can implement BATV? How much down time will they have to deal with to implement it? Multiply that by the millions of mta's around the globe. Now, you tell me Doug, which is easier for everyone to do? Upgrade/update their mta's around the world or have those few AV detection vendors recode their software? I don't know about you, but if what little information I've found on BATV is current, most folks will have to switch to Exim or NetQmail just to get it to work currently. There's a lot of postfix and sendmail networks out there that may not want to switch. What happens to them? Mike P.
Re: SMTP store and forward requires DSN for integrity
> "Douglas" == Douglas Otis <[EMAIL PROTECTED]> writes: >> BATV doesn't help you if the problem is SMTP transaction volume, >> any more than a firewall will help you cope with a saturated >> network link. Douglas> Your statement regarding BATV is not correct however. There Douglas> are two ways BATV reduces SMTP transaction volume when Douglas> dealing with forged DSNs. When you're dealing with 30 million incoming DSNs (this is not a hypothetical figure), being able to reject them all at RCPT TO is not much help. I don't see why I should have to engineer my mail server to handle 5,000 times its expected workload just to accomodate all the bozos who accept-and-bounce, uncontrolled backscatter, "sender verification", C/R, and all the other cost-shifting methods out there. -- Andrew, Supernews http://www.supernews.com
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. real harm/mass traffic not intended -m
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
On Sat, 2005-12-10 at 17:51 -0600, Robert Bonomi wrote: > BATV has the risk of false-positive detection of an 'invalid' DSN. > All it takes is a remote mail system that keeps 'trying' to deliver to > a tempfailing address for _longer_ than the lifetime of that 'private > tag'. > > Congratulations, you have just blocked a *valid* DSN failure notice. The expiry period of the tag is determined by the MSA of the message. Setting this period for more than 5 days should extend beyond retry efforts, so make it ten days. > Your approach has just demonstrably 'impaired the integrity of the email > system'. The tag only needs a reasonable expiry controlled by the MSA. Exhaustion of delivery retry are getting shorter. > Remember, the putative sender (the person, not the software) is the > best judge of whether or not that NDR is a delayed response to a message > they sent. Why not take advantage of that superior knowledge? Tagging of the return-path address would be transparent to the author. They would not even see this change, nor would they ever see any DSNs for messages they did not send. They would be protected from bounced malware and other forms of abuse using this avenue of entry. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
mta test anyone? [EMAIL PROTECTED](P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Re: SMTP store and forward requires DSN for integrity
> From [EMAIL PROTECTED] Sat Dec 10 16:56:38 2005 > Date: Sat, 10 Dec 2005 17:55:38 -0500 (Eastern Standard Time) > From: Todd Vierling <[EMAIL PROTECTED]> > To: nanog@merit.edu > Subject: Re: SMTP store and forward requires DSN for integrity > > > On Sat, 10 Dec 2005, Douglas Otis wrote: > > > BATV will make forged DSNs a thing of the past, irrespective of where a > > recipient list is checked, an AV or SPAM filter is added, etc. > > Stop plugging a recipient-side cost-shift scheme that you're directly > involved with as some sort of panacea. BATV has benefits, as do other > schemes, but you're still fixated on it as being the end-all, be-all of > forgery prevention -- by making third parties do the dirty work and letting > the instigators off the hook. > > By putting the costs on the shoulders of third parties, you're putting > yourself squarely on the side of the spewing hosts, and being as ignorant as > the admins running the anti-malware products on those hosts. For shame. > I recommend to all a review of the "Rules of Spam". Rule #1, in particular. Specifically the "Lexical Contradiciton" and "Sharp's Corollary". We seem to have yet another example for the 'rules-keeper's refrain'. *sigh* Considering the source of _this_ demonstration, one can only despair -- what possible chance is there for things to 'get better', when one of the putatively 'good guys' espouses that kind of double-think?
Re: SMTP store and forward requires DSN for integrity
> From [EMAIL PROTECTED] Sat Dec 10 15:55:48 2005 > Subject: Re: SMTP store and forward requires DSN for integrity > From: Douglas Otis <[EMAIL PROTECTED]> > To: Andrew - Supernews <[EMAIL PROTECTED]> > Cc: nanog@merit.edu > Date: Sat, 10 Dec 2005 13:54:37 -0800 > > > On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: > > > BATV doesn't help you if the problem is SMTP transaction volume, any > > more than a firewall will help you cope with a saturated network link. > > I agree with most of your statements. AV filters should be done within > the session when possible, etc. > > Your statement regarding BATV is not correct however. There are two > ways BATV reduces SMTP transaction volume when dealing with forged > DSNs. > > Previous return-path and real email-address: > <[EMAIL PROTECTED]> > > Is transformed by BATV with a private tag into: > prvs=fred/@example.com > > S: 220 mail.example.com ESMTP Ready > C: EHLO fred.example.com > S: 250-mail.example.com Hello fred.example.com > S: 250-ENHANCEDSTATUSCODES > S: 250-PIPELINING > S: 250-8BITMIME > S: 250-SIZE 2000 > S: 250-DSN > S: 250-ETRN > S: 250-AUTH PLAIN LOGIN > S: 250-STARTTLS > S: 250-DELIVERBY > S: 250 HELP > C: MAIL FROM: <> > S: 250 2.1.0 <>... Sender ok > C: RCPT TO: <[EMAIL PROTECTED]> > S: 550 5.1.1 ... User unknown > C: QUIT > > > When the MAIL FROM is <>, the only valid RCPT TO would be a BATV address > such as: > > ... > C: RCPT TO: > S: 250 2.1.5 ... Recipient ok > C: DATA > S: 354 Enter mail, end with "." on a line by itself > C: This is a notification you sent a virus to at ... > C: Blah, Blah, Blah, and by the way, here is the virus. ... > C: ... > C: . > S: 250 2.0.0 234fls89056789 Message accepted for delivery > C: QUIT > > The BATV is a few lines of code that adds a private tag with a time > limit set in days. BATV helps dramatically by eliminating the DATA phase > and all that is involved in handling messages. In addition, once BATV > becomes more widely deployed, the DSN refusal offers an alert about > accepting more such messages from that IP address. > > BATV will make forged DSNs a thing of the past, irrespective of where a > recipient list is checked, an AV or SPAM filter is added, etc. TWO FACED, DOUBLE STANDARD, "SPEAKS WITH FORKED TONGUE". BATV has the risk of false-positive detection of an 'invalid' DSN. All it takes is a remote mail system that keeps 'trying' to deliver to a tempfailing address for _longer_ than the lifetime of that 'private tag'. Congratulations, you have just blocked a *valid* DSN failure notice. Your approach has just demonstrably 'impaired the integrity of the email system'. Strange, isn't it, that your "solution" will do exactly what you insist is utterly unacceptable behavior for any other approach. Remember, the putative sender (the person, not the software) is the best judge of whether or not that NDR is a delayed response to a message they sent. Why not take advantage of that superior knowledge?
Re: SMTP store and forward requires DSN for integrity
On Sat, 10 Dec 2005, Douglas Otis wrote: > BATV will make forged DSNs a thing of the past, irrespective of where a > recipient list is checked, an AV or SPAM filter is added, etc. Stop plugging a recipient-side cost-shift scheme that you're directly involved with as some sort of panacea. BATV has benefits, as do other schemes, but you're still fixated on it as being the end-all, be-all of forgery prevention -- by making third parties do the dirty work and letting the instigators off the hook. By putting the costs on the shoulders of third parties, you're putting yourself squarely on the side of the spewing hosts, and being as ignorant as the admins running the anti-malware products on those hosts. For shame. Until you get the point that you're putting the burden on people that have nothing to do with the problem that started this long thread (anti-malware notices to forged senders), and your first priority should be stopping that spew at the source BEFORE asking uninvolved third parties to help, you're going to continue to look like the self-absorbed crack smoker you've made yourself out to be. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: SMTP store and forward requires DSN for integrity
On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: > BATV doesn't help you if the problem is SMTP transaction volume, any > more than a firewall will help you cope with a saturated network link. I agree with most of your statements. AV filters should be done within the session when possible, etc. Your statement regarding BATV is not correct however. There are two ways BATV reduces SMTP transaction volume when dealing with forged DSNs. Previous return-path and real email-address: <[EMAIL PROTECTED]> Is transformed by BATV with a private tag into: prvs=fred/@example.com S: 220 mail.example.com ESMTP Ready C: EHLO fred.example.com S: 250-mail.example.com Hello fred.example.com S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-8BITMIME S: 250-SIZE 2000 S: 250-DSN S: 250-ETRN S: 250-AUTH PLAIN LOGIN S: 250-STARTTLS S: 250-DELIVERBY S: 250 HELP C: MAIL FROM: <> S: 250 2.1.0 <>... Sender ok C: RCPT TO: <[EMAIL PROTECTED]> S: 550 5.1.1 ... User unknown C: QUIT When the MAIL FROM is <>, the only valid RCPT TO would be a BATV address such as: ... C: RCPT TO: S: 250 2.1.5 ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: This is a notification you sent a virus to at ... C: Blah, Blah, Blah, and by the way, here is the virus. ... C: ... C: . S: 250 2.0.0 234fls89056789 Message accepted for delivery C: QUIT The BATV is a few lines of code that adds a private tag with a time limit set in days. BATV helps dramatically by eliminating the DATA phase and all that is involved in handling messages. In addition, once BATV becomes more widely deployed, the DSN refusal offers an alert about accepting more such messages from that IP address. BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. -Doug
Re: SMTP store and forward requires DSN for integrity
> "JP" == JP Velders <[EMAIL PROTECTED]> writes: JP> Right now dumb AV filtering is akin to a Smurf amplifier. Good analogy. I would extend it by pointing out that "dumb AV filtering" is actually only a part of the general backscatter problem. The existence of BATV isn't an excuse for mail system operators to ignore the backscatter problem any more than the existence of stateful firewalls is an excuse for people to run smurf amplifiers. Right now, unless you are a large provider or corporate, or unless your mail system is massively over-engineered, any spammer can, at any time, drown you in bounces (30 million SMTP transactions in response to one spam run has been observed in practice). BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. It is, in my view, the responsibility of every mail system operator to design and operate their systems in such a way as to minimize the impact of backscatter on innocent third parties. This is not to say that DSNs should not be sent (because that would indeed cause an integrity problem) but that they should be avoided. Forged virus backscatter is just one of the more trivial examples (trivial because much of it is caused by A/V systems that _know_ they should not be doing it); there are many other sources of backscatter that are not specific to viruses, most of which can easily be controlled by proper feedback to the SMTP server (e.g. accounts which go over quota and _stay_ that way should be set to reject traffic at SMTP time, so that they don't become continuous sources of backscatter). -- Andrew, Supernews http://www.supernews.com
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 )
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 )
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 )
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 )
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 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 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 )
> 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 )
> 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 )
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 )
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 )
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 )
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: 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
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.
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: 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: 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
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: 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
