on Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna (adam@flounder.net) wrote:
> On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote:
> > #2, Misplaced burden, is the reason for the 'grave' severity.
>
> People have a right to ask that unkown people that e-mail them confirm
> the e-mail. I'm sorry you don't agree with this, but your opinion is
> hardly justification for a grave bug.
People also have the responsibility to accept, personally, the
responsibility for using, developing, and distributing systems which
impose this burden on others.
If you wish to undertake the distribution of TMDA yourself, with your
own resources, you are free to do so.
You may not demand the right to transfer these consequences on the
Debian Project and SPI over the objections (if present) of the project
at large. Determining the will of the Debian project is a purpose of
this discussion.
> > - TMDA should carry a warning to the user about possible consequences
> > of activating the C-R mechanism, including sending spam, risking
> > blacklisting or registration in spam-reduction services such as
> > SpamCop, and a likelihood that some, and perhaps a majority of
> > challenges will not be responded to. The warning should require the
> > user to assume full responsibility for doing so.
>
> Sorry, but no. I will not do this. The user presumably knows what he is
> installing.
"The User" demonstrably does not, in all, and possibly in most,
circumstances.
In my own cites of TMDA mailing list experiences, users have apparently
spammed thousands of arbitrary addresses with C-R challenges, and have
found their own systems listed by spam-prevention systems, with neither
the user, nor the architect of TMDA realizing the significance and
externalized costs of TMDA.
Moreover, inclusion of debconf warning messages is *NOT* a
responsibility of upstream, but of the Debian package maintainer.
> > - Configuration templates for C-R challenges _must_ incorporate virus
> > and spam filtering, _prior_ to issuing a C-R challenge. Preferably,
> > tests against obvious header spoofing, if possible, should be
> > performed. Debian tmda packages _must_ depend on corresponding spam
> > and virus filters, if this functionality isn't built into TMDA.
> >
> > - Additional strong validation mechanisms, including RFC 2015 PGP
> > signed mail and S/MIME signatures, _must_ be used to validate
> > sender, including use of web of trust to identify a reasonable
> > probability of trusted user status.
> >
> > - If possible, TMDA should be moved to SMTP-time filtering, so that
> > mail rejection occurs at SMTP time. As SMTP doesn't offer a
> > protocol for challenge-response, this introduces interesting
> > challenges for TMDA's developers.
> >
> > - TMDA's performance _must_ be independently validated and the target
> > maximum of 2% challenges to spoofed addresses be confirmed.
> >
> >
> >
> > I'm not going to pretend that these are easy fixes. I'm not a user of
> > this package. I _am_ negatively impacted by it, however, and if it
> > continues to display similarly poor consideration of security, abuse,
> > and adverse side effects, I fear for Debian, SPI, and the generosity of
> > our sponsors. I do feel the remedies are necessary and advised. They
> > should be communicated upstream, naturally.
>
> I suggest you take these suggestions to the TMDA worker's mailing list at
> tmda.net, and file wishlist bugs against TMDA for each desired feature.
For what reason can these suggestions not be accomplished (excepting
SMTP-time filtering and independent validation) through providing a
template which applies the proper processing order to a C-R challenge
issuing change, and C-R issuance be disabled unless working AV,
spamfilters, and signature validation SW are installed? Seems to me
upstream needn't be involved at all.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Sick of mal-formed websites? A stylesheet to override poor design:
http://twiki.iwethey.org/Main/UserContentCSS
Attachment:
pgp357QDhGwAp.pgp
Description: PGP signature