Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote: 2. All checks have to be automatic, and there is no chance of manual review to ensure that the messages where geniune before bouncing it. Actually, I'm pretty sure SA is statistically better than an average person scanning subject lines of an unfiltered inbox. And if a real user gets his message bounced as spam, he/she has a chance to retry the message via some alternative transport, like POTS or snailmail, instead of getting the message buried in the reciepents spam folder. -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | dark A bad analogy is like leaky screwdriver | pgpBxKSYrZ0ON.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Sat, Aug 30, 2003 at 09:41:39PM -0500, John Hasler ([EMAIL PROTECTED]) wrote: I wrote: This is about a quarter of my incoming mail. Karsten writes: Which? Bounces to spoofed senders, or improperly addressed mail? Bounces. Thanks. What prevents you from 550ing this at SMTP connect? The absence of any such connections. I'm on a dialup. Fair enough. I'm in the same boat. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? A guide to GNU/Linux browsers: http://twiki.iwethey.org/twiki/Main/NixBrowsers pgpYbdiLuITO6.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 10:42:17AM +1000, Brian May wrote: On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? no, i am not saying that. That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. the difference are : 1. a bounce is NOT the same thing as generating a new notification or confirmation message. 2. with modern MTAs that can reject mail from spammers/spamware/viruses during the SMTP session, there is no bounce message at all. by issuing a 5xx reject code during the smtp session, it leaves the task of bouncing the message up to the senderand very few (none, to my knowledge) virus or spamware programs have any code at all to send bounces. they just ignore the reject and move on to spamming the next victim address. this is beneficial both to the mail server itself (which is not clogged up with thousands of undeliverable bounces) and also to the poor bastard who has had their address forged by spamware or virus. reasons for rejecting during the smtp session include: unknown recipient, relay access denied, blacklisting (open relay, dialup/dynamic pool, known spam domain etc), local policies (message size, quota, etc), obvious spam/virus (e.g. content-filtering) and many others. 3. it is reasonable and correct for an MTA to assume that the sender address is correct. that is its job. it is not at all reasonable for an anti-virus or anti-spam system to make that assumption - almost all spam and most viruses are from forged addresses. this has been known for years, it is absolutely inexcusable that any anti-virus or anti-spam tool has been programmed without this knowledge in mind. 4. if an anti-virus or anti-spam mail system can NOT reject the mail during the smtp session then it MUST NOT send any notification/bounce back to the sender. the correct thing to do is to either tag the message and deliver it to the recipient address (perhaps after removing or de-fanging any virus), or to quarrantine it (and optionally send the *recipient* a notification message, or just let them check their quarranitine box every so often). The other option which many people seem to want is to discard the E-Mail without giving either party any indication of what happened. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. Do you simply discard such E-Mails (which gives no indication that something went wrong), or do you try to contact the sender to indicate that something went wrong? the answer to this is obvious: you reject it and leave it up to the sending mta/client to deal with it. if the sender is spamware or virus, there won't be any bounce message (nor should there be). if the sender is a legitimate client, then the user will be notified (usually via a dialog box) and the message will stay in the outbound queue or be bounced to the inbox or an error mbox. if the sender is a mail server, then it will bounce the message back to the original sender. if it was a legitimate email that bounced (e.g. unknown recipient) then that is what is supposed to happen. the only time this is a problem is when the sending MTA is an open relay, and the address was forged. there isn't much that can be done about that, however bounces from an open relay server will be rejected by any MTA that uses an open-relay blacklist (so no bounce will be delivered to the forged address). One approach for instance would be to modify the SMTP standard, and say if a host accepts the E-Mail then it is guaranteed to get it to the destination (ie. it signal OK until the message has been delivered), but that would break store-and-forward capabilities of secondary mail servers. that is pretty much the standard now, except that a host which accepts a message MUST either deliver it (directly or forward it on to the next hop), or it MUST bounce it. that word accept is crucial, however. if you don't accept the message (i.e. if you reject it with a 5xx reject code) then it's not your responsibility to either deliver or bounce it...it is the responsibility of the sending client or server. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. encryption and
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote: Backup MX servers serve no useful purpose in the modern Internet, this is why big sites such as microsoft.com and hotmail.com don't have them. agreed. If you have a backup MX then it should know all the acceptable email addresses in your domain and enforce all rules regarding acceptable content. Then it can block content through SMTP 550 and 450 codes. yes. if you don't have 100% administrative control over your backup MX server(s) then you should NOT be using them. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote: On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote: That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. A SMTP 550 code can convey all the information that is needed for bounces. There are two problems with this. 1. The modular design of SMTP agents like postfix do not allow scanning of messages before the message has been accepted by the MTA at the SMTP session. I think you would have to add hooks into smtpd, but that is going to complicate the code. not true. postfix header_checks and body_checks check the message *before* it is accepted by the MTA. if it fails the test, a final 5xx reject code is issued rather than a 2xx accepted code. recent experimental versions of postfix also allow the same thing to be done with content-filters, although use of this feature is not recommended by Wietse due to the time it takes for a filter like spamassassin to run - there is a risk of smtp timeouts, especially on busy servers. 2. All checks have to be automatic, and there is no chance of manual review to ensure that the messages where geniune before bouncing it. The list of known solutions follows: (nil) actually, the known solution is: - reject if you possibly can, tag and deliver otherwise. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, 30 Aug 2003 10:42, Brian May wrote: On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? Yes. That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. A SMTP 550 code can convey all the information that is needed for bounces. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. If the mail server it was sent to responded with: 550 Don't want ZIP files of .exe content Then the bounce message would have been clear and there would be no chance of it going to the wrong person. If the C-R systems we are discussing would send their challenge in the 550 SMTP code then I doubt that anyone would have any problem with them. The problem is that I see no easy way to fix this problem to the large scale required on the Internet while keeping store-and-forward feature of SMTP. The old-style store and forward is dead. Backup MX servers serve no useful purpose in the modern Internet, this is why big sites such as microsoft.com and hotmail.com don't have them. If you have a backup MX then it should know all the acceptable email addresses in your domain and enforce all rules regarding acceptable content. Then it can block content through SMTP 550 and 450 codes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Sat, Aug 30, 2003 at 10:42:17AM +1000, Brian May ([EMAIL PROTECTED]) wrote: On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? At the very least, this is a small subset of the incoming mail. There are probably bad practices, which should be fixed. The aim is also one which is presumably useful: if the sender is valid, then advising them that a message was not delivered is arguably useful (note that I regard most delivery failure messages as junk). Most importantly: the MTA isn't sending mail out willy-nilly to offload a cost (filtering, content assessment) to a third party. It's taking an action on a (hopefully) limited number of mails which cannot be delivered. SMTP Envelope reply address should be given precedence, and an SMTP error precedence over any bounce. That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. The message can't be delivered because of addressing errors is a different class of error than I can't be bothered to see if this mail is worth reading, despite its being properly addressed to me. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. A publicly available key, with an email address (or addresses), validated against contents, is useable. It doesn't validate the sender, but it provides a level of indication that someone went through the trouble of getting a key, posting it publicly, and signing (and/or encrypting) content with it. That's more elbow grease than your garden-variety spammer. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Hollings: bought, paid for, but couldn't deliver the CBDTPA: http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html pgpea857fP6eC.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Brian May writes: You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? Karsten M. Self writes: At the very least, this is a small subset of the incoming mail. This is about a quarter of my incoming mail. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
I think challenge response needs extra care. Anyway, current e-mail worm/virus incident is pretty bad. On Sat, Aug 30, 2003 at 07:44:56AM -0500, John Hasler wrote: Brian May writes: You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? Karsten M. Self writes: At the very least, this is a small subset of the incoming mail. This is about a quarter of my incoming mail. I filter e-mail worm/virus mail bounces by reading the attached original mail header. Most bounces keep the good amount of original header information. ## Worm e-mails by the header :0 * ^X-Mailer: Microsoft * ^X-MailScanner: Found to be clean Xworm/ ## Worm bounces by the headerbody :0 BH * ^FROM_MAILER * ^X-Mailer: Microsoft * ^X-MailScanner: Found to be clean Xworm-bounce/ I guess our e-mail server can do the similar checks. Osamu
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote: That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. A SMTP 550 code can convey all the information that is needed for bounces. There are two problems with this. 1. The modular design of SMTP agents like postfix do not allow scanning of messages before the message has been accepted by the MTA at the SMTP session. I think you would have to add hooks into smtpd, but that is going to complicate the code. 2. All checks have to be automatic, and there is no chance of manual review to ensure that the messages where geniune before bouncing it. The list of known solutions follows: (nil) ;-) I have considered to possibility of using something like zorp to act as a proxy SMTP server between the client and the real server, but that would not work for encrypted SMTP communications. ...and Yes, now that I have enabled SSL on my postfix, at least some spammers do use encrypted SMTP sessions. -- Brian May [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, 30 Aug 2003 23:49:40 + Brian May [EMAIL PROTECTED] wrote: 1. The modular design of SMTP agents like postfix do not allow scanning of messages before the message has been accepted by the MTA at the SMTP session. I think you would have to add hooks into smtpd, but that is going to complicate the code. Well, that's postfix's problem. After years of hearing how modular is the superior method it is kind of ironic that a simple solution is complicated. 2. All checks have to be automatic, and there is no chance of manual review to ensure that the messages where geniune before bouncing it. Trust me, if SA scores it high enough do you really want to worry about it? Running SA-Exim here and with sensible defaults I've 550'd most spam and, after the Bayesian filtering caught up, most of the recent viruses. I am perfectly capable of of reviewing the messages as I have the option of saving them for review. I define the levels at which things get accepted, rejected or even teergrubed. So far my false positives have been exactly 0 for rejects as I allow a small window for grey area messages to get through for the user to manage. In that window exactly 2 messages were false-positives and they were/barely/ high enough to be marked as spam. This has been so effective I've been working on getting clamav hacked into Spamassassin so that future virus attacks can be avoided without the painful Bayesian ramp-up. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpV7r5ETQv8e.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 05:26:59PM -0700, Steve Lamb wrote: On Sat, 30 Aug 2003 23:49:40 + Brian May [EMAIL PROTECTED] wrote: 1. The modular design of SMTP agents like postfix do not allow scanning of messages before the message has been accepted by the MTA at the SMTP session. I think you would have to add hooks into smtpd, but that is going to complicate the code. Well, that's postfix's problem. After years of hearing how modular is the superior method it is kind of ironic that a simple solution is complicated. I don't see any reason why postfix couldn't be readily adapted to support hooks to external program checks, if it really doesn't support them already. You can do just about any other kind of check you want to at any point in the receiving process, external program checks shouldn't be all that hard to add. -- Steve Langasek postmodern programmer pgpShfmHfA2tw.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Sat, Aug 30, 2003 at 07:44:56AM -0500, John Hasler ([EMAIL PROTECTED]) wrote: Brian May writes: You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? Karsten M. Self writes: At the very least, this is a small subset of the incoming mail. This is about a quarter of my incoming mail. Which? Bounces to spoofed senders, or improperly addressed mail? What prevents you from 550ing this at SMTP connect? Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? KQED FM: The bright spot on the dial: http://www.kqed.org/fm/ pgpIh22S5cRqH.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
I wrote: This is about a quarter of my incoming mail. Karsten writes: Which? Bounces to spoofed senders, or improperly addressed mail? Bounces. What prevents you from 550ing this at SMTP connect? The absence of any such connections. I'm on a dialup. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Friday 29 August 2003 09:28, Steve Lamb wrote: On Fri, 29 Aug 2003 00:36:57 -0700 Adam McKenna [EMAIL PROTECTED] wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. exacerbate is probably what you meant here. ben
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 16:31:59 + benfoley [EMAIL PROTECTED] wrote: On Friday 29 August 2003 09:28, Steve Lamb wrote: Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. exacerbate is probably what you meant here. Quite so. 1:30am emails before the requisite round of CS to wake-up are prone to errors, no? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpMC75FKYQ9o.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
* Adam McKenna #0, #1, #2 and #11 are basically opinion and rhetoric. Well. Let's take a look at what Karsten had to say about point #2, Misplaced burden: [...] «C-R may place the burden on third parties either inadvertently (via spoofed sender spam or virus mail), or deliberately (see Joe-job below).» [...] You dismiss this as basically opinion and rhetoric. Yet, I see a unsolicited junk mail from you, yes - *you* Adam, in my mailbox. I'd be very interested in hearing how that could've been a result of 'opinion and rhetoric', so please, let me know. Earlier, you've stated that your time is precious. Well, so is mine. How dare you assume that the time I spent reviewing *your* callenge mail and deciding it was junk is less precious than the time you (could have) spent reviewing the mail that spurred the challenge in the first place? I admit my first email was written in hot blood, but if TMDA actually endorses this selfish behaviour, I still feel it is something that do not belong in Debian. On the other hand, if the junk mail in my inbox was a result of a misconfiguration on your part, then I'm sorry for yelling so loud. Errare humanum est. -- Tore Anderson
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 02:46:48AM +0200, Tore Anderson wrote: Earlier, you've stated that your time is precious. Well, so is mine. How dare you assume that the time I spent reviewing *your* callenge mail and deciding it was junk is less precious than the time you (could have) spent reviewing the mail that spurred the challenge in the first place? I admit my first email was written in hot blood, but if TMDA actually endorses this selfish behaviour, I still feel it is something that do not belong in Debian. On the other hand, if the junk mail in my inbox was a result of a misconfiguration on your part, then I'm sorry for yelling so loud. Errare humanum est. I've already stated that I've modified my incoming mail filters so that these viruses will no longer hit TMDA. I feel bad that others were affected due to my misconfiguration, but it was user error (or laziness in this case) that caused this, not a fundamental problem with the software. When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 00:36:57 -0700 Adam McKenna [EMAIL PROTECTED] wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp81Uf26k2Ll.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 04:31:59PM +, benfoley wrote:
On Friday 29 August 2003 09:28, Steve Lamb wrote:
On Fri, 29 Aug 2003 00:36:57 -0700
Adam McKenna [EMAIL PROTECTED] wrote:
Well, since we're pointing fingers, it's really SMTP that's broken by
design, and all anti-spam programs (including C-R systems) are merely
stopgap measures that try to make up for SMTP's shortcomings.
Oddly enough Spamassassin doesn't exasperate the problem. TDMA does.
exacerbate is probably what you meant here.
Actually, I think exasperate is perfectly valid as well.
From WordNet (r) 1.7 [wn]:
exasperate
v 1: exasperate or irritate [syn: {exacerbate}, {aggravate}]
2: make furious [syn: {outrage}, {infuriate}, {incense}]
3: make worse; This drug aggravates the pain [syn: {worsen},
{aggravate}, {exacerbate}] [ant: {better}]
- Keegan
pgpkdhOOQymzr.pgp
Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna ([EMAIL PROTECTED]) 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.comhttp://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 pgpmcc4tXb539.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. Why not make your tmda package depend on amavis-new and clamav-freshclam? If they are installed and correctly configured then virus filters should get updated as fast as is possible. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
reassign 207300 humanity thanks On pe, 2003-08-29 at 10:36, Adam McKenna wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. The fact that SMTP now needs authentication and what not points at the real problem: there are greedy and evil people willing to exploit anything for their personal benefit. In the interest of fixing things once and for all, that flaw in humanity needs to be fixed. It is not enough to kill all greedy and evil people, since new ones will be born. I propose killing all humans and letting the planet be inherited by us Martians. On a more serious note, it would be interesting to have a thought experiment of how an e-mail system could be designed from scratch (no compatibility with SMTP needed). Debian-devel is not the forum for it, though. I develop and maintain one mailing list manager, and it will send confirmation requests for subscriptions, unsubscriptions, and messages that will wait for moderation. I'll make it so that it will avoid sending them if the message that triggered them looks too much like spam. At least that much good results from this thread. :) -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna 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. the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. such software is too brain-damaged to use. there is more than enough spam, viruses and other garbage clogging SMTP servers around the world without making things worse by using programs which falsely claim to be part of the solution. junk like this does not solve the problem, it is not part of the solution - it just amplifies the original problem: every virus or spam with forged headers results in even more confirmation and/or notification messages being sent in response. in short, it is automated spamware that contributes to denial of service attacks. craig
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 12:12:58PM +1000, Russell Coker wrote: On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. Why not make your tmda package depend on amavis-new and clamav-freshclam? If they are installed and correctly configured then virus filters should get updated as fast as is possible. Does Amavis automatically configure itself for whatever MTA is installed and start scanning mail immediately? If not, then I don't see how a Depends: would help. I would consider adding a Suggests: or Recommends:. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. Really? TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 01:42:53AM +1000, Russell Coker wrote: PS Before someone raises the issue of license of viruses. I believe that anyone who distributes a virus does so with the desire that it be installed on as many systems as possible and that the implied license permits you to have a copy of it for whatever purposes you desire. People who wish to limit the use of their software in any way should make it refrain from installing itself on hundreds of thousands of machines without the consent of the owners. :-# ... but you don't always get the source code, this is required by the DFSG ;-). -- Brian May [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. The other option which many people seem to want is to discard the E-Mail without giving either party any indication of what happened. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. Do you simply discard such E-Mails (which gives no indication that something went wrong), or do you try to contact the sender to indicate that something went wrong? The problem is that I see no easy way to fix this problem to the large scale required on the Internet while keeping store-and-forward feature of SMTP. One approach for instance would be to modify the SMTP standard, and say if a host accepts the E-Mail then it is guaranteed to get it to the destination (ie. it signal OK until the message has been delivered), but that would break store-and-forward capabilities of secondary mail servers. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. -- Brian May [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 05:40:46PM -0700, Don Armstrong wrote: On Wed, 27 Aug 2003, Adam McKenna wrote: TMDA does not ship with any defaults, except a couple of customizable text files (templates). It is entirely up to the user to create a TMDA configuration along with his own whitelist and filter directives. If possible, perhaps you could consider whitelisting common debian.org address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc.] When I said there are no defaults, I meant it. There is no system-wide TMDA configuration. Installing TMDA is analagous to installing procmail, or maildrop, or any other mail filtering software. In order to utilize it, you must configure your MTA to deliver mail to it, and set up several configuration files (e.g. .procmailrc in procmail's case or .mailfilter in maildrop's case). The whitelist is just a list of e-mail addresses. I could include a sample whitelist, but listing the recommended addresses to whitelist in README.Debian should be equivalent or better. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 05:40:46PM -0700, Don Armstrong wrote: If possible, perhaps you could consider whitelisting common debian.org address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc.] And would probably defeat the purpose since spammers would know which adresses they have to spoof into the From: Header. Furthermore, if spammers got that, it might happen that they use debian.org adresses as sensible default for From: Adresses which will raise the amount of Bounces to debian.org. That sounds like a great way for the Project to shoot itself into the feet. -- | Rico -mc- Gloeckner | mv ~/.signature `finger [EMAIL PROTECTED] | | Encrypted Mails preferred: 1024D/61F05B8C | | 3D67 D42F 2D50 4B68 1D62 E999 EFCB CDFF 61F0 5B8C |
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
First note: ISP mailbox overflow due to Sobig.F knocked me off a few Debian lists, I've just resubscribed. I've got a partial copy of this thread thanks to a friend who forwarded it to me. I've also been following the discussion in the d-d archives and BTS. Thanks to all who've commented on this topic. Interesting reading. Adam: my email is [EMAIL PROTECTED] I've set the $EMAIL environment variable 'bug' uses. General response to those who've suggested that general distaste for software is sufficient cause for a grave bug filing. Specious. The current response is on mark: behaviour which doesn't maliciously affect other users or third parties should be exempted. _Bugs_ which can be exploited to do same would be grounds. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03635.html General response to those noting that there is software which _can_ be configured in such a way that users shoot themselves or others in the foot. A configuration concern, but not necessarily a bug. If this isn't a design intent, or isn't a default configuration, then a grave bug is unwarranted. Warning documentation, or an important debconf screen requiring input along the lines of Yes, I understand that this setting may cause grave harm and accept full responsibility might be (and probably is) appropriate. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03637.html General response to those who claim that user interest is sufficient to include a package in Debian. Above and beyond comments by Joey Hess, there is this to consider: including a package in Debian both offers the support and infrastructure Debian, SPI, and various sponsoring organizations provide, _and_ puts these entities at risk for malfeasance which may be conducted, intentionally or otherwise, as a result of this package. Which is a damned good reason for Debian not to package viruses and spam mailers. Or tools which can be readily subverted as such. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03680.html on Wed, Aug 27, 2003 at 01:34:53PM -0700, Adam McKenna ([EMAIL PROTECTED]) wrote: On Wed, Aug 27, 2003 at 07:49:27PM +0100, Colin Watson wrote: On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: Adam McKenna wrote: The arguments are facile and specious, I do not intend to waste my precious time responding to them. That's a shame. I don't believe Karsten to be in the habit of putting forward specious arguments. Well, let's see, I'll try to be brief: An admission: the Considered Harmful essay is a general argument against C-R systems, not specifically TMDA. TMDA does share some, though not all faults. Not all of these should be considered grave. Some are. #0, #1, #2 and #11 are basically opinion and rhetoric. Karsten has stated that he has a 'religious' objection to CR, and I'm not willing to have a debate about it. I've already noted some of the places that Karsten can go if he wants a debate. #0 (Weak verification) is a statement of established fact: SMTP headers are readily forged, as is adequately discussed in this thread. #1 (Mistaken interpretation) is a statement of opinion, but weighs strongly on other factors, in particular #2 and #4. #2, I'll get back to. #11 (techno-economic underpinnings) is largely irrelevant to the current discussion, though it weighs on the merits of pain and harm created through C-R systems, relative to the benefits, and existence of currently feasible alternatives. #3 blames CR for actions taken by an ISP (IOW, user configuration error). (Privacy violation) Subpoenability or other data leakage of personal communications data which is enabled by virtue of a systems design (C-R's requirement that a whitelist be maintained online or nearline at the SMTP server for proper operation) is a risk in both the United States and other countries under current legal doctrine. While not a grave bug, it warrants a warning in documentation. Better would be a requirement to notify users in an ISP situation of this risk, though I'm not sure this can be mandated under DFSG software licenses. For a related issue of security and logs, see: http://cryptome.org/no-logs.htm In a broader sense, for configuration errors which are made by a large class of users, blame cannot be laid entirely on them. There was a tradition in the early industrial age to blame accidents -- as acts of God -- either on, well, God (He didn't seem to mind) or workers. This until principles of scientific management (Taylorism) and statistical process control were developed, and it could be shown that accident rates in different situations varied wildly. Bog-obvious now, but a big leap at the time. Today, a major issue in computer security and administration are the plague of ills launched forth from Microsoft platforms. We've seen the Internet brought to its knees three times this year, twice in a week. And the blame
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Thu, Aug 28, 2003 at 08:56:36AM +0200, Rico -mc- Gloeckner ([EMAIL PROTECTED]) wrote: On Wed, Aug 27, 2003 at 05:40:46PM -0700, Don Armstrong wrote: If possible, perhaps you could consider whitelisting common debian.org address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc.] And would probably defeat the purpose since spammers would know which adresses they have to spoof into the From: Header. Furthermore, if spammers got that, it might happen that they use debian.org adresses as sensible default for From: Adresses which will raise the amount of Bounces to debian.org. That sounds like a great way for the Project to shoot itself into the feet. That would be an example of #0. With a twist. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? GNU/Linux web browsing mini review: Galeon. Kicks ass. http://galeon.sourceforge.org/ pgp4TDCrFo7tX.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Just some additional data points as I have been following this and other related C-R threads for a while now. On Thu, 28 Aug 2003 12:35:25 +0100 Karsten M. Self kmself@ix.netcom.com wrote: [ Snip ] Specific to my own experience: over half the C-R challenges (TMDA or otherwise) I've received have been for mail I didn't send. I expect this trend to increase in both magnitude and percentage. I'm likely to either ignore messages or filter them with other spam. The only C-R challenges I've gotten were when I actually responded to Alan Conner on D-U by accident. He had a habit of setting his reply-to and Sylpheed-Claws honored it. Normally I hit reply and get the list. This accounts for 3 C-R ever. Since they I've gotten at least a hundred or so in recent days thanks to the virus going around. [ Snip ] More chillingly, other users post Sobig.F stats: TMDA and Sobig.F virus - praise Sven Neuhaus [EMAIL PROTECTED] Thu, 21 Aug 2003 17:04:09 +0200 http://mla.libertine.org/tmda-users/2003-08/msg00120.html In the last 3 days, I received more than 4000 copies of the Sobig.F virus. Thanks to TMDA, I didn't even notice it until today (when I noticed the 330megs in my pending folder). That's 4,000 innocent parties spammed with C-R challenges, if I'm interpreting what the meaning of 330 MiB in the pending folder is. This... is scary. Within hours of one machine trying to hit me I had blacklisted him at the firewall and implored my secondary MX to do the same. It was because each instance of a bounce or the virus itself was 100k. Praise for being ignorant of 4Gb of traffic being moved!? Praise for moving 4Gb in bounces? That's bordering on criminal. [ Snippage ] This then leaves a small number of messages daily to be assessed -- they are not viruses, spam, or on an existing whitelist. My question at this point is: why not simply look at the damned mail and figure out for yourself whether or not it's worth reading? We're probably talking something like a couple of items, a few times a week. I posted a message to d-u a few weeks back with hard stats about that narrow band. I think it came down to 4 a week as my rough estimate. And, so far, not a single piece in that band was legitimate. I was in the process of adjusting sa-exim's limitations downward since the band wasn't so narrow any more. With Bayesian filters on, razor checked and auto-learning set to -2 and +5 for ham and spam respectively my average ham score was quickly approaching -5 and my average spam score was pushing well over 6 with very little, if anything, in between. I think I saw 1-2 pieces a day with scores between those two points. I figure if I adjusted my scores downward I would have been able to cut that close to 1 every 10 days or so. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpxadPeDtMVs.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Karsten M. Self kmself@ix.netcom.com wrote: [...] SpamAssassin achieves a false-positive rate (non-spam reported as spam) of 5% with a default threshold of 5. This can be dramatically improved using a whitelist, to ~98% in my experience. This is not the best performance of all filters, so makes a somewhat generous threshold. http://www.spamassassin.org/dist/rules/STATISTICS.txt http://freshmeat.net/articles/view/964/ So a spam-reduction system user would at worst see a typical rate of 2% of spam to be manually disposed of. [...] You are mixing up percentages. 5% non-spam reported as spam ... can be ... improved to ~98% ... I would not use a filter which would tag 98% of my regular mail as spam. Perhaps you wanted to write 2%? No, does not match either, because the last sentence does not talk about false-positive at all, it talks about false negatives, i.e. spam that was tagged as non-spam. When I last checked my personal rate with spamassassin 2.55 with default rules and no DNS lists or razor (but including a rather well trained bayesian filter) and a default threshold of 5, I came up with these numbers[1]: * 0% false positives, i.e. ham sorted into the spam folder * 10% of the spam was not recognized as such and I had to filter it out by hand. Of course the numbers depend a lot on the people you are communicating with, if your partners used Lotus Notes and sended everything in html you might get false positives with score 5. A properly trained bogofilter will give better results but is not as effective as site wide service an requires more work to keep it properly trained. cu andreas [1] I am quite happy with these, I can live with ~10 spams per day in my inbox. -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 05:35:14PM +0200, Florian Weimer wrote: That's why it's better to get rid of generic MX secondaries (IOW secondaries which are not under you administrative control). The Which is fine if you're lucky enough to have root on a set of conveniently distributed hosts... example, you might want to defer a message from a sender whose temporarily domain doesn't have any MX (or A) record. If you do this, significant numbers of messages will pile up in the queues of your secondary MXes, and their operators won't be happy about that. So I discovered with recently RBL shutdowns :-) Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 12:03:34AM +1000, Russell Coker wrote: On Thu, 28 Aug 2003 21:35, Karsten M. Self wrote: Which is a damned good reason for Debian not to package viruses and spam mailers. Or tools which can be readily subverted as such. My Postal program can be used for DOS attacks on mail servers, and has been used for such on at least one occasion (*). I disagree with your conclusions regarding putting viruses in Debian. I think it would be a useful service for people who analyse such things to have copies of viruses in usable form. The EICAR.COM test pattern exists solely for that purpose. I wouldn't have any problem with putting testpatterns in packages that are supposed to do some security tests (or something similar), but putting viruses in the Debian archive is a bad idea. If I misunderstood you, please ignore this mail :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgptsKOmtCJUL.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
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. - 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. - 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. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 01:32, Wouter Verhelst wrote: I disagree with your conclusions regarding putting viruses in Debian. I think it would be a useful service for people who analyse such things to have copies of viruses in usable form. The EICAR.COM test pattern exists solely for that purpose. I wouldn't have any problem with putting testpatterns in packages that are supposed to do some security tests (or something similar), but putting viruses in the Debian archive is a bad idea. Test patterns can't be executed and thus miss most of the value of a live virus for analysis purposes. I know that most people would disagree with me strongly on this issue, so I wouldn't bother pushing it even if it wasn't for the issue of Debian packages not being for arbitary binaries. If I misunderstood you, please ignore this mail :-) I think you simply disagree with me so greatly on this issue that you couldn't believe I meant what I said. It's no big deal. As I have other reasons for thinking that live viruses don't belong in Debian we can at least agree to not have them, even though we disagree on the reasons for not having them. PS Before someone raises the issue of license of viruses. I believe that anyone who distributes a virus does so with the desire that it be installed on as many systems as possible and that the implied license permits you to have a copy of it for whatever purposes you desire. People who wish to limit the use of their software in any way should make it refrain from installing itself on hundreds of thousands of machines without the consent of the owners. :-# -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: - TMDA should carry a warning to the user about possible consequences of activating the C-R mechanism, including sending spam, risking Sorry, but no. I will not do this. The user presumably knows what he is installing. It's entirely reasonable to ask that the documentation be improved to cover the problems that may arise from using the package. Saying that the user already knows what the package does isn't entirely helpful since the user may be looking at the package trying to see if it's something worth investigating rather than already being an expert user. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, 28 Aug 2003 21:35, Karsten M. Self wrote: Which is a damned good reason for Debian not to package viruses and spam mailers. Or tools which can be readily subverted as such. My Postal program can be used for DOS attacks on mail servers, and has been used for such on at least one occasion (*). I disagree with your conclusions regarding putting viruses in Debian. I think it would be a useful service for people who analyse such things to have copies of viruses in usable form. I am not requesting them only because arbitary archives of files don't belong in Debian. Debian packages are for programs that comprise parts of the distribution and for data files used for them, not arbitary other data. I believe that Linux based tools for auditing network security belong in Debian. We rightly have nmap and nessus, other tools of a similar nature also belong in Debian. If DMCA issues prevent distribution of such things through the US then they can go in non-US. (*) An idiot complained to me because the URL for Postal was in the headers of the thousands of messages they received. It didn't occur to them that the URL was there to inform any victim of an attack of what they were facing, and is also intended to be a conveniant header string that can be blocked in a mail server to stop such an attack. Presumably other more intelligent people had their servers attacked by Postal and were smart enough to configure their header checks without bothering me. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 05:10:07PM +0100, Mark Brown wrote: On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: - TMDA should carry a warning to the user about possible consequences of activating the C-R mechanism, including sending spam, risking Sorry, but no. I will not do this. The user presumably knows what he is installing. It's entirely reasonable to ask that the documentation be improved to cover the problems that may arise from using the package. Saying that the user already knows what the package does isn't entirely helpful since the user may be looking at the package trying to see if it's something worth investigating rather than already being an expert user. I've already stated that I am more than willing to add documentation. What I will not do is put in some sort of scary warning that makes people change their mind about using the software. They can go look at Karsten's website if they want that. And no, I'm not putting in a link. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: Thanks to all who've commented on this topic. Interesting reading. Likewise, Karsten. That was a very well written rebuttal to a C-R systems. You followed up with suggetions on using C-R only as a last resort in a mail management tool and only after a modest attempt at detecting spoofed headers was made. I think you've hit upon the core of the issue: no one filtering techniqueue is bullet-proof on its own. The author of TMDA acknowledges this on the TMDA website. It really shouldn't be used as a sledgehammer solution. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpeSkyhtZvsW.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 01:42:53AM +1000, Russell Coker wrote: On Fri, 29 Aug 2003 01:32, Wouter Verhelst wrote: I disagree with your conclusions regarding putting viruses in Debian. I think it would be a useful service for people who analyse such things to have copies of viruses in usable form. The EICAR.COM test pattern exists solely for that purpose. I wouldn't have any problem with putting testpatterns in packages that are supposed to do some security tests (or something similar), but putting viruses in the Debian archive is a bad idea. Test patterns can't be executed and thus miss most of the value of a live virus for analysis purposes. Ah, *that* kind of analysis :-) I know that most people would disagree with me strongly on this issue, so I wouldn't bother pushing it even if it wasn't for the issue of Debian packages not being for arbitary binaries. If I misunderstood you, please ignore this mail :-) I think you simply disagree with me so greatly on this issue that you couldn't believe I meant what I said. No, I really misunderstood you. In fact, I keep a copy of all viruses that are sent to me in a directory on my mailserver. Think of it as a collection; not that I would analyse them, but they could become handy for other purposes. It's no big deal. As I have other reasons for thinking that live viruses don't belong in Debian we can at least agree to not have them, even though we disagree on the reasons for not having them. :-) [...] -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpM7zJ5H7RS1.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Quoting Adam McKenna ([EMAIL PROTECTED]): 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. This is an attempt to change the subject: The issue at hand is the cited maintenance (and acceptance) issues concerning the Debian package. If on the other hand the above was just a novel way to say No and dig in your heels, there are more direct (and concise) ways to do it, ja? -- Cheers, The only good goth is a shoggoth Rick Moen -- Alistair J.R. Young, in r.a.sf.w.r-j [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 10:27:43AM -0700, Rick Moen wrote: Quoting Adam McKenna ([EMAIL PROTECTED]): 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. This is an attempt to change the subject: The issue at hand is the cited maintenance (and acceptance) issues concerning the Debian package. If on the other hand the above was just a novel way to say No and dig in your heels, there are more direct (and concise) ways to do it, ja? I don't intend to implement Karsten's requests myself, so it makes sense that he take his beef upstream. I am happy to forward his wishlist bugs upstream, but since I do not have as fervent a desire to see them implemented, Karsten will probably be a better advocate. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Thu, Aug 28, 2003 at 03:09:48PM +0200, Andreas Metzler ([EMAIL PROTECTED]) wrote: Karsten M. Self kmself@ix.netcom.com wrote: [...] SpamAssassin achieves a false-positive rate (non-spam reported as spam) of 5% with a default threshold of 5. This can be dramatically improved using a whitelist, to ~98% in my experience. This is not the best performance of all filters, so makes a somewhat generous threshold. http://www.spamassassin.org/dist/rules/STATISTICS.txt http://freshmeat.net/articles/view/964/ So a spam-reduction system user would at worst see a typical rate of 2% of spam to be manually disposed of. [...] You are mixing up percentages. 5% non-spam reported as spam ... can be ... improved to ~98% ... Correct. And yes, I was thinking false-negative. Spam not flagged as spam. What I meant to say was this: - Currently feasible content-based filters + whitelists can achieve a spam rate of 2% of spam passing to the inbox, by independent tests. - A C-R system should then target having no more than 2% of challenges sent be misdirected (based on spoofed headers, etc.). At this rate, it's still transferring burden inappropriately, but at a level that matches a reasonable-case technological alternative. This also achieves a secondary goal in the interests of C-R proponents of keeping the incidence of false challenges low enough that recipients would be likely to respond to the challenge. When I last checked my personal rate with spamassassin 2.55 with default rules and no DNS lists or razor (but including a rather well trained bayesian filter) and a default threshold of 5, I came up with these numbers[1]: * 0% false positives, i.e. ham sorted into the spam folder * 10% of the spam was not recognized as such and I had to filter it out by hand. I use a whitelisting system. It's based on Lars Wizenius's spamfilter package, my local add being a shell script to scan messages for sender to add to white, black, gray, or spam lists. Mail from previously unknown senders ends up in a grey box. The principle is the same as C-R, except that assessment is done by me, rather than a third party. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Verio webhosting? Guaranteed downtime: http://www.wired.com/news/politics/0,1283,57011,00.html http://www.dowethics.com/r/environment/freedom.html pgp7SQrlsknKk.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Fri, Aug 29, 2003 at 12:03:34AM +1000, Russell Coker ([EMAIL PROTECTED]) wrote: On Thu, 28 Aug 2003 21:35, Karsten M. Self wrote: Which is a damned good reason for Debian not to package viruses and spam mailers. Or tools which can be readily subverted as such. My Postal program can be used for DOS attacks on mail servers, and has been used for such on at least one occasion (*). Can be used and is designed to do when used as directed has already been dealt with and dismissed as a separate case from the one under consideration. My understanding of postal is that it is launched at the direction of a local user. While this could be embedded into other mechanisms (cgi, procmail, etc.), it's not packaged or designed specifically for this. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Spread the real scoop on Xenu and The Church of Scientology, link a href=http://xenu.net/;;Scientology/a on your website. pgpDK1orK2Wyr.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Tore Anderson [EMAIL PROTECTED] writes: How many other innocent third parties have you spammed through the use of this broken program? How many of these are Debian users, do you think? I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. 0) Substitute for any MTA you like or dislike. -- Peter Makholm | Have you ever felt trapped inside a Klein bottle? [EMAIL PROTECTED] | http://hacking.dk |
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
[ Please do not send me CC's, as I have not explicitly asked for them. ] * Tore Anderson How many other innocent third parties have you spammed through the use of this broken program? How many of these are Debian users, do you think? * Peter Makholm I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. I fully agree, and I would not hesitate to submit a RC bug on the Postfix (or any other MTA) package, if it by default came with the broken configuration you speak of. However, a quick test shows that this is not the case (as Postfix appears to reject the SMTP RCPT command for non-existent accounts), so I fail to see how it is relevant. -- Tore Anderson
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 12:58:19PM +0200, Peter Makholm wrote: Tore Anderson [EMAIL PROTECTED] writes: How many other innocent third parties have you spammed through the use of this broken program? How many of these are Debian users, do you think? I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. I think the difference here is that postfix never bounces valid emails. Apparently TMDA will under some situations??? (however, I am not making any judgements as far as this dispute is concerned; I am not familiar with TMDA either). -- Brian May [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 01:43:29PM +0200, Tore Anderson wrote: However, a quick test shows that this is not the case (as Postfix appears to reject the SMTP RCPT command for non-existent accounts), so I fail to see how it is relevant. Sometimes, there is no choice. That could be the case if, for instance, you are backup MX for a server that is down. You have accepted the message from the original sender already -- possibly hours ago. The primary server comes back up and rejects the message. You have no choice but to generate a bounce mail to the original sender. This behavior is not limited to Postfix. Perhaps you would like to file a grave bug against the SMTP virtual package?
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 01:43:29PM +0200, Tore Anderson wrote: I fully agree, and I would not hesitate to submit a RC bug on the Postfix That's a completely inappropriate use of the RC severity, and possibly the BTS entirely. The discussion is a good and useful one, trying to inflate your difference of opinion into an RC bug is not. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpavE8qre6Jt.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 10:00:13PM +1000, Brian May wrote: On Wed, Aug 27, 2003 at 12:58:19PM +0200, Peter Makholm wrote: Tore Anderson [EMAIL PROTECTED] writes: How many other innocent third parties have you spammed through the use of this broken program? How many of these are Debian users, do you think? I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. I think the difference here is that postfix never bounces valid emails. Apparently TMDA will under some situations??? [...] TMDA will send a mail saying something along the lines of This is the first mail I've received from your address, I won't actualy recieve it until you send verify fgf$%ZTRD4315835671658998719710 to [EMAIL PROTECTED] Comparing to vacation(1) fits better. cu andreas
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Peter Makholm [EMAIL PROTECTED] writes: I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. Most MTAs support rejecting unknown destinations at the SMTP level. They don't generate bounce messages in such cases. It's a pity if Postfix can't do this. So far, I assumed only qmail had this weird property.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
John Goerzen [EMAIL PROTECTED] writes: Sometimes, there is no choice. That could be the case if, for instance, you are backup MX for a server that is down. You have accepted the message from the original sender already -- possibly hours ago. The primary server comes back up and rejects the message. You have no choice but to generate a bounce mail to the original sender. That's why it's better to get rid of generic MX secondaries (IOW secondaries which are not under you administrative control). The effect you describe hampers effective anti-spam measures, too. For example, you might want to defer a message from a sender whose temporarily domain doesn't have any MX (or A) record. If you do this, significant numbers of messages will pile up in the queues of your secondary MXes, and their operators won't be happy about that.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Stephen Stafford wrote: As long as SOME users like it, and find it useful and it fits THEIR needs, then we should not be removing it from Debian (as long as it meets DFSG). Great! Then someone needs to revive that ITP filed April 1st 2002. This new policy will certianly make a lot of script kiddies very happy. -- see shy jo pgpN7fm59MxZx.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 12:37:36PM +0100, Colin Watson wrote: Perhaps some compromise could be found here to improve the package's description. Adam, I also think it would be helpful if you could respond to at least some points from the original bug report. I do believe that Karsten has thought about this in some thoroughness and is not simply trying to antagonize you. The arguments are facile and specious, I do not intend to waste my precious time responding to them. There is no reason for me to remove TMDA from Debian, and therefore I will not do so. If Karsten or anyone else wants to have a debate about which of these arguments apply to TMDA, and why, then I suggest he take his complaints to the upstream mailing lists @tmda.net. I will not debate this in the BTS or on any debian list. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Adam McKenna wrote: The arguments are facile and specious, I do not intend to waste my precious time responding to them. Speaking of precious time, let me bore you with another facile and specious argument.. Like many of us here, I occasionally receive bug reports from our users, and reply for more information, and get back some kind of challenge[1], or possibly a warning that my mail is being rejected because I am in a DUL (such as the osirusoft one). Since I consider my time just as precious as Adam's, I typically ignore all such challenges. I will leave the bug open for a while in case another user, who is willing to hold up his end of the implied BTS social contract and also sees the bug is able to respond to it. Eventually though I will have no choice but to close it. This is ok when the percentage of such bugs is low -- in the 1% area. If the percentage of such bugs becomes higher, say 10%, I belive that Debian will start to suffer from it. If we're unable to contact the submitters of 10% of our bugs, then a lot of bugs will go unfixed, and quality will drop. I'm already finding it much harder to get a response from users on bug reports than I did years ago. I don't think that TMDA is yet enough of a problem for this to be a big deal, but I think it has the potential to become one. Debian as a whole is empowered to override the wishes of one maintainer, if it turns out that the software he is packaging is detrimental to the distribution as a whole. We do not let maintainers package software in us/main that puts us at risk of copyright infringement, or certian patent infringements, or in the past, crypto that cannot be exported. If we find that TMDA has the potential to cause significant problems for the project, we can certianly decide that we will not promote it or distribute it, and we can warn our users not to use it in communication with the project. -- see shy jo [1] Which is fairly amusing, since I both gpg sign all my mail with a and use TLS for sending it. There's no shortage of identification here. pgpRzn1e779Cz.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 05:16:40PM +0200, Florian Weimer wrote: Most MTAs support rejecting unknown destinations at the SMTP level. They don't generate bounce messages in such cases. It's a pity if Postfix can't do this. So far, I assumed only qmail had this weird property. Postfix supports this perfectly well now (it used to not support this well at the SMTP level due to having a modular design much like qmail but that hasn't been the case for quite some time). -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
* Florian Weimer [EMAIL PROTECTED] [030827 19:08]: That's why it's better to get rid of generic MX secondaries (IOW secondaries which are not under you administrative control). The effect you describe hampers effective anti-spam measures, too. It can also help anti-spam measures. They are in my eyes a good solution for large universities together with a block for incomming smtp-messages except to one or two central machines beeing backup MX for anything. I don't know a better way to close open relays. For example, you might want to defer a message from a sender whose temporarily domain doesn't have any MX (or A) record. If you do this, significant numbers of messages will pile up in the queues of your secondary MXes, and their operators won't be happy about that. This is merely an argument againt badly configured backups or backups with operations getting sad to fast... Hochachtungsvoll, Bernhard R. Link -- They said: Smile and be happy, it could become worse. And I smiled and was happy. And it became worse.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
This one time, at band camp, Joey Hess said: I don't think that TMDA is yet enough of a problem for this to be a big deal, but I think it has the potential to become one. Debian as a whole is empowered to override the wishes of one maintainer, if it turns out that the software he is packaging is detrimental to the distribution as a whole. We do not let maintainers package software in us/main that puts us at risk of copyright infringement, or certian patent infringements, or in the past, crypto that cannot be exported. If we find that TMDA has the potential to cause significant problems for the project, we can certianly decide that we will not promote it or distribute it, and we can warn our users not to use it in communication with the project. Let me start by saying I absolutely hate C-R systems, and give up on communicating with people who use them. That being said, I think the argument you're making is a slippery slope, and is not something I'm entirely comfortable with. The project certainly can and should prohibit maintainers from uploading things that will cause problems for the project (crypto, copyright infringement, etc.), but that is a different case than this. Distributing TMDA doesn't infringe copyrights, and is not illegal, at least AFAIK. The fact that it is distasteful to me personally (and clearly, many others) is a sad thing, but not RC quality. Remember that we explicitly state in the Social Contract that we allow groups like the KKK to use our software for distasteful ends. I think that either a large warning on bugs.d.o about the use of C-R systems in corrspondence, or a similar warning in the description of TMDA would suffice. I am not familiar with TMDA, so I may be wrong, but couldn't it be shipped with a default of not issuing a C-R, and have a note in README.Debian about how to do enable it, with the caveat that using C-R for BTS correspondence will likely result in ignored bug reports and problems for the project? Just some thoughts, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpE67eWs0xH6.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: Adam McKenna wrote: The arguments are facile and specious, I do not intend to waste my precious time responding to them. That's a shame. I don't believe Karsten to be in the habit of putting forward specious arguments. Speaking of precious time, let me bore you with another facile and specious argument.. Like many of us here, I occasionally receive bug reports from our users, and reply for more information, and get back some kind of challenge[1], or possibly a warning that my mail is being rejected because I am in a DUL (such as the osirusoft one). Since I consider my time just as precious as Adam's, I typically ignore all such challenges. Some of those challenges arrive at [EMAIL PROTECTED] instead. AFAIK, we typically don't have enough time to respond to them what with all the other stuff we're doing, and on a matter of principle I think that people interacting with the Debian BTS should whitelist it; imagine if we had to respond to a challenge by hand for every maintainer and submitter who ever uses bugs.debian.org! Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: Adam McKenna wrote: The arguments are facile and specious, I do not intend to waste my precious time responding to them. Speaking of precious time, let me bore you with another facile and specious argument.. [snip] He's not listening, and he won't. The best thing may be to reassign the bug to the Technical Committee. -- G. Branden Robinson|There is no housing shortage in Debian GNU/Linux |Lincoln today -- just a rumor that [EMAIL PROTECTED] |is put about by people who have http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin pgpadg7ifrAbb.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 07:49:27PM +0100, Colin Watson wrote: On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: Adam McKenna wrote: The arguments are facile and specious, I do not intend to waste my precious time responding to them. That's a shame. I don't believe Karsten to be in the habit of putting forward specious arguments. Well, let's see, I'll try to be brief: #0, #1, #2 and #11 are basically opinion and rhetoric. Karsten has stated that he has a 'religious' objection to CR, and I'm not willing to have a debate about it. I've already noted some of the places that Karsten can go if he wants a debate. #3 blames CR for actions taken by an ISP (IOW, user configuration error). #4 claims that CR is less effective without giving any empirical data to back up that claim. #5 claims a high false positive rate without giving any empirical data to back up that claim. #6 singles out CR for a DOS attack that all autoresponders and vacation programs, as well as some MTA's are vulnerable to. In addition, the effect of such an attack would still identify the original sending machine through the headers of the quoted message, so it would basically be equivalent to mailbombing someone from your own machine. #7 does not apply to TMDA #8 does not really make any sense at all. It seems like he is saying that spammers might start to send out fake confirmation requests in order to harvest e-mail addresses. This seems far-fetched at best. #9 just sounds like a threat. #10 blames CR for user configuration errors (failing to set up a proper whitelist) --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 03:02:33PM -0400, Stephen Gran wrote: I think that either a large warning on bugs.d.o about the use of C-R systems in corrspondence, or a similar warning in the description of TMDA would suffice. I am not familiar with TMDA, so I may be wrong, but couldn't it be shipped with a default of not issuing a C-R, and have a note in README.Debian about how to do enable it, with the caveat that using C-R for BTS correspondence will likely result in ignored bug reports and problems for the project? Stephen, TMDA does not ship with any defaults, except a couple of customizable text files (templates). It is entirely up to the user to create a TMDA configuration along with his own whitelist and filter directives. TMDA is actually not just a C-R system. C-R is only part of the system. It is also has a very powerful and configurable mail filter, and it is also a Mail Delivery Agent. You can read about the features of TMDA at http://tmda.net/features.html I don't have a problem with adding documentation, in fact I had already planned on adding a note to README.Debian on the next release listing the addresses that the user should be sure to whitelist if he expects to be able to communicate with the BTS. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Stephen Gran dijo [Wed, Aug 27, 2003 at 03:02:33PM -0400]: The project certainly can and should prohibit maintainers from uploading things that will cause problems for the project (crypto, copyright infringement, etc.), but that is a different case than this. Distributing TMDA doesn't infringe copyrights, and is not illegal, at least AFAIK. The fact that it is distasteful to me personally (and clearly, many others) is a sad thing, but not RC quality. Remember that we explicitly state in the Social Contract that we allow groups like the KKK to use our software for distasteful ends. I completely agree - If a user is going to shoot himself in the foot, he can do it with TMDA or with any other package. I think that either a large warning on bugs.d.o about the use of C-R systems in corrspondence, or a similar warning in the description of TMDA would suffice. I am not familiar with TMDA, so I may be wrong, but couldn't it be shipped with a default of not issuing a C-R, and have a note in README.Debian about how to do enable it, with the caveat that using C-R for BTS correspondence will likely result in ignored bug reports and problems for the project? Description, with the possible addition of a note in README.Debian would be better - it is targetted at the user. Bugs are targetted to the maintainer, and most users will not be aware of them. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgphQ2E8JzhRw.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Colin Watson wrote: Some of those challenges arrive at [EMAIL PROTECTED] instead. I'm curious; how many would you say it gets per package on avarage, that have some real impact? (A TMDA response to a BTS ACK mail has little impact.) Perhaps my numbers were low, since I only counted the ones I occasionaly see. -- see shy jo pgptCU7i7BnNf.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
This one time, at band camp, Adam McKenna said: Stephen, TMDA does not ship with any defaults, except a couple of customizable text files (templates). It is entirely up to the user to create a TMDA configuration along with his own whitelist and filter directives. TMDA is actually not just a C-R system. C-R is only part of the system. It is also has a very powerful and configurable mail filter, and it is also a Mail Delivery Agent. You can read about the features of TMDA at http://tmda.net/features.html I don't have a problem with adding documentation, in fact I had already planned on adding a note to README.Debian on the next release listing the addresses that the user should be sure to whitelist if he expects to be able to communicate with the BTS. Well, if it ships essentially disabled, and has to be purposefully enabled to do any harmful behavior by the user, and there is documentation included that lets the user know about whitelisting and so forth, that takes care of all of my objections. I see no reason for this to be RC either, but that's just IMHO. Good luck with the debate, Steve (who still hates C-R systems :) -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpXDdMGtYMos.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, 27 Aug 2003, Adam McKenna wrote: TMDA does not ship with any defaults, except a couple of customizable text files (templates). It is entirely up to the user to create a TMDA configuration along with his own whitelist and filter directives. If possible, perhaps you could consider whitelisting common debian.org address by default? [Things like [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc.] That would at least avoid some of the annoying C-R's that come from TMDA on this list. [Probably wouldn't help the few other C-R systems that don't understand what X-Mailing-List: means, though.] Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in [EMAIL PROTECTED] http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgptqujdgVWht.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Wed, Aug 27, 2003 at 07:26:24PM -0400, Joey Hess wrote: Colin Watson wrote: Some of those challenges arrive at [EMAIL PROTECTED] instead. I'm curious; how many would you say it gets per package on avarage, that have some real impact? (A TMDA response to a BTS ACK mail has little impact.) Perhaps my numbers were low, since I only counted the ones I occasionaly see. Oh, a fraction of a percent at the moment, fortunately, although my perceptions are lower than reality since most of the challenges get caught by the filters we use to catch the bazillion bounces and mail delivery warnings that come our way, and end up in a rarely-read mailbox on master. The ones that are actually interesting would probably be challenges in response to your-bug-has-been-closed acknowledgements. -- Colin Watson [EMAIL PROTECTED]
