> From: Scott Lawrence <[EMAIL PROTECTED]>

> > Still, there are other good reasons why the IESG should add something like
> > the following to sendmail.cf on odin.ietf.org to reject multi-part junk:
> > 
> >      HContent-Type: $>+Check_CT
> >      SCheck_CT
> >      R$*multipart$*              $#error $: 553 reject multi-part junk
> > 
>
> That seems rather heavy-handed; I've often found the vcard 
> attachments to be quite handy, for instance.

What vcard attachments should be sent to the main IETF list?  Unless
a substantial majority of main IETF mailing list subscribers find them
useful, they should not be sent to the main IETF list.  I suspect
that not only are they not useful to a majority, but that a majority
could not use them even if they knew about them and wanted to.

Anything other than pure 7-bit ASCII is very hard to justify in an
international mailing list that is not a captive of a single vendor.


>                                               The IETF produced the 
> MIME standard that defines these things, after all.  The multipart 
> mechanism is not itself responsible for the bad ways in which it is 
> used.

Each time I hear that statement about MIME, it feels as if my blood
pressure ncreases 10%.  I've heard it so often that by now I should be
excreting diamonds.

Outside the offices of the pointy haired and of marketoons, the existence
of a tool is not a requirement for its use in absolutely positively every
context.  MIME is an excellent screwdriver, but it is silly to insist, as
many do, that MIME must be used everywhere a hammer is needed.  The most
common rationalization for MIME everywhere (including the exceptionally
dumb Eudora headers that announce 7-bit ASCII and no multi-parts) is
politically correct cant involving "diversity" (of people, not computers).


Vernon Schryver    [EMAIL PROTECTED]

Reply via email to