Aanand Shekhar Roy writes: > Suppose I have posted my confidential information on mailing list, > and the list setting is neither "accept" nor "discard" any mails > having confidential information.
I think you really should give up on this idea as stated. This function really should be implemented in the user agent, as a plug-in with a large dictionary of user-contributed criteria, as Spamassassin does for spam. Such a plug-in could also be used in the enterprise in the MTA. But a list knows too little about "confidential", it knows too little about individual concerns for privacy, to do a good job. The only thing going for a list is that lists often are relatively public and so relatively high potential for "leaks". But it's quite easy for an MUA to figure out which destinations are lists (most lists nowadays sport RFC 2369 header fields), so that takes care of the list. The MUA also can be intelligent about things like corporate contact addresses in the automatically added footer. More important, the author of the mail controls the rules (see disadvantage 2.d below). What to do instead: You can generalize to allow Mailman to filter on regular expressions in the body (this should be easy to do simply, but watch out for MIME structure and very large messages). That has been requested in the past. I believe the reason we don't do that already is that applications like Spamassassin and ClamAV do the job of filtering for malicious mail *much* better than we can (because they already have those libraries of criteria), and there aren't other good use cases. I'm not sure this is "big enough" to be a GSoC project (Mark or Barry would have better judgment), but it's much more likely to be useful and could be applied to your desired application. > So I had to ask which one approach is better? Both seem pretty bad to me. > 1.Including a command like "accept_confidential" at start of message or > subject. This has three disadvantages. a. Users are notoriously poor at using the commands, and not very good at spelling them correctly. b. If you reject the mail and *don't* provide the original text, the user has to reconstruct the mail from memory if they haven't saved it. (This may not be such a problem with modern MUAs, but the ones I use don't keep file copies of sent mail automatically.) c. If you reject the mail and *do* provide the original text, you are providing a spam vector. (Spammer sends mail *from* the victim's address and includes "confidential information" but deliberately omits the command.) > 2.Sending the mail, getting an auto-reply from reply-bot like " your mail > contains confidential info. reply with "confirm" ". This has four disadvantages. a. Most users are unlikely to care about the phone numbers etc in their mail. False positive rate will be high, and the "please confirm" spams similarly annoying. b. If you reject the mail and *don't* provide the original text, the user has to reconstruct the mail from memory if they haven't saved it. True, the list has the mail and will resend it, but the user needs to be able to figure out *why* the mail was held, and that may not be at all obvious without the original text. c. If you reject the mail and *do* provide the original text, you are providing a spam vector. (Spammer sends mail *from* the victim's address and includes "confidential information".) d. Since the author doesn't control the rule set, it may be *impossible* for her to construct a mail that will convey the desired information and still pass the filter. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
