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