SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

Fri Dec 9 21:12:52 UTC 2005

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