Hi All, Thanks for all who took the time to respond to my request. As I'm sure you know, my concern isn't really with the subscribers on this list (which are generally considerate, sophisticated users) but with the madness on some of our larger lists like suse-linux and suse-linux-e. Suddenly implementing filtering without any notice would probably result in threats on my life and posting an RFC is pretty much out of the question there. So if everything goes well with this test case I'm planning on implementing similar policies on those lists after a suitable warning. I received about 20 responses and all except two were, to put it mildly, extremely enthusiastic about the proposal. The two arguments that were against were, in my opinion, both valid and the second convinced me that a complete ban on attachments is, sadly enough, a little too heavy handed. Here's the policy as it currently stands: o mail that consists only of a MIME attachment gets bounced o HTML mail gets bounced o all attachments that aren't text/plain get stripped o other than the bounces in the first two cases, no notification is sent to the sender that their attachments have been removed I think that this is reasonable compromise that allows people to attach log snippets or gpg keys while keeping HTML and "vcards" out, but you comments are of course welcome. Thanks again for the input, I really appreciate it. -- -ckm
Here's the policy as it currently stands: o mail that consists only of a MIME attachment gets bounced o HTML mail gets bounced o all attachments that aren't text/plain get stripped o other than the bounces in the first two cases, no notification is sent to the sender that their attachments have been removed
Sounds good. Have you also considered implementing AV scanning so that people who are infected get notification? I find it very amusing to receive emails like "so and so tried to email you, but it was blocked cause they have a virus, they have also been notified" I noticed these picked up a LOT shortly after sircam became popular (although today so far I've receieved upwards of 10 Sircam infected emails :P. One thing, Mutt with GnuPG signed email shows up as two attachments, make sure you don't block those or you might get some crypto people unhappy. One thing to consider for a total ban: ctrl-R in pine, cut and paste, etc. You can put stuff into the email message. It shouldn't be so long that it needs compression or causes problems. The main argument against is imap users can get headers/message bodies/attachments seperately, so for people on dialup with imap it sort of sucks.
I think that this is reasonable compromise that allows people to attach log snippets or gpg keys while keeping HTML and "vcards" out, but you comments are of course welcome.
Amen.
Thanks again for the input, I really appreciate it.
-ckm
-Kurt
Hi Kurt, @ 8:12:59 PM on 11/1/2001, Kurt Seifried wrote: KS> Sounds good. Have you also considered implementing AV scanning so KS> that people who are infected get notification? I find it very KS> amusing to receive emails like "so and so tried to email you, but KS> it was blocked cause they have a virus, they have also been KS> notified" I noticed these picked up a LOT shortly after sircam KS> became popular (although today so far I've receieved upwards of 10 KS> Sircam infected emails :P. OTOH, I've also gotten mail from someone's scanner after I've posted to this list. And I haven't been infected with any virus/worm (ever) -- text/plain without any attachments. I guess someone's regexp engine is seriously lax or something -- or maybe vise versa. I didn't keep the mail or the headers, but I remember the notification came from some software developed by http://www.antivir.de and the message contained something like "A malicious mail was received from you!" -Brian
* Brian Clark (brianj@fusionwerks.com) [011101 18:38]:
OTOH, I've also gotten mail from someone's scanner after I've posted to this list. And I haven't been infected with any virus/worm (ever)
:) We occasionally get email from people who have "discovered" a virus in a file from ftp.suse.com. -- -ckm
Some clarification. gpg/pgp attached signatures will, of course, still get through. At least the kind that mutt creates, which is the only kind I tested. If other mail clients to something other than the applica/pgp-signat type let me know and I'll make sure they work. -- -ckm
On Thu, Nov 01, 2001 at 16:58 -0800, Christopher Mahmood wrote:
Here's the policy as it currently stands: o mail that consists only of a MIME attachment gets bounced
[ separated for optical grouping only ]
o HTML mail gets bounced o all attachments that aren't text/plain get stripped
Whom are you trying to protect here (or some other place on SuSE lists)? I take it "HTML mail" are the "text/html" and "multipart/alternative" thingies. But ISTR that a "text/plain" mark is taken by MS browsers as an invitation to the usual "maybe I know better and it actually _is_ HTML?" attitude. So HTML is easily pushed through this filter by simply classifying it as text/plain. Is this a problem? (Sorry, I'm not sure about what you are heading for -- security or less annoyance.) As to the valid (reasonable?) attachment types: What about C code and patches, *zip'ed or tar'ed archives, and the like which usually carry some "application/x-c", "application/x-gzip" or some such type (this is from memory, names might be different but the situation is always the same: neither can you enumerate the good nor the "bad" ones without forgetting a few hundred ...).
o other than the bounces in the first two cases, no notification is sent to the sender that their attachments have been removed
But I feel (strongly) the mangled messages should be marked as such. IANAL. But what would you think if you post a message to a public list and have it published *unnoticed* in a scrambled way while it's still attributed to you? There's definitely a need for something along the lines of "X-Note: crippled by the list management software". Maybe the inserted text needs to be worded some other way but I feel that any kind of manipulation applied to articles contributed by others in principle is crippling them. Did I already mention that I don't like the unnecessary, useless and annoying "[listname]" insertion in the subject line? Just to make it clear. All of the above assumes that this kind of manipulation is of benefit. But I'm not too convinced of this. Yes, I'm annoyed by HTML messages and v-cards (which seem to be the most prominent failures you're trying to keep away from the list). But the same holds true for bad quoting ratios, TOFU (sorry, I lack a better "English" term), pages full of nonsense disclaimers ("this is an email ..."), sigs longer than the actual message, OT and FAQ postings etc. To cut it short: Most problems - actually the worst ones - aren't of technical nature and obviously cannot be solved by technical means but with a clue bat only. :( Sometimes I wish list maintainers would ban articles coming from certain mail frontends (those which cannot even be configured correctly since they are broken by design; Lotus, the thankfully dying X-400 ones, and MS' "mail programs" come to mind) plus those which show a fine example of bad attitude towards other people's time and resources (yes, even with capable and conforming mail frontends ignorant users are able to send out crappy messages which are a burdon for the receiver). This way subscribing to some lists could become bearable and of benefit, again, instead of just wasting one's time. :) I fear that the kind of filter you talk about could easily turn out to be more of a problem than being a (real) solution. At least I have a hard time seeing all the benefits I should cheer about joyfully ... Undoubtedly it takes a *huge* amout of consideration and careful testing before being implemented on lists by default. But you're already aware of this. :) If you are searching for ways to improve the lists' appearance to their subscribers I would suggest - removing the Subject mangling - clearly (and in public) stating that you will _never_ consider Reply-To munging - _immediately_ removing subscribers with bouncing messages, "test" postings and misconfigured autoresponders (any bulk that goes to a list is braindead) and I already like very much that only subscribers can post to the list (at least in those lists I'm subscribed to). Regarding the virus scanning others mentioned I'm sure no list owner would happily spend the cpu cycles necessary to do this. Even more in the case of the (so called only?) SuSE lists -- since they are by no means an official SuSE service IIUC but merely pure kindness on SuSE's side to host these on their servers. A fact some posters sometimes seem to forget together with the fact that no list reader gets paid for participating (neither for reading nor for helping others). Anyway do I feel that virus scanning should be done as close as possible at the sender's and receiver's sides as possible (just like anti spoofing measures). There's no point in shoving all the nonsense over a network passing many hops just to drop it on the other terminal point. After a little thinking it's obvious that it would have been best to not issue this stuff at all or at least not having it pass the very first hop. So it's good habit to not annoy others with virii and it's just sane to not accept virii from others. :> virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
I was pretty explicit about not sending responses to the list, but oh well... * Gerhard Sittig (Gerhard.Sittig@gmx.net) [011102 13:13]:
Whom are you trying to protect here (or some other place on SuSE lists)? I take it "HTML mail" are the "text/html" and "multipart/alternative" thingies.
Personally, I really don't care if someone's Windows machine gets a virus and my concerns, in order, are 1) decreasing the amount of unnecessary list traffic we have 2) decreasing the annoyance of the overuse of attachments and HTML mail 3) avoiding viruses being pread through our lists (which has only happened once that I can recall)
But ISTR that a "text/plain" mark is taken by MS browsers as an invitation to the usual "maybe I know better and it actually _is_ HTML?" attitude. So HTML is easily pushed through this filter by simply classifying it as text/plain. Is this a problem?
It's not a problem for me, but it probably is for the sender since I can't imagine many people are willing to take the time to pipe the mail into lynx or html2text or whatever to read.
As to the valid (reasonable?) attachment types: What about C code and patches,
That's text.
*zip'ed or tar'ed archives, and the like which usually carry some "application/x-c", "application/x-gzip" or some such type (this is from memory, names might be different but the situation is always the same: neither can you enumerate the good nor the "bad" ones without forgetting a few hundred ...).
No, gzip and tar archives would be stripped. If your patch (which are rare on most of our lists) is so large as to require compression to get in under 50K(!) message size limit that we've been using for quite some time, even the most ardent supporter of the trend that has developed over the last few years of using SMTP as poor man's file transfer protocol would suggest that you probably should find some other way to tell the list about it. But you are correct, if someone *really* can only express themself in HTML then they can inline it and it will get through.
But I feel (strongly) the mangled messages should be marked as such.
It's clearly stated in both the welcome message they will receive and the FAQ.
IANAL. But what would you think if you post a message to a public list and have it published *unnoticed* in a scrambled way while it's still attributed to you?
I'd be pissed, but that's not really what's happening.
There's definitely a need for something along the lines of "X-Note: crippled by the list management software".
Fair enough, I'll insert an X-header that says something to that effect.
Did I already mention that I don't like the unnecessary, useless and annoying "[listname]" insertion in the subject line?
Probably not since I thought we were discussing attachment filtering, but add something like the following to your procmailrc: :0 hwf * ^Subject.*\[suse-security\] | sed 's/\[suse-security\]//' $MBOX_WHERE_I_KEEP_SUSE-SECURITY if it really bothers you.
To cut it short: Most problems - actually the worst ones - aren't of technical nature and obviously cannot be solved by technical means but with a clue bat only. :(
No one is trying to legislate common sense here and I don't have the time or the personality to enforce a set of policies that we don't really don't have anyway.
I fear that the kind of filter you talk about could easily turn out to be more of a problem than being a (real) solution.
Then we'll remove it.
At least I have a hard time seeing all the benefits I should cheer about joyfully ...
I never asked for cheering, I just wanted some feedback from a list who's opinions I respect. I got that and now I'm slowly acting on it.
Undoubtedly it takes a *huge* amout of consideration and careful testing before being implemented on lists by default. But you're already aware of this. :)
Hence the careful testing, request for comments, careful log watching during dinner, etc.
If you are searching for ways to improve the lists' appearance to their subscribers I would suggest - removing the Subject mangling
Done. See procmail example above.
- clearly (and in public) stating that you will _never_ consider Reply-To munging
Done several times on SLE (the last time resulted various threats on my physical well-being and misc. insults...no joke) and in the FAQs. We don't use reply-to's on any of our lists and never will...don't worry, I'm a True Believer.
- _immediately_ removing subscribers with bouncing messages,
We do it as quickly as we can.
"test" postings and misconfigured autoresponders (any bulk that goes to a list is braindead)
Personally, I leave "testers" alone since others usually flame them. We try to to get autoresponders as quickly as we can and ezmlm is very good at catching most of them.
and I already like very much that only subscribers can post to the list (at least in those lists I'm subscribed to).
All of our lists are closed. -- -ckm
Hi,
I was pretty explicit about not sending responses to the list, but oh well...
:-) As one who was hit by the problem which started all this, may I put this debate into perspective. Abhorrent as they are, the basic problem was not HTML or vcards etc. For me, the problem went as follows:- 1 My ISP implemented content filtering - albeit severely broken 2 A unknown number of mails heading to me from the SuSE list were bounced back to SuSE. 3 ezmlm mailed me a probe After investigating I found the original mail had a structure which looked to be an inline attachment of a .bat file to Outlook Distress. The ezmlm also contained this same structure but luckily my ISP's content filter failed to pick this up. If it had picked it up, ezmlm would have received a bounce and I would have been removed from the SuSE list. Effectively by not implementing a policy like the one proposed, SuSE would be allowing the mailing list to be exploited in a DoS attack. The DoS is twofold. First it has the potential to cut users off but it also increases the traffic/load on the SuSE servers. I predict more ISPs will implement content filtering to "protect the masses" so the problem is only likely to get worse. Personally, I think the policy ought to be the other way around and it shouldn't be too difficult to implement. Just as in good firewall design, you deny everything then just allow what you want. In this case there are arguments for pgp signing and maybe tar variants. For what its worth, I don't think attachments are appropriate for a mailing list in the same way as they are frowned on in newsnet. As another protection mechanism, maybe the bot should not repeat a bounced message but simply list the message number(s). John
Just to put it all in perspective: I just posted to NTBugtraq, so far 68 out of office replies. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd wish that every (ISP) mail administrator would have applied this filtering, life would be so much nicer :) Yours sincerely, Michelangelo van Dam - -- Devoted is he, who configures sendmail without the book (unknown) -- On Thu, 1 Nov 2001, Christopher Mahmood wrote:
Hi All,
Thanks for all who took the time to respond to my request. As I'm sure you know, my concern isn't really with the subscribers on this list (which are generally considerate, sophisticated users) but with the madness on some of our larger lists like suse-linux and suse-linux-e. Suddenly implementing filtering without any notice would probably result in threats on my life and posting an RFC is pretty much out of the question there. So if everything goes well with this test case I'm planning on implementing similar policies on those lists after a suitable warning.
I received about 20 responses and all except two were, to put it mildly, extremely enthusiastic about the proposal. The two arguments that were against were, in my opinion, both valid and the second convinced me that a complete ban on attachments is, sadly enough, a little too heavy handed.
Here's the policy as it currently stands: o mail that consists only of a MIME attachment gets bounced o HTML mail gets bounced o all attachments that aren't text/plain get stripped o other than the bounces in the first two cases, no notification is sent to the sender that their attachments have been removed
I think that this is reasonable compromise that allows people to attach log snippets or gpg keys while keeping HTML and "vcards" out, but you comments are of course welcome.
Thanks again for the input, I really appreciate it.
--
-ckm
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE75A+UcExHpthAaugRAkaJAKDMxpf1GZARrYMvdrrBxNwairIjkwCdH8ZW Y6uSmFby61+zQSBe1u4h2uE= =i6bx -----END PGP SIGNATURE-----
participants (6)
-
Brian Clark -
Christopher Mahmood -
Gerhard Sittig -
John Trickey -
Kurt Seifried -
Michelangelo van Dam