RE: Clueless anti-virus products/vendors (was Re: Sober)

Mailman List Mirror (Read Only)
21

> 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.

22

Date: Tue, 6 Dec 2005 16:26:16 -0800
From: Douglas Otis

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

Good.

products, nevertheless, DSNs are not Unsolicited Bulk Email.

Huh? I get NDRs for mail that "I" sent. I do not want those NDRs. I
did not request those NDRs. Those NDRs are not in response to a message
I sent.

I do not want backscatter NDR notices. I frankly don't care that
WhizBangAV caught WormOfTheWeek on Susie Smith's corporate mail in
Argentina from Billy Boo's PC in China... just because my address
happened to be the subject of a joe jobbing worm.

Really. Even reading and posting to NANOG is more important. :wink:

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,

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.

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.

scheme fails. Why create corner cases?

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

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

If you receive mail with

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!

Saying a DSN should be sent is just untenable.

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.

Eddy

23

> 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,

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.

> 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.

> scheme fails. Why create corner cases?

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

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

> 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

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

24

Date: Wed, 7 Dec 2005 14:15:00 -0800
From: Douglas Otis

> 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.

Fine. But where to send it? Certainly not to a random address.

> > 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.

Perhaps we're examining different "authorization" cases. Maybe my
mindset of "SMTP auth" is too narrow for your intended scope.

> > scheme fails. Why create corner cases?
>
> The corner case is that a virus _might_ actually have a realistic "From"
> address. :slight_smile:

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

SPF has _nothing_ to do with the From address.

Errrr, "return-path". Freudian slip dealing with some site local
experiments... "from" is not as accurate as "return-path", but it's far
from (no pun intended) useless.

Once again, not _all_ messages are rejected within the SMTP session. False

Of course not.

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.

Oh well. I guess I've pretty much given up on pre-body filtering... so
I suppose it would be too idyllic to expect anything different with
DSNs.

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. :wink:

Eddy

25

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

26

Date: Wed, 7 Dec 2005 17:02:51 -0800
From: Douglas Otis

> 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. :wink:

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

I've read the spec.

should alleviate your concerns about bandwidth. It would also depreciate

I usually don't use humor-related smileys when I'm worried.

this tactic and further reduce related traffic. Being sensitive about
spoofed DSNs, one would expect to hear accolades for BATV rather than
berating.

Wouldn't it be nice to let people know their DSNs are misplaced? Or
does that only apply to viruses and worms? :wink:

So much for "be conservative in what you send and liberal in what you
accept". Yes, BATV helps block the errant DSNs. It's just a shame that
we seem to be shifting responsibility to the recipient, treating the
symptom instead of the disease.

Eddy

27

Some may see it as a
violation of RFC to not return a DSN on failed delivery.

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.

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.

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

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.

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?

--Michael Dillon

28

Perhaps DSNs should be sent to the original recipient, not the purported

sender. RFC-compliant? No.

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.

--Michael Dillon

29

* 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.

30

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

31

On the contrary, short of the tricks played on AOL to defeat their original
antispam system, TCP means you always know the source.

We manage to filter out ~98% of the unwanted email here with very nearly 100%
accuracy at the SMTP transaction stage with low processor overhead on our new
email servers. At which point any backscatter from what gets through is
trivial, although alas there still is a little due to evil practices of the
past in then forwarding email elsewhere.

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.

The remaining issue is how much resource it costs to do your spam/malware
detection, but I believe trying to do anything beyond policy enforcement ("no
EXE/PIF/SCR here please") in terms of malware detection in the MTA is a
mistake, especially when you only really need to protect the thick(!)
clients, and they still need to be protected when the content is
zipped/encrypted/novel/zipped+encrypted+novel etc.

This thread on the other hand should move to Spam-L.

32

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

33

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

34

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.

35

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

36

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

37

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?

38

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!

39

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.

40

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.