Diversity Business Newsletter
Title: DiversityBusiness.com | Monthly Newsletter SEPTEMBER NEWSLETTER-2004 | BellSouth Corporation honored as National Corporation of the Year MIAMI, FL -- BellSouth Corporation is honored to be selected as National Corporation of the Year by the Florida Regional Minority Business Council. The presentation, at FRMBC's 29th Annual Awards Gala on Friday, Sept. 17, cited BellSouth for its leadership in providing business and developmental opportunities for minority-owned firms in South Florida. More.. OfficeMax (R) recently awarded scholarships to three of its minority and a women owned business ITASCA, Ill. -- OfficeMax (R) recently awarded scholarships to three of its minority - and women-owned catalog suppliers for the Minority Business Executive Program at Dartmouth College's Tuck School of Business. Morris Liao, vice president of marketing for Pointe Writing Company in Schaumburg, Ill.; Lewis Scott, president of Simon Marketing, Inc. in Elgin, Ill.; and Delilah Stevens, president of Hess Advanced Technology, Inc. in Dayton, Ohio, were selected as OfficeMax's 2004 scholarship recipients. More... Women Facts Women hold 13.6% of board seats at Fortune 500 companies. The number of seats held by women of color has increased from 2.5% in 1999 to 3% in 2003. Of the Fortune 500, 54 companies have 25% or more women directors in 2003. Women comprise 46.6% of the U.S. labor force, 50% of managerial and professional specialty positions. Source: Business Womens Network Sponsors America's Top Organizations for Multicultural Business Opportunities Top 50 Diversity Businesses Top 100 Diversity Businesses Top 500 Diversity Businesses Top 50 Small Businesses Top 500 Small Businesses Top 500 Woman Businesses
heise online: Top-20 der Sicherheitslücken
Diese Meldung aus dem heise Security-Newsticker wurde Ihnen von "[EMAIL PROTECTED]" gesandt. Wir weisen darauf hin, dass die Absenderangabe nicht verifiziert ist. Sollten Sie Zweifel an der Authentizität des Absenders haben, ignorieren Sie diese E-Mail bitte. 09.10.2004 00:07 Top-20 der Sicherheitslücken Das SANS[1] (SysAdmin, Audit, Network, Security) Institute hat seine neue Top-20 der Sicherheitslücken im Internet veröffentlicht, die wieder aus zwei Top-Ten-Listen besteht -- eine für Windows und eine für Unix/Linux. Beide Listen führen die am häufigsten ausgenutzten Schwachstellen in Diensten und Betriebssystemen auf und basieren auf Informationen vieler internationaler Sicherheitsexperten, CERTs und Regierungsbehörden. Unklar ist allerdings, wie die Reihenfolge der Einträge zustande kam -- dass Windows RAS-Dienste noch vor Web-Browsern rangiert, überrascht dann doch. Obwohl jährlich tausende von Sicherheitslöchern[2] entdeckt werden, konzentrieren sich Angreifer und Würmer respektive deren Programmierer auf einige wenige, gut dokumentierte Lücken, für die auch entsprechende Tools kursieren. Trotzdem meist Sicherheitsupdates für verwundbare Applikationen verfügbar sind, haben die Hacker bei der Suche nach ungepatchten Server dennoch großen Erfolg. Die Liste ist allgemeiner als früher[3] formuliert und fasst mehrere Produkte unter einem Dienst zusammen, statt einzelne Produktnamen zu nennen. So findet sich der Internet Information Server zusammen mit dem Apache in der Kategorie Webserver. Wo früher noch Sendmail[4] als eigene Sicherheitslücke galt, sind nun Sendmail, Postfix[5], Qmail[6] und andere im Dienst Mail Transport System vereint. Das ändert aber nichts daran, dass beispielsweise der IIS[7] immer noch zu den üblichen Verdächtigen bei gefährlichen Diensten auf Windows-Systemen zählt und auf dem ersten Platz liegt. Auch bei Unix rangiert ein alter bekannter auf Platz eins: Der Name-Server BIND[8]. Neu zur Windows-Liste hinzugekommen sind Dienste wie Instant Messaging[9], der LSASS-Dienst[10], über den auch der Wurm Sasser[11] eindringt sowie der RPC-Dienst[12], über den sich Lovsan[13] in Windows einschleicht. Auch hier überrascht, dass die Sasser- und Lovsan-Lücken hinter IIS platziert sind, immerhin war von Millionen geschädigter Anwender die Rede. Weggefallen sind dafür Windows Scripting Host und SNMP. Unter Unix ist das Concurrent Versions System[14] (CVS) der Shooting-Star, der es gleich auf Platz vier der Liste schafft. Auch Datenbank-Systeme[15] rücken stärker ins Visier der Angreifer, ebenso wie Schwachstellen im Kernel[16] selbst. Siehe dazu auch: The Twenty Most Critical Internet Security Vulnerabilities[17] von SANS Institute (dab[18]/c't) URL dieses Artikels: http://www.heise.de/security/news/meldung/51977 Links in diesem Artikel: [1] http://www.sans.org [2] http://www.heise.de/security/news/meldung/51340 [3] http://www.sans.org/top20/top20_oct03.php [4] http://www.heise.de/security/news/meldung/40380 [5] http://www.heise.de/security/news/meldung/39142 [6] http://www.heise.de/security/news/meldung/38600 [7] http://www.heise.de/security/news/meldung/51954 [8] http://www.heise.de/security/news/meldung/42452 [9] http://www.heise.de/security/news/meldung/51874 [10] http://www.heise.de/security/news/meldung/46943 [11] http://www.heise.de/security/news/meldung/47037 [12] http://www.heise.de/security/news/meldung/38638 [13] http://www.heise.de/security/news/meldung/39347 [14] http://www.heise.de/security/news/meldung/48097 [15] http://www.heise.de/security/news/meldung/40297 [16] http://www.heise.de/security/news/meldung/43341 [17] http://www.sans.org/top20/ [18] mailto:[EMAIL PROTECTED] Copyright 2004 Heise Zeitschriften Verlag FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Joachim Merkel <[EMAIL PROTECTED]> wrote on 08.10.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >>> IMHO nicht, aber abschaltbar sollte es schon sein, wenn man >>> befürchtet bei externem Einsatz verschiedene MIDs zu bekommen. >> Wieso "befürchtet"? Man will doch verschiedene (aka eindeutige) >> MIDs. 0 Befürchten würde ich eher das Gegenteil (= immer dieselbe >> MID). Wo kommt denn die "0" vor dem "Befürchten" her? > Wenn derselbe Puffer zweimal durch den UUZ geschickt wird, entstehen > für dieselbe Nachricht unterschiedliche MID:. Wie das? Bei RFC=>ZC bekommt sie eine MID verpaßt (wenn sie fehlt), und bei ZC=>RFC behält sie diese MID bei. Nix anderes -- nur mit wesentlich kaputterer MID -- passiert, wenn jemand seine Puffer routinemäßig durch ZPR laufen läßt. > Das ist der einzige Grund, wo ich mir vorstellen kann, das es > unerwünscht ist. Da wäre JHA mal an der Reihe, was zu sagen, denn der wäre von allen Anwesenden wohl einer der Betroffenen. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >> IMHO nicht, aber abschaltbar sollte es schon sein, wenn man >> befürchtet bei externem Einsatz verschiedene MIDs zu bekommen. > Wieso "befürchtet"? Man will doch verschiedene (aka eindeutige) > MIDs. 0 Befürchten würde ich eher das Gegenteil (= immer dieselbe > MID). Wenn derselbe Puffer zweimal durch den UUZ geschickt wird, entstehen für dieselbe Nachricht unterschiedliche MID:. Das ist der einzige Grund, wo ich mir vorstellen kann, das es unerwünscht ist. -- Salut _)oachim FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Jörg Tewes <[EMAIL PROTECTED]> wrote on 08.10.04: > Donnerstag, 07.10.04 Michael Heydekamp schrub... >> Eben, und die kennt er i.d.R. nicht und müßte raten. Außerdem hat >> die MsgID einer eingehenden Nachricht meist eher wenig mit dem FQDN >> des Empfängers (sondern mehr mit dem FQDN des Erstellers, in diesem >> Fall UUZ) zu tun. ;) > Heißt das der UUZ soll auch bei eingehenden Mails eine Message ID > erzeugen? Erstens sprechen wir sowieso *nur* über eingehende Mails, und zweitens wieso "auch"? Bei ausgehenden erzeugt der UUZ doch gar keine, er übernimmt nur die vorhandene 1:1. > Wäre ungünstig weil ich danach Spam filtern lasse. Ist das wirklich so schwer? Wenn man auf eine leere MID filtern kann, kann man auch auf eine MID filtern, die ein bestimmtes, vordefiniertes und immer gleichbleibendes Muster erfüllt. Siehe auch <[EMAIL PROTECTED]>. Ich würd' dann schon gerne mal "echte" Argumente hören, sofern vorhanden. Und wenn Thomas mir damals keinen Unsinn erzählt hat, dann kannst Du mit UKAW sowieso nie Mails ohne MsgID erhalten, weil schon UKAW die setzt, wenn sie nicht vorhanden ist. Sonst kann man sie auch schlecht vom Server löschen... Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 08.10.04: > Michael Heydekamp ([EMAIL PROTECTED]) wrote: >> Es gibt ja auch keinen Schalter "-nukeMID" oder so zum Eliminieren >> bereits existierender MsgIDs. Wer will, kann ja immer noch mit >> XPFILTER alle MIDs, die auf das Muster passen, löschen. > Bei ausgehenden Mails nicht. Was (geht) "bei ausgehenden Mails nicht"? Die MID löschen? Weil? Aber egal, um ausgehende Mails geht's ja auch gar nicht. Da braucht der UUZ ja in Sachen MID nix zu erzeugen. Es geht nur um RFC=>ZC. > Bei eingehenden Mails kann das nicht Vorhandensein einer MID ein > signifikantes Merkmal für Spam sein. Wenn das so ist, wäre dann eben zukünftig [EMAIL PROTECTED] ein genauso eindeutiges und geeignetes Merkmal. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Donnerstag, 07.10.04 Michael Heydekamp schrub... Hi! > Johann H. Addicks <[EMAIL PROTECTED]> wrote on 07.10.04: >>> spricht irgendwas dagegen, den UUZ bei fehlenden MsgIDs in Mails >>> (nicht in News!) eine eigene und eindeutige MsgID á la >>> [EMAIL PROTECTED] >>> erzeugen zu lassen? >> alternativ könnstest Du auch die eigene fqdn von XP nehmen... nur >> dann müsste der UUZ versuchen, die passenden .bfg zu finden. > Eben, und die kennt er i.d.R. nicht und müßte raten. Außerdem hat > die MsgID einer eingehenden Nachricht meist eher wenig mit dem FQDN > des Empfängers (sondern mehr mit dem FQDN des Erstellers, in diesem > Fall UUZ) zu tun. ;) Heißt das der UUZ soll auch bei eingehenden Mails eine Message ID erzeugen? Wäre ungünstig weil ich danach Spam filtern lasse. Und Tschüss Jörg -- "I'll say a prayer for him tonight." "He's agnostic." "Then I'll say half a prayer." (Ivanova, Dr. Franklin und Garibaldi, "Points of Departure") FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Michael Heydekamp ([EMAIL PROTECTED]) wrote: > Es gibt ja auch keinen Schalter "-nukeMID" oder so zum Eliminieren > bereits existierender MsgIDs. Wer will, kann ja immer noch mit > XPFILTER alle MIDs, die auf das Muster passen, löschen. Bei ausgehenden Mails nicht. Bei eingehenden Mails kann das nicht Vorhandensein einer MID ein signifikantes Merkmal für Spam sein. Gruss Hans-Juergen FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Martin Wodrich <[EMAIL PROTECTED]> wrote on 08.10.04: > Michael Heydekamp <[EMAIL PROTECTED]> schrieb am 07.10.04 um 19:00: >> spricht irgendwas dagegen, den UUZ bei fehlenden MsgIDs in Mails >> (nicht in News!) eine eigene und eindeutige MsgID á la >> [EMAIL PROTECTED] >> erzeugen zu lassen? > Nein, da spricht nicht dagegen. [...] > Wichtig ist nur: > Es darf bei allen diesen ID-Ergänzereien niemals eine > gültige E-Mail-Adresse bei rauskommen. Genau. Aber freexp.de ist ohnehin keine so gute Idee (wir müßten bzw. sollten dann "uuz" als blackhole einrichten), daher ändere ich den Vorschlag ab in: [EMAIL PROTECTED] Das ist garantiert nie eine gültige Adresse und dennoch eine RFC-konforme MsgID (siehe RFC2606) und kann XP-intern keine Probleme machen. >> Der ZPR macht ja was ähnliches, wenn er eine Mail (und sogar ein >> Posting!) vorfindet, das keine MsgID hat. Allerdings halte ich die >> für ziemlich unbrauchbar, weil immer dieselbe und damit uneindeutig: >> --8<-- >>> MID: [EMAIL PROTECTED] >> --8<-- >> Außerdem ist "Z.P.R" kein gültiger FQDN. ;) > Das wäre sinnvoll in > [EMAIL PROTECTED] > zu ändern. Beim ZPR ist das Problem, daß er Nachrichten aller Netztypen bearbeitet und daher ggf. die netztypspezifischen Konventionen zu beachten wären, wenn man ihn eindeutige MIDs erzeugen lassen wollte. Der UUZ braucht sich nur um RFC zu kümmern. > Ansonsten wirds unter Umständen ungemüdlich beim Reorg. > Oder wo sonst die MSG-ID benötigt wird. Soweit hatte ich noch gar nicht gedacht. Wobei es beim Reorg AFAIK noch nach anderen Kriterien geht (INT_NR der Nachricht?), aber ein Dupekill könnte durchaus zu unerwünschten Ergebnissen führen, wenn man bei fehlender MID immer dieselbe erzeugen würde. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Fehlende MesIDs
Joachim Merkel <[EMAIL PROTECTED]> wrote on 08.10.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >> spricht irgendwas dagegen, den UUZ bei fehlenden MsgIDs in Mails >> (nicht in News!) eine eigene und eindeutige MsgID á la >> [EMAIL PROTECTED] >> erzeugen zu lassen? > IMHO nicht, aber abschaltbar sollte es schon sein, wenn man > befürchtet bei externem Einsatz verschiedene MIDs zu bekommen. Wieso "befürchtet"? Man will doch verschiedene (aka eindeutige) MIDs. Befürchten würde ich eher das Gegenteil (= immer dieselbe MID). Ich würde eher dafür plädieren, daß man feststellt, was sinnvoll und richtig ist, und das dann macht. Ich wüßte gerade in dem Fall nicht, warum man es abschalten können sollte. Es gibt ja auch keinen Schalter "-nukeMID" oder so zum Eliminieren bereits existierender MsgIDs. Wer will, kann ja immer noch mit XPFILTER alle MIDs, die auf das Muster passen, löschen. > Das Gate DUUCP hier erzeugt auch eigene MIDs, wenn es Mails > ohne MID aus dem RFC-Raum nach ZConnect konvertiert: > "MID: [EMAIL PROTECTED]" Ah, interessant. Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
