Subject: Re: Eliminating Virus Spam

From: Vernon Schryver <[email-masked]>
Date: Wed, 3 Jan 2001 18:56:17 -0700 (MST)

> From: [email-masked]

> > Please point to an example of a useful multipart message seen in
> > this list or that might someday be useful in this mailing list.

> Example:
>
> A multipart/signed message containing a pgp signature known to
> some/all members of this list.  As, for example, the ietf registrar pgp
> signature (see http://www.ietf.org/ietf-registrar.asc).

I'm not sure that is an example of a useful multipart message in this
or other plausible open international mailing lists. 

  - Messages from the IESG or other parts of the IETF bureaucracy that
     should reasonable be signed seems unlikely to be sent to this list.

  - I don't recall seeing that signature block in this list, and since
     I use a primitive MUA with very primitive MIME support normally
     turned off, I think I would have noticed.
     However, now that you remind me of the IESG's traffic, I think much
     of the IETF announcement list is multi-part.  Strangely, especially
     after this morning's burst, I don't have a sample handy to check.

  - Semi-private messages should not be sent to public, international lists.

  - Because signed messages are rare in public, signing is not much
     good in public lists.  If signed messages did become common that
     would change.  (There are reasons why I doubt they will become common,
     but let's not argue that now.)

  - http://www.ietf.org/ietf-registrar.asc is an awful lot of bits.
     That's not a consideration in some quarters, but few if any
     that I respect.

However, assume for the sake of argument that signature blocks are
reasonble.  Can you suggest a sendmail pattern that would exclude
other than signature blocks?  Perhaps the following?

     HContent-Type: $>+Check_CT
     SCheck_CT
     R$*multipart$*application/pgp-signature$*	$@ OK
     R$*multipart$*		$#error $: 553 reject multi-part junk

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Jan 2001 10:20:56 -0700 (MST)

> From: "Matt Crawford" <[email-masked]>

> I have sent to wg lists a multipart containing a preamble and an
> internet-draft or similar file.  This makes it easy for recipients to
> save the draft as-is.  Sometimes I have made the file a
> content/external-body to avoid stuffing O(100kB) into many mailboxes
> where it wouldn't be wanted.
>
> You said "this list", but the above scenario would apply if the
> document were pertinent to a BOF or brand-new working group.

I'm having trouble parsing that.  
I agree that depending on the I-D and the WG, sending I-D's to working
group lists is sometimes a good thing.  I don't think MIME is required
for that and wouldn't choose it myself, but I agree a working group could
agree to tolerate or prefer it.  However, sending I-D's to this list is
not only not kosher, but an anathema.

Sending content/external-body instead of the 100KB thing itself anywhere
could be swell, except that the state of word puts it somewhere between
irrelevant and a bad idea:
  1. many MUA's automatically dereference all pointers they find anywhere,
     whether in separate MIME attachments or in-line
  2. many slimey outfits use that fact with "web bugs" for violating privacy,
     and have convinced other outfits to help them do that (e.g. my
     soon-to-be-ex on-line stock broker)
  3. so anyone with any sense turns off all automatic dereferencing and
     uses the manual hooks to #1, and that makes content/external-body
     irrelevant.

In other words, who has the least trouble dereferencing a URL in a 7-bit
ASCII message without a single MIME header?

   ...........

] From: James M Galvin <[email-masked]>

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

Someone should tell Mr. Galvin that this is not a "general elist," although
it has been identified by some as a haunt of "elitist legacy programmers."

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

That seems to be based on a non-standard definition of "virus."  Neither
MS Word macros nor text/html javascript are likely to be infectious on
reasonable or even most UNIX boxes.  Just running MS Word macros on most
UNIX boxes is between difficult and impossible.  (Yes, I've heard about
StarOffice.)

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

If wishes were horses then beggars would ride.
Or what MIME attachment virus scanners are there for NetBSD?

]           The virus may be platform specific but that is irrelevant.

That sounds reasonable only to members of the Church of Redmond.