SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500 SMB> From: Steven M. Bellovin SMB> A-V companies are in the business of analyzing viruses. They should SMB> *know* how a particular virus behaves. The cynical would say they _do_ know, and "accidental" backscatter is a way to advertise their products. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

On Sun, 4 Dec 2005, Steven M. Bellovin wrote:

In message <B6621ED4D0AD394BBA73CA657DFD8976869630@MSPEXBE01.wamnet.inc>, "Chur ch, Chuck" writes:

...

What about all the viruses out there that don't forge addresses? Sending a warning message makes sense for these. Unless someone has

A-V companies are in the business of analyzing viruses. They should *know* how a particular virus behaves.

This has also been said before, but... they are also in the business of SELLING their product. It seems that the 'default' (note I don't either: use av, nor scan emails for virii so I'm not sure what defaults to what... just use something other than outlook and you can care less about it) is possibly there for advertising effect more than anything else :( Hey, bob's company stopped this virus with $PRODUCT_12, why aren't we using that product $VP_O_IT ??

On Mon, 05 Dec 2005 17:38:00 PST, Douglas Otis said:

pending the scan. Another solution would be not returning message content within a DSN. This would mitigate the distribution of viruses, as well as forged bounce-addresses sent to a backup MTAs as a method for bypassing black-hole lists. Would changing what is returned within a DSN in all cases be a solution?

No. You're still sending a DSN to a destination that you know beforehand is incorrect.

On Dec 6, 2005, at 8:19 AM, Todd Vierling wrote:

On Mon, 5 Dec 2005, Douglas Otis wrote:

...

A less than elegant solution as an alternative to deleting the message, is to hold the data phase pending the scan.

Contrary to your vision of this option, it is not only elegant; it happens to be the *correct* thing to do.

Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream. Waiting for the scan to complete adds stack overhead (assuming a good black-hole list is being used). Albeit small, there is never 0% false detections of malware. It would seem that when a DSN is required, as a general practice, the DSN should not include message content. This should at least thwart this vector being used to spread malware and spam. Preventing the spread of a virus seems key. There is always BATV to clean-up spoofed bounce-addresses in the meantime. -Doug

On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:

On Tue, 6 Dec 2005, Douglas Otis wrote:

...

Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream.

Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e- mail... thus UBE.

I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email.

Generated virus "warnings" must not go to a known forged sender, or to a sender for which the forgery status is unknown. If you cannot *guarantee* that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time, your only options are to quarantine, discard, or allow delivery. Do not send a DSN; do not pass Go; do not collect US$200.

Not all email is rejected within the SMTP session. You are changing requirements for recipients that scan incoming messages for malware. Fault them for returning content or not including a null bounce- address. No one can guarantee an email-address within the bounce- address is valid, furthermore a DSN could be desired even for cases where an authorization scheme fails. Why create corner cases?

...

There is always BATV to clean-up spoofed bounce-addresses in the meantime.

And other methods (DK, SPF, SID, choose your poison). However, if the server cannot verify that the MAIL FROM:<> is not forged with reasonable certainty, the server should not send a DSN, period. Otherwise, it's a direct contributor to the UBE problem.

DomainKeys and Sender-ID can not validate the bounce-address or the DSN. Even with an SPF failure, a DSN should still be sent, as SPF fails in several scenarios, and false positives are never 0%. BATV offers a unilateral option that can effectively discard spoofed bounce-addresses. When the AV software provides the DSN with a null bounce-address, BATV works as advertised. -Doug

----- Original Message ----- From: "Douglas Otis" <dotis@mail-abuse.org> To: "Todd Vierling" <tv@duh.org> Cc: "Steven M. Bellovin" <smb@cs.columbia.edu>; "Church, Chuck" <cchurch@netcogov.com>; <nanog@merit.edu> Sent: Tuesday, December 06, 2005 6:26 PM Subject: Re: Clueless anti-virus products/vendors (was Re: Sober)

On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:

...

On Tue, 6 Dec 2005, Douglas Otis wrote:

...

Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream.

Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e- mail... thus UBE.

I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email.

That's good Doug, and IMHO, your products should never generate them. However, I will disagree with you concerning the DSN being UBE. As a general rule, you are correct, DSN's != UBE. However, in the case of av systems (scanning engine and mta configurations) they can be. While I agree with you that the scanning engine(s) used by most of us, do not actually send reject notifications, the mechanisms that employ them, both commercial and open source, usually can, and do, unless configured not to. Some may see it as a violation of RFC to not return a DSN on failed delivery. Others, like myself see the need to not return a failure notice on virus / trojan infected email as it has become the norm that the sender information is forged. Especially those systems that contain the infected data along with the message. To many trojans / viri as of late, the DSN's that include the message (with infection) are being used as a repeater to further propogate the infection. Those that release these things are starting to depend on our mechanisms to help them spread. I, like others, prefer not to help them break the net from my little piece of it. -- Mike P.

On Dec 8, 2005, at 2:18 AM, Michael.Dillon@btradianz.com wrote:

It seems reasonable to design a mail system so that notifications are sent back to the originator of the message when there is a problem somewhere along the delivery chain.

Agreed. The alternative would be more like instant messaging.

It seems very UNreasonable to send notifications to random destinations that have nothing to do with originating the message in question.

It is also unreasonable to assume the return-path can always be associated with the sending MTA.

The crux of the matter is that if you don't KNOW the true source of the message, then you cannot return a DSN. You can go through the motions, but then you are originating SPAM (UBE), not returning DSNs.

When accepting messages from anonymous sources, seldom does one know the source.

Should you be accepting any mail at all from SMTP servers that you do not know and trust because of prior contact, i.e. negotiating an email peering agreement?

Making email a closed system would dramatically change who can send messages and how email would work. The safest place to decide whether a DSN is legitimate is by the MTA located by the return- path. Use of BATV allows the return-path MTA to immediately refuse DSNs determined to be illegitimate. Immediately, the back-scatter problem would be substantially resolved and no RFC need to be changed, and the integrity of email delivery would not suffer. This would also close the "back-door" used to evade black-hole lists. -Doug

On Fri, 2005-12-09 at 09:25 +0000, Simon Waters wrote:

But the point of this discussion is that SMTP will have to evolve to be a point to point system (or functional equivalent). The days of store and forward in intermediate MTAs should die as quickly as possible (which as our forwarding demonstrates may be quite slowly alas). The problem is that many of the antivirus gateways behave like new intermediate MTAs, especially when for many of the organisations involved it could easily be done during SMTP transactions.

While AV scanning may be done during the session, it would also require additional steps to also contain _all_ upstream activity within the same session as well, when attempting to achieve an apparent point-to-point operation. If SMTP were point-to-point, this would be evolving into the IM model where the message queue or storage would always be at the sender. Such mode of operation will increase the average transaction time needed for email. As SMTP may pass messages through multiple administratively separate MTAs where acceptance criteria may differ, unless all connections needed to complete the transaction are active simultaneously, refusal at any point will require use of a DSN or delivery integrity is lost. A common exploit used by abusers is to find where acceptance criteria differs between MTAs. Abusers depend upon this to generate DSNs that act as a delivery vehicle of abusive messages masquerading as DSNs with spoofed return-paths. While simulating point-to-point operation would be one (expensive) approach at solving this problem, some have suggested the use of SPF records to qualify the return-path before accepting the message. The qualified return-path approach has several problems. It may require more than 100 sequential lookups to fully resolve a complete address list, which is often open-ended. These address lists remain open-ended, as there are many legitimate cases where this qualification still fails. As of yesterday, there is no record in use with a scope specifically defined to qualify the return-path. BATV on the other hand solves the DSN exploit without waiting for anyone else to adopt some practice. Although there is a small window where the BATV return-path could be replayed, such illegal activity can be traced. Neither Sender-ID nor DKIM will solve this serious exploit either. While many AV products are a nuisance as they enable this DSN exploit which actually spreads viruses (#$%&*), solving this problem does not require changing the nature of SMTP and dramatically affecting every email system, or even hoping everyone qualifies the return-path prior to acceptance. BATV is really a simple and effective solution that should be put in place now. -Doug

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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

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: sjsobol@JustThe.net Snail: 22674 Motnocab Road, Apple Valley, CA 92307

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

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 --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke

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

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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

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

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

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? Naaaah:

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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

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

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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

Date: Fri, 9 Dec 2005 15:08:49 -0800 From: Douglas Otis <dotis@mail-abuse.org> 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

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_________

On Sat, 2005-12-10 at 17:37 +0000, 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: <fred@example.com> Is transformed by BATV with a private tag into: prvs=fred/<KDDDSSSSSS>@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 20000000 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: <fred@example.com> S: 550 5.1.1 <fred.example.com>... User unknown C: QUIT When the MAIL FROM is <>, the only valid RCPT TO would be a BATV address such as: ... C: RCPT TO: <prvs=fred/A237EDBA07@example.com> S: 250 2.1.5 <prvs=fred/A237EDBA07@example.com>... 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 <joe.tld> 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

...

...

...

...

"Douglas" == Douglas Otis <dotis@mail-abuse.org> 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

On 12/11/05, Micheal Patterson <micheal@tsgincorporated.com> 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 (ops.lists@gmail.com)

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 ______________________________________________________________________

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: sjsobol@JustThe.net Snail: 22674 Motnocab Road, Apple Valley, CA 92307

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: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

----- Original Message ----- From: "Douglas Otis" <dotis@mail-abuse.org> To: "Todd Vierling" <tv@duh.org> Cc: "Steven J. Sobol" <sjsobol@JustThe.net>; "Geo." <geoincidents@nls.net>; <nanog@merit.edu> Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote:

...

1. Virus "warnings" to forged addresses are UBE, by definition.

This definition would be making at least two of the following assumptions:

1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem.

While there could be best practices created for AV filtering, it seems unlikely to be effective. Simplistic filters for DSNs also seem counter to ensuring the integrity of email delivery. Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Why expect others to fix this problem, when there is a solution that one could make the investment in to deploy. This will reduce this problem over the long term. The BATV alternative would not cause otherwise valuable DSNs to be lost, nor make assumptions about the quality of malware detection.

If you can't trust AV handling of DSNs, why trust their detections?

Would you rather see emails simply disappear?

I would rather see the problem stop at the source instead of the current issue being used as a crutch to attempt to get people to go to BATV or Mass-Rep (as described in your draft). There's an old military comm saying that fits perfectly here. "Clean House". For those of you ex comm folks, you'll probably recognize it. For those of you who don't, it simply means, fix your stuff before you point blame at the distant end for the problem.

...

2. It is the responsibility of the *SENDER* not to send UBE.

When the recipient is a legitimate email provider, it could seriously lower the integrity of email delivery for these providers to toss DSNs because many fall into a category you want to define as UBE. While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution.

-Doug

Do you not comprehend what's really being said here Doug? Yes, blocking / rejecting of a DSN is a BAD thing and should never be done. Rejecting of a notification of malware != the same thing. If the reciever of "your" DSN didn't sent the message, then it's no longer a DSN.. It's now officially, by definition, UBE from YOU to the incorrect originator now isn't it. This is the case in the majority of malware notifications by anyone / anything that generates them. More than likely, the viri / trojan writer is "depending" on them to help propogate their ilk because they too can be network admins and are aware that DSN's don't get tossed. What better method to get them out to the masses but to have our main feeds, and huge pipes help them along? I mean, really, who's better to help them? Mom and dat with the 56k dialup or us with the DS3's - OC12's to help them along? Look at the big picture Doug instead of 45 degrees to the left and right. You hate spam, I hate spam, I don't send DSN's to senders because I know that roughly 90% of them are bogus. You feel that's bad. You have the right to disagree. I have the right to deny traffic that is in response to traffic that didn't originate from my network(s) regardless of your belief. Mike P.

----- Original Message ----- From: "Micheal Patterson" <micheal@tsgincorporated.com> To: "Douglas Otis" <dotis@mail-abuse.org>; "Todd Vierling" <tv@duh.org> Cc: "Steven J. Sobol" <sjsobol@JustThe.net>; "Geo." <geoincidents@nls.net>; <nanog@merit.edu> Sent: Friday, December 09, 2005 4:01 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

----- Original Message ----- From: "Douglas Otis" <dotis@mail-abuse.org> To: "Todd Vierling" <tv@duh.org> Cc: "Steven J. Sobol" <sjsobol@JustThe.net>; "Geo." <geoincidents@nls.net>; <nanog@merit.edu> Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

...

On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote:

...

1. Virus "warnings" to forged addresses are UBE, by definition.

This definition would be making at least two of the following assumptions:

1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem.

Case in point Doug.. Current versions of Sober.U are sending mail from: ?@c-24-19-xx-xx.hsd1.wa.comcast.net (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 hostmaster?@comcast.net or ?@comcast.net. The originator is forged and the DSN is unable to get to the originating sender. Mike P.

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

On Tue, 6 Dec 2005, Douglas Otis wrote:

...

Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e-mail... thus UBE.

I know of no cases where a malware related DSN would be generated by our products,

That's good. Unfortunately it is not the case for most commercial anti-malware products.

nevertheless, DSNs are not Unsolicited Bulk Email.

I don't see how this is relevant to my paragraph above. I was not equating DSNs to UBE -- I specifically mentioned virus "warnings". Whether those warnings are look like DSNs, smell like DSNs, or taste like DSNs is wholly irrelevant; they are still UBE if sent to forged virus sender addresses. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

On Dec 7, 2005, at 1:35 PM, Edward B. Dreger wrote:

DO> Not all email is rejected within the SMTP session. You are changing DO> requirements for recipients that scan incoming messages for malware. Fault DO> them for returning content or not including a null bounce- address. No one DO> can guarantee an email-address within the bounce-address is valid,

Perhaps DSNs should be sent to the original recipient, not the purported sender. RFC-compliant? No. Ridiculous? Less so than pestering a random third party. Let the intended recipient communicate OOB or manually if needed.

Being refused by the intended recipient would be the cause for the DSN.

DO> furthermore a DSN could be desired even for cases where an authorization

When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary.

This assumes all messages are rejected within the SMTP session.

DO> scheme fails. Why create corner cases?

The corner case is that a virus _might_ actually have a realistic "From" address. :-)

You mean bounce-address? A From address often has nothing to do with where a message originated.

DO> DomainKeys and Sender-ID can not validate the bounce-address or the DSN. DO> Even with an SPF failure, a DSN should still be sent, as SPF fails in

If you receive mail with

From: <eddy@everquick.net>

coming from 10.10.10.10, and everquick.net SPF records indicate that IP address is bogus, how can you possibly justify "that mail may indeed have come from how it's apparently addressed"? Doubly so when a virus is known to spoof "from" addresses!

SPF has _nothing_ to do with the From address. Once again, not _all_ messages are rejected within the SMTP session. False positives are not 0%. To ensure the integrity of email delivery, not including message content and using a null bounce- address should be the recommended practice at the initial recipient. If you do not want to see DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the recommended practice. You would not need to insist that anything special be done at millions of other locations. -Doug

On Dec 7, 2005, at 4:06 PM, Edward B. Dreger wrote:

Hmmmm. BATV-triggered bounces. Virus triggers forged bounce which in turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth growth of the '90s will continue. ;-)

BATV should not trigger any bounce as this only changes the local- part of the bounce-address (a.k.a return-path). BATV allows quick rejection of the session when a spoof is detected before any message is exchanged. This should alleviate your concerns about bandwidth. It would also depreciate this tactic and further reduce related traffic. Being sensitive about spoofed DSNs, one would expect to hear accolades for BATV rather than berating. -Doug

On Wed, Dec 07, 2005 at 02:15:00PM -0800, Douglas Otis wrote:

...

When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary.

This assumes all messages are rejected within the SMTP session.

Yes, exactly and the point several of us have been making is that this is (a) easy (well, provided you're using a quality MTA; if not, then switch to one) (b) running a sane mail system (c) fast (d) resource-friendly and (e) most important of all, the _only_ way to avoid sending UBE in response to forgeries (which are not going away any time soon or quite possibly ever). (Please note: there are no exceptions to the UBE specification for DSNs. If DSNs are: - sent to forged senders (thus unsolicited) - in bulk (thus bulk) - via email (thus email) then they are UBE, which is THE definition of spam -- and which deliberately omits any mention of content, purpose or other things that are irrelevant to the spam/not-spam question.) ---Rsk

On Mon, 12 Dec 2005 11:08:14 +0000, Michael.Dillon@btradianz.com said: [snip]

Not quite the only way. If a postprocessing step is needed, it is trivial for the SMTP server to record any return path info that it knows in order for the post-processor to be able to send DSN's as accurately as the SMTP server itself.

What we have here is yet another failure of imagination.

Has anybody claimed that post-processing within the SMTP-server is better than postprocessing done elsewhere? The issue was in-line-processing vs post-processing. No information you can collect from the SMTP-session or elsewhere can ever compete with the accuracy in notification gained if you reject the message in-line and leave the responsibility for sender-notification with the sending MTA. //per -- Per Heldal heldal@eml.cc

On Mon, 12 Dec 2005, Michael.Dillon@btradianz.com wrote:

...

No information you can collect from the SMTP-session or elsewhere can ever compete with the accuracy in notification gained if you reject the message in-line and leave the responsibility for sender-notification with the sending MTA.

On the other hand, sending the DSNs back to the sending MTA

That is contradictory. The sending MTA is known to be presenting a forged return path, but a DSN is defined as being sent to the presented sender address at the original MTA location. Thus any such notifications are not DSNs by definition. (Read RFC1894 for context, and note that virus-worms do not implement RFC1891 ORCPT -- nor should you ever expect them to do so.) In the case of virus-worm spew, there is better than 99% chance that there is no inbound MTA on port 25 of the connecting host. What's the point of generating an illegitimate DSN if no one will see it anyway? Again, we circle back around to 5xx in-band errors as the only way, that is usable in non-theoretical environments today, to provide virus rejection notifications. In lieu of rejecting in-band, an admin of such a broken product should follow a two-step process: 1. Drop viruses into the bit bucket without notification; and 2. Look for a product that can reject in-band, and switch to it. The days of multihop MTAs are coming to a close. In-band error signaling is used by nearly every other protocol commonly used on the Internet today; SMTP shouldn't be considered all that different anymore. The MUA and MDA leaf roles have clearly defined separation from the MTA infrastructure, and MTA-to-MTA communication should be perfectly capable of in-band error signaling in the modern Internet. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

Thus spake "Per Heldal" <heldal@eml.cc>

On Mon, 12 Dec 2005 14:18:07 +0000, Michael.Dillon@btradianz.com said: [snip]

...

This whole discussion centered around the fact that innocent 3rd parties with no ability to act, were being sent large volumes of notifications. Once you remove the innocent 3rd party from the equation, the shape of the problem is quite different.

I agree that notices should not be sent to addresses that are likely to be forged because then innocent 3rd parties are being spammed. However that does not mean that all notifications are bad.

It still doesn't make sense to send notification in any form other than a "5xx stuff your malware..." response. Any MTA-admin with half a clue seeing lots of such in the logs for outbound messages should know what to do.

You think they'll notice, much less act on those logs? The sending MTA, provided it's not the malware or spam software itself, will simply read the in-band 5xx and send a DSN to the forged originator. This moves the error closer to the source, but the result is still that the innocent third party still gets a DSN for mail they didn't send. I fail to see how this is a meaningful improvement. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

On Mon, 12 Dec 2005, Michael.Dillon@btradianz.com wrote:

...

...

This assumes all messages are rejected within the SMTP session.

Yes, exactly and the point several of us have been making is that this is (a) easy (well, provided you're using a quality MTA; if not, then switch to one) (b) running a sane mail system (c) fast (d) resource-friendly and

...

(e) most important of all, the _only_ way to avoid sending UBE in response to forgeries (which are not going away any time soon or quite possibly ever).

Not quite the only way. If a postprocessing step is needed, it is trivial for the SMTP server to record any return path info that it knows in order for the post-processor to be able to send DSN's as accurately as the SMTP server itself.

The point is not to send a DSN *at all* for virus-based rejections, because doing so even at the SMTP server level will still result in UBE to a forged original sender address. The return path is *known* to be invalid, so it doesn't matter where you put the DSN generator; it will still send spew to an uninvolved third party. Rejecting with 5xx during the SMTP transaction does not have this undesired behavior. In that case, the connecting MTA, which should have a much better idea of who sent the virus-worm instance, receives the rejection in-band. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>

* Michael.Dillon@btradianz.com (Michael.Dillon@btradianz.com) [Thu 08 Dec 2005, 12:11 CET]:

The RFC process itself is broken when clueless vendors treat RFCs as inviolable specs and implement according to the RFC even when they find flaws in it. If they want to remain true to the RFC process, they should not implement dumb things found in an RFC, instead they should write and submit a new RFC correcting the error and explaining the right way to do things.

Exactly. The nice thing about standards is that there are so many to choose from! Why not add a few more? -- Niels. -- "Calling religion a drug is an insult to drugs everywhere. Religion is more like the placebo of the masses." -- MeFi user boaz