Subject: Eliminating Virus Spam

From: John Border <[email-masked]>
Date: Wed, 03 Jan 2001 12:41:05 -0500

I am not that familiar with the details of how mailing list servers work. 
Is it possible to configure a mailing list server (e.g. [email-masked]?)
to do a virus scan on an incoming mail message before forwarding it to the
mailing list, bouncing the mail message back to the sender if a virus is
detected?  (Or, since From addresses might be faked, maybe just tossing it is
the right answer.)  If such a capability doesn't exist, maybe it should...

John

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 03 Jan 2001 15:51:04 -0500

I think it would be a mistake for the IETF to try to get into the
business of protecting mailing list subscribers from virses.  But the
list membership should be protected from anti-virus software spamming
by some combination of filters and unsubscribing those whose sites run
such unscalable software.

Donald

From:  John Border <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Wed, 03 Jan 2001 12:41:05 -0500
To:  [email-masked]

---

From: Russ Allbery <[email-masked]>
Date: 03 Jan 2001 13:20:13 -0800

John Border <[email-masked]> writes:

> I am not that familiar with the details of how mailing list servers
> work. Is it possible to configure a mailing list server
> (e.g. [email-masked]?)  to do a virus scan on an incoming mail
> message before forwarding it to the mailing list, bouncing the mail
> message back to the sender if a virus is detected?  (Or, since From
> addresses might be faked, maybe just tossing it is the right answer.)
> If such a capability doesn't exist, maybe it should...

Can we please just unsubscribe all list subscribers who are sending these
warnings to the list and ban their domains?  This is getting ridiculous.
An IETF mailing list should not have to do virus scans specific to one
particular platform, scans that are quite possible to do at sites that
care, just to protect the mailing list against *completely broken*
notifications that should never under any circumstances have been
automatically sent to the mailing list in the first place.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: James M Galvin <[email-masked]>
Date: Wed, 03 Jan 2001 17:50:03 -0500 (EST)

I think it would be a mistake for the IETF to try to get into the
    business of protecting mailing list subscribers from virses.

I'd sure like to understand your motivation for this point of view.
Since it is, in fact, relatively straightforward to put virus scanning
in front of message distribution I would think this is exactly what we
want the IETF to do, or more precisely the IETF Secretariat to do for
those elists they manage.  The only real work in such an activity is
keeping up with the "virus updates".

Jim

On Wed, 3 Jan 2001, Donald E. Eastlake 3rd wrote:

    Date: Wed, 03 Jan 2001 15:51:04 -0500
    From: Donald E. Eastlake 3rd <[email-masked]>
    To: [email-masked]
    Subject: Re: Eliminating Virus Spam

    Donald

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 3 Jan 2001 18:46:36 -0500

Date: Wed, 03 Jan 2001 17:50:03 -0500 (EST)
   From: James M Galvin <[email-masked]>

Well, such "virus protection" is utterly irrelevant to me; I use a Unix
and Linux machines to read my e-mail, and so I don't have stupidly
designed mail user agents.

I agree that filtering multipart messages goes too far; they can be
useful.  However, I do believe it would be fair game --- especially for
the IETF mailing list, to filter multipart messages containing Microsoft
documents and executables.  There really is no excuse for sending any of
that nonsense onto the IETF mailing list, and that would nicely avoid
sending any viruses onto the IETF list without needing to run
platform-specific virus detection software, and requiring the
secretariat to keep such software up-to-date.  (For bonus points, it
would be nice to have filtering software to deal OutLook's annoying
habit of sending both HTML and ASCII TEXT messages for messages there
was absolutely no need to send to the HTML...)

I do have to admit, the more I get spammed with this Microsoft-specific
mail-garbage, the more sympathy I have towards those who've argued for
simply filtering all messages that orignated from Microsoft MUA's (which
would also solve the problem), although arguably that penalizes the
wrong set of people --- the users, instead of the idiots who wrote the
MS-MUA's in the first place.

							- Ted

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Jan 2001 00:07:38 +0000 (GMT)

On Wed, 3 Jan 2001, James M Galvin <[email-masked]> wrote:

> those elists they manage.

And these virus scanners are available and marketed for which
platforms, exactly? (Hint: demand creates supply.)

And which platforms are the least reliable at mail delivery, and are
less favoured by managers of large 'elists'?

By 'we', you mean 'I, and I alone'.

I'd just bounce all emails with non-text attachments with a message
requesting that attachments not be sent to the list, and that the
message be resent as text. Simple. sufficient.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 03 Jan 2001 19:55:03 -0500

>message be resent as text. Simple. sufficient.

        Fully agree.  There is no need to use any thing that
isn't text/plain to the main IETF list. 

Ran
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jan 2001 18:04:51 -0800

> isn't text/plain to the main IETF list.

How about adding some filters to the mailer?
I've implemented this on other lists, to
majordomo's 'taboo headers' pattern list:

        /^Subject: Antigen found/
        /^Subject: Virus Notification/
        /^Subject: Virus Alert/

The list maintainer gets the error message
(taboo header found), and can notify the list
_gracefully_.

Joe

---

From: James M Galvin <[email-masked]>
Date: Wed, 03 Jan 2001 23:57:53 -0500 (EST)

I think this discussion needs to separate at least two distinct issues.

1. Should the IETF elist messages be scanned for viruses?

2. Should the IETF elist restrict the type of content that can be
   submitted?

Personally I think it would be a great service to the community to scan
messages for viruses, especially if we are going to continue to allow
content other than text.  This is strictly a practical opinion on my
part.  It's not hard to do and it would eliminate a lot of wasted
resources.  (How much is your time worth?)  In fact, I do it for
precisely this reason.  I run an elist management service
(www.elistx.com) and I include it as part of my core service.  I do it
on x86 machines running Solaris with Sophos (www.sophos.com - excellent
UNIX support in my opinion, they support all the popular varieties).  No
big deal, although frequently there are daily updates to the virus
descriptions.  Your mileage may vary as far as cost is concerned.

In addition to better managing resources on the server side I consider
it a service to the subscribers.  Some people are bound to whatever
their employers do and how they do it.  You can bash Microsoft and
Antigen all you want but it won't change the fact that some people just
can not control everything about their environment and if we can do a
little something to help them get more out of their IETF experience how
can that be bad?  Especially on this general elist!

As far as restricting the content of messages on the IETF elist to text,
I'm not opposed to it although I won't support it either.  The IETF has
always prided itself on being a text-based operation so I can accept the
position as rational.  The big win of course is if you do this you don't
need to do virus scanning of the messages.

On the other hand, I think it's a feature to be able to send documents
(even text-based documents) as attachments as opposed to inline and I
further consider it a feature that Internet Draft announcements and RFC
announcements are multipart with functional pointers to the documents.
I realize these latter points are probably more applicable to WG elists
than this general IETF elist, but nonetheless I would consider it
short-sighted of us to explicitly hold back the advancement and
improvement of email (and MIME would be an improvement if more software
did it right), especially when it is our own standard.

I would, however, support the moderation of any message containing
something other than text, especially on this general IETF elist.  Of
course that presumes someone is available to be the moderator.  Another
policy worth considering that has also been mentioned is trimming those
annoying multipart/alternative with both HTML and text to just text.
Now those are a waste of resources if ever there was one.

Jim

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 04 Jan 2001 00:27:00 -0500

>   keeping up with the "virus updates".

Here are a few reasons that occur to me immediately: If the IETF
filters messages for their safety, the IETF becomes responsible for
damages caused by any messages that get through.  The IETF
Secretariate is a limited resource and it is better expended
supporting those with the knowledge and competence to contriubte to
the IETF mission of quality protocol specifications who can immunize
themselves from viruses in an Internet friendly way for the account(s)
they use for IETF mailing lists.  (And, given how many mailbox
services are available, I don't consider "But my organization uses X
broken mail software" to be a plausible excuse.)  Virus filtering is
almost entirely platform dependent, so such things shouldn't be on the
IETF discuss mailing list at all, and would require selection,
possible periodic replacement, and constant maintenance of proprietary
commercial software.  Etc.

However, stripping out or blocking mail by MIME type would probably be
a reasonable technique that would be about as effective and is
certainly platform independent...

From:  "Theodore Y. Ts'o" <[email-masked]>
Date:  Wed, 3 Jan 2001 18:46:36 -0500
Message-Id:  <[email-masked]>
In-reply-to:  James M Galvin's message of Wed, 03 Jan 2001 17:50:03 -0500
	     	(EST), <[email-masked]>

>...

I think MULTIPART should definitely be allowed.  MULTIPART/SIGNED
certainly shouldn't be discouraged.  I frequently want, for someone
active in the IETF, the type of information in vCard attachments,
though it often seems that those for whom I want such info don't use
such attachments.

But it seems to me relatively easy to come up with a set of allowed
MIME types, basicly those defined in IETF standards which are useful
in platform independent IETF discussion list messages, and only allow
mail that either isn't MIME or has only the allowed types.  In
particular, about the only APPLICATION subtypes that seem reasonable
are those related to signatures and keys/certificates and proprietary
subtypes under other top level MIME types should be blocked.

>...

Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 155 Beaver Streeet                         [email-masked]
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Jan 2001 13:58:14 +0700

Date:        Wed, 03 Jan 2001 23:57:53 -0500 (EST)
    From:        James M Galvin <[email-masked]>
    Message-ID:  <[email-masked]>

Aside from what Donald said...

  | In addition to better managing resources on the server side I consider
  | it a service to the subscribers.

I don't.   This is like the kind of service you do for a battered
wife when you offer to drive her home from the hospital...   Much
better to do the harder work and convince the subscribers to get
rid of the cause of the problem, rather than offering band aids.

If that means excluding people till they learn how to participate
gracefully, then that might be what it takes to get the message
through.

  | As far as restricting the content of messages on the IETF elist to text,
  | I'm not opposed to it although I won't support it either.

On [email-masked] (as is already done on several other lists) this
seems like an entirely reasonable idea to me.  On ietf-announce on
the other hand, no, no need to restrict types (but there the list
cannot be generally accessed).

I can't think of a particularly good reason to send signed messages
to the ietf list, and I can't even imagine what use those vcard
things that keep appearing are (I have never found one... but I'd have
thought that if you want one from someone, you should send them
private mail and ask for it).

I can't think of any other reason that the ietf list would need
any kind of attachments in mail.

  | On the other hand, I think it's a feature to be able to send documents
  | (even text-based documents) as attachments as opposed to inline and I
  | further consider it a feature that Internet Draft announcements and RFC
  | announcements are multipart with functional pointers to the documents.

Yes, but none of that on the [email-masked] list.

  | but nonetheless I would consider it
  | short-sighted of us to explicitly hold back the advancement and
  | improvement of email (and MIME would be an improvement if more software
  | did it right), especially when it is our own standard.

There's a difference between holding it back, and directing it towards
proper, or considered, rather than simply universal, use.

  | I would, however, support the moderation of any message containing
  | something other than text,

That's probably more work than it is worth for the IETF list, as 99%
of the time, (probably more) "bounce it" is going to be the appropriate
response.

kre

---

From: Denis Mcmahon <[email-masked]>
Date: Thu, 04 Jan 2001 12:02:15 +0100

>1. Should the IETF elist messages be scanned for viruses?

This would require that appropriate virus detection software exist in
the environment that the mail list is operated.

Are you aware of eg an Acorn Archimedes virus scanner that runs in a
vax/vms environment?

>2. Should the IETF elist restrict the type of content that can be

I see no reason that the IETF list(s) should not be restrictd to
plaintext[1], with either a remove-the-attachment or even
drop-the-message approach (possibly with an automated unsubscribe) to
non text attachments / content.

Anyone who wants to distribute non plaintext can post it on a website
or ftp directory somewhere for collection by those who actually want
it.

Rgds
Denis

[1] Text based markup eg html is *NOT* plaintext in this context.
-- 
Denis McMahon              Usenet: Trim quotes
Mobile: +44 7802 468949            Reply at the end
Email: [email-masked]   Don't use html
I trim ng when posting! Email domain blocking in use

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jan 2001 08:01:29 -0500

>>>>> "James" == James M Galvin <[email-masked]> writes:
    James> On the other hand, I think it's a feature to be able to send documents
    James> (even text-based documents) as attachments as opposed to inline and I
    James> further consider it a feature that Internet Draft announcements and RFC
    James> announcements are multipart with functional pointers to the
  
  Emphasis on *pointers*
  
  Sending of IDs to the WG lists is a terrible practice.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Jan 2001 14:05:21 +0000 (GMT)

>   Sending of IDs to the WG lists is a terrible practice.

WG lists are archived. For historical research and memory, sending a
text ID to a WG has its advantages.

L.

---

From: James M Galvin <[email-masked]>
Date: Thu, 04 Jan 2001 09:19:06 -0500 (EST)

This distinction between filtering content and virus scanning is
confusing because they are not the same thing.

To choose to filter content (restrict it to text/plain or some other
limited set) would be changing the policy of this elist.  That is more
than an operational decision and probably deserves more debate, although
not here.

To choose to scan for viruses is an operational decision.  I never said
anything about safety.  You can not do virus scanning principally for
safety reasons.  To be sure that's a contributing factor but the truth
is you're only as safe as your last virus description update.  We're all
whining about vacation and virus notices and how we want them filtered
off the elist and I just don't see how filtering for viruses in the
first place is any different.

This is about being a "good net citizen".  Sending a virus to me (the
royal "me" because like Ted T'so viruses are irrelevant to me personally
since I use a UNIX box, a safe MUA, and my email system scans for
viruses) is only going to teach me that you know how to contribute to
the abuse of the Internet.

The source of the problem is not me for letting you send me a virus.
The source of the problem is the originator who sent the message and the
IETF elist is being used like an open email relay is used by spammers.
The IETF elist is irresponsibly contributing to the waste of resources
and abuse of the Internet.  Send the problem back to the originator, not
to me.  Unsubscribing them may make you feel better but it doesn't give
you the chance to chastise them, again and again if you're lucky.

And the argument about virus scanning being platform specific is
specious.  Your vulnerability to a virus is directly proportional to how
well you protect yourself.  Software developers/suppliers contribute to
this problem but if you were protecting yourself they wouldn't be in
business.  Microsoft Windows may be the predominant OS that supports
applications that contribute to the development and distribution of
viruses, but it is the application data that is the virus not the OS.
Microsoft Word macros can be run on UNIX and text/html with javascript
runs virtually anywhere.

A virus scanner scans content, a sequence of bytes.  It can do this on
any platform, regardless of the intended destination platform of the
content.  The virus may be platform specific but that is irrelevant.

Jim

---

From: chris d koeberle <[email-masked]>
Date: Thu, 4 Jan 2001 10:07:00 -0500 (EST)

> 2. Should the IETF elist restrict the type of content that can be

Bear this in mind when you say that - I am running (in the spirit of
inclusion) an operating system / mailservice that I wrote myself.  My
system is set up such that, upon receiving an e-mail which contains any
sort of attachment it does not recognize (and it doesn't recognize
anything but 7-bit ASCII text), it immediately replies to every address
mentioned in the e-mail, including every attachment, and throwing in a
virus for every other system for which one is known.  Please be certain to
include virus-scanning which respects the fact that to my system, all
attachments are viruses.

(Naturally, I have configured my system to APPEAR as though I'm just using
PINE, but trust me - it works the way I say it does.  Really.)

-= flail? http://flail.com/ =-
 -= the online comic strip =-

---

From: Russ Allbery <[email-masked]>
Date: 04 Jan 2001 17:04:39 -0800

>   Sending of IDs to the WG lists is a terrible practice.

Sending short IDs to WG lists or longer IDs in parts as the WG goes over
them results, in my experience, in more detailed and easier to follow
comments than pointers.  YMMV.  It's not appropriate for every version of
the ID, but it's not a bad idea at several points in the process.

---

From: John Stracke <[email-masked]>
Date: Mon, 08 Jan 2001 09:32:19 -0500

"Theodore Y. Ts'o" wrote:

> the more sympathy I have towards those who've argued for

Ah, but MS people seem to use Exchange exclusively, so filtering Exchange
from the list would get the attention of IETF participants at MS, leading
them to lean on the Exchange people.  Probably.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I'm not imaginary. I'm ontologically challenged.|
[email-masked]|                                                |
\=================================================================/