From owner-nanog@merit.edu Fri Dec 9 13:59:30 2005 nanog@merit.edu From: Douglas Otis <dotis@mail-abuse.org> 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 <tv@duh.org>

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

...

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

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

FALSE TO FACT. Notice the qualifier "forged", regarding the address to which the notification is being sent.

1) Malware detection has a 0% false positive.

If there is a 'false positive' decting malware, it is a near certainty that the "legitimage" message so classified does *NOT* have a FORGED ADDRESS. In addition, _IF_ a false positive occurs, the *sender* can do nothing about the situation -- resending the message, for example, will *NOT* have any better chance of getting through. The _right_ person to notify in such a situation is the RECIPIENT. They have a chance of 'influencing' the people who set the policies (that resulted in that false postive) in regard to getting the policy _changed_. Thus, this is an invalid straw-man argument. One down.

2) Lack of DSN for email falsely detected containing malware is okay.

*IF* the sender address _is_ forged (a _necessary_ pre-condition for Todd's statement to be applicable, then the fact remains that that 'false positive' indication is going to someone who DID NOT REQUEST such notification, either explicitly (by signing up for it), nor implicitly (by actually _sending_ the message in question). Thus, this is an invalid straw-man argument. Two down.

3) Purported malware should be assumed to use a forged return-path.

I can't imagine why anyone could *possibly* think that that might be the case! </sarcasm> Note: It does happen to be an assumption that does turn out to "coincide with the actual facts of the situation" in a _very_large_ share of the cases. In the last three years of rejecting (SMTP transaction-time) _anything_ that contained anything that 'looked like' either an MS-executable format attachment, or a ZIP file, I have not seen a *SINGLE* such message that did have an accurate return path. Available statistical data from other sources shows a "not quite that extreme" proportion. The _lowest_ numbers I've seen put the proportion at well over 90% -- basis the numbers of messages encountered. A trivial, surface-level, analysis of the goals of virus-writers shows that virus writers, in general, have *every* reason to obsure the "source" of the message, and _no_ reason for the message to "clearly identify" the actual message source. That once the virus-writer "community" figured out how to send messages with spoofed origin information, the _virtually_every_ virus released after that point *does* use such spoofing -- for the express purpose of making it 'as difficult as possible' to identify the true source of the infection-carrying message. It is also an "obvious fact" that people who are in the *business* of selling malware detection systems, have a business interest in "identifying" and "classifying" malware. "What it does", and "how it works" ARE (or should be) reasonable and expected parts of their identificaton/analysis/classificaiton process. Thus, 'malware detection system' vendors -- of all people -- should be expected to know _more_ about whether or not a particular 'detected' malware (regardless of whether or not it was a 'false positive' detection) is one that forges the 'pooint of origin' information that would be used to route a DSN. Thre is no need for the authors/sellers of 'malware detection systems' to "assume" any specific behavior as a 'default' assumption. They *SHOULD* *KNOW* the actual of every virus that they have an 'identification signature' for. thus there is no need to assume anything, they can act case-by-case on "actual", factual data. Thus, this is an invalid straw-man argument. Three down.

4) The return-path can be validated prior to accepting a message.

"wHO CARES" ABOUT the return-path? if you make the malware determination *at*the*exterior*gateway** to your network, *during* the SMTP transaction, you have a 'reliable' path back to the system that tried to deliver it _to_ you. If *they* don't know (reliably) who the actual sender of that message is, that is _their_ problem. If you _cannot_ make a real-time "malware" determination during the _gateway_ SMTP transaction, and the gateway has "accepted for delivery" the questionable message, then when the 'malware' determination is made, the message should be simply _delivered_, according to site policy -- directly to the bit-bucket. As this _does_ meet the 'delivery' requirements of the relevant RFCs, thre is no need to send a failure notification 'backwareds' to anywhere. Thus, this is an invalid straw-man argument. four down.

5) SMTP should appear to be point-to-point.

An overly-broad statement, without any real meaning. SMTP already _is_ point-to-point, relative to "point-to-multipoint" (broad- casting), and/or 'multipoint-to-point" (semders to the same destination over- writing each other). A message just goes through a series of point-to-point links en route to the destination. I suspect you meant "point-to-point" as a reference to a system where the actual sender makes a direct connection to the reveiver's mailbox. This is really described as a end-to-end snychronous connection. No 'store and forward' capability, no 'asynchronous' transfers. IF that is what you mean, it is a 'conclusion' not supported by the facts so far in evidence. With "minor" changes to the current SMTP protocol, and the various implementations, the issue of delivery failure notices to a forged address can route the message back to the *actual* sender, and _reliably_ so. First, an MSA (to use the 'sendmail' terminology) must know how to 'reliably' send a message back to the _user_ who submitted the message, *before* it accepts that 'submitted' message. Second there is a need to _retain_ that information on a _per_message_ basis, until the allowed 'message delivery failure" interval has elapsed. Third, when a message is passed on to another MTA, the remaining time until the _original_ message delivry failure time-limit is reached. this will be the 'original' time remaining less any time that it has spent sitting _IN_ the queue on the server. any server can have a 'maximum" time-limit, and if the time-limit on an incoming message is _greater_ than that maximum, it 'automatically gets reduced to the 'site maximum". Now, if a message is still "undelivered" when the delivery failure time- limit is reached, the message is removed from the local outgoing queue, And a status notification is sent *to*the*server* that delivered the message to the system where it timed-out. Each system going back 'up' the delivery path will then "pass up the line" TO THE SERVER that sent to that systrem, of the delivery failure. eventually, the 'failure' message gets back to the MSA that accepted the message, and "knows" _reliably_ how to contact the actual sender. and *that* machine mails the actual failure notice to the actual sender. You've got asyncrhonous, store-and-forward, message passing in *both* directions. It's _not_ "point-to-point'. It takes some protocol extensions, and supporting implementations, to make everything work. OK, that was a lengthy debunking, but it is debunked. five down.

6) MTAs with AV filters are the only problem.

And _what_, pray tell, *OTHER* than an "MTA with AV filters" is going to automatically generate a 'virus warning' to an address that was forged as the sender of a virus-infected email? Yes, there are other sources of UBE. That is utterly irrelevant to whether or not "systems that send *unsolicited* messages to persons who have had _zero_ contact with that system" are sending UBE. A claim that "X (a malware detecting system) is a member of set "Y" (UBE emitters) *DOES*NOT*IMPLY* that "X" is the _only_ member of that set. That the set has other members does _not_ invalidate X's membership membership in set "Y", Thus, this is _also_ a false claim. wups. that's 6 out ot 6. nothing left.

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.

Why should _everyone_ have to "make the investment", when a much smaller investment by a *much*smaller* population (the 'malware detection system _vendors_) would utterly *eliminate* the _problem_as_stated_ -- to wit: Virus "warnings" to forged addresses.

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?

Quote: "E-mail is *NOT* a _reliable_ communicaitons mechanism."

...

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.

_I_ am *NOT* the sender of the message. I DID NOT SOLICIT any notifications about messages sent by *OTHER*PEOPLE*. Sending _me_ those messages does more to 'lower the integrity of email delivery' than not sending them to me. What it does is teach me to *ignore* non-delivery messages -- because they are KNOWN TO BE WRONG for virtually every non-delivery notice I receive. (bogus -- for messages I did _not_ send -- notifications, _for _me_, outnumber 'legitimate' ones -- for messages I *DID* send -- by more than 500:1.

While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution.

Yup. After the third bogus notification within 12 months, I configure my mail-server to not accept *any* traffic from the offending "sending" server. The SMTP transaction rejection message says _exactly_ (and in rather pointed language) why no mail from that system is accepted, and suggests that the sender try sending _from_a_different_network_ if they really want to contact the addressee. Orders of magnitude less CPU cycles than BATV. Far friendlier on _my_ network bandwidth. It may not be 'friendly', and it may not be appropriate for larger sites