Nog grotere vraag is waarom deze medewerker in staat is deze fout te maken. De mail omgeving is blijkbaar slecht ingericht, waardoor dit soort fouten gewoon kan worden uitgevoerd. Waarom heeft de Rabobank dat niet beter voor elkaar. Ik bespeur bij de Rabobank een trend om zoveel mogelijk het geld niet uit te geven aan service verhogende middelen. Dit is er weer een. Pinautomaten in de buitenlucht, nog zo een. Opheffen van bijna alle kantoren, want alle diensten kunnen toch wel via internet ? Het is dat de wet ons verplicht een lopende rekening te hebben om ons loon op te kunnen ontvangen. Anders nam ik per direct afscheid van de bankenwereld. Ik red me prima met contant geld......

Je vergeet alleen dat ze langzaam maar zeker het contant geld willen afschaffen. In de toekomst is contant geld alleen voor criminelen. Want dat kan de belastingdienst niet controleren.

Dit is een lokale actie. Als je je druk wil maken over banken doe het dan met:
Maturity level 5 voor de invulling IT-risico’s te controleren door de DNB. http://www.toezicht.dnb.nl/3/50-203304.jsp en http://www.toezicht.dnb.nl/binaries/50-230767.pdf. De controle op de invulling bestaat uit een papieren vinkenlijstje op te sturen aan de DNB.

Even kijken autos en snelheden. We doen alleen een papieren controle waarbij elke bestuurder zelf aangeeft of hij het goed doet. Wie stuurt zelf zijn bekeuring door en waarom dan toch al die snelheidscamera's?

Dit soort fouten worden aan de lopende band gemaakt bij allerlei bedrijven en instellingen. Omdat het dan geen landelijk bekende naam is, wordt er geen ruchtbaarheid aan wordt gegeven. Zolang medewerkers met een mailclient kunnen werken, kunnen dit soort fouten gemaakt worden.

Snelheidslimieten zijn grosso modo ingevoerd door Den Uil tijdens de zogenaamde oliecrisis. Daarna vond de pvda het wel leuk om ze te laten bestaan, want op dat moment was autorijden nog voorbehouden aan rechtse ballen. En als je die kunt pesten is het altijd goed. Daarna bedacht meneer Gatsonides de snelheidsmeting middels radar en vastlegging middels fotocamera, geautomatiseerd en was het hek van de dam. De roverheid zag kans schoon om de automobilist meer geld afhandig te maken. Met veiligheid hebben de snelheidslimieten hoegenaamd niets van doen gehad. Ik vind ze daarom heden ten dage grotendeels bull-shit.
MAAR :
1.) automobilisten zijn niet goed geschoold én niet goed onderlegd.
De meesten schijten al 7 kleuren bij 100 km per uur tegenwoordig.
2.) rijbewijzen zijn te gemakkelijk uitgedeeld, waardoor veel automobilisten wel een papiertje hebben, maar niet kunnen rijden
3.) de autodichtheid is tegenwoordig veel groter

1, 2 en 3 tezamen maken snelheidsbeperkingen overdag helaas gerechtvaardigd én nodig, tegenwoordig. Want door alle niets-ontziende, kortzichtige, egoïstische individuën op de weg, is de weg inherent onveilig geworden. En de roverheid mist de wil, het doorzettingsvermogen en het vermogen om er echt wat aan te doen.

De oplossingen zijn :
1.) strenger optreden tegen onveilig (verkeers)gedrag. Eerder het rijbewijs innemen.
2.) onbetamelijk gedrag richting agenten en medeweggebruikers : inname rijbewijs. Gij zult u ten allen tijde gedragen.
3.) bij- en herscholen van automobilisten
4.) om de 5 jaar bekwaamheidsexamens. Na 3 pogingen niet gehaald : rijbewijs inleveren en pas na rijlessen en geslaagd examen weer terug kunnen verdienen.
5.) alle personenwagens waar je na een koprol niet ongeschonden, ongedeerd en onbeschadigd uit kunt stappen van de weg halen. Per type voertuig te testen. Motorfietsen en vrachtwagens worden uitgezonderd. Aannemers busjes worden het uitvoerigst getest, die moeten ook na een botsproef goed zijn te verlaten.
6.) Fietsers en voetgangers worden niet meer automatisch onschuldig verklaard. Ook zij dienen de regels te respecteren en er zich aan te houden.

Na dit alles mogen de snelheden op autowegen weer naar onbeperkt, op dezelfde manier als in Duitsland : tot 140 geldt als normaal. Boven 140 een ongeluk, draag je (progressief oplopend met de snelheid) eigen risico als je schuldig bent aan schade.

Banken zijn tegenwoordig een wettelijk noodzakelijk kwaad geworden. Je kunt er goed zonder, maar moet ermee van de wet/regering, onder het motto : hoe houden we het volk arm en in bedwang.

De fouten worden niet gemaakt als de centrale mailinstellingen goed worden geregeld, zodat niet zomaar iedereen mail to all of mail to many kan doen. En dat ís écht goed te regelen. Maar is blijkbaar niet gedaan...... met gevolg.

Je hebt de kern van de eerdere links niet opgepakt. De controles hoe een en ander afghandeld wordt binnen een bank zijn een wassen neus, net zoals de verantwoordelijk dragen bij onverantwoord gedrag.

Dat een medewerker een fout kan maken als hij zijn werk doet, dat kan gebeuren. Fouten kun je alleen voorkomen door het werken onmogelijk te maken. Met een mailinglist-naam stopt de mail-server de rest er bij.
Zo'n foute cut/paste actie had ook de mailserver down kunnen halen (LHM).

Okay, de 'domme' Rabo klanten niet, maar die virussen die ze hebben zijn dol op E-mail adressen.

Zo had ik laatst ineens spam op mijn Cisco accounts (CCIE, CCW en Meraki) ineens kilo's spam.
Niet Cisco was gehacked, maar een medewerker van Meraki (Cisco) had zijn laptop laten besmetten en alle E-mail adressen op die laptop werden meteen geharvest.

All it takes is 1 of those 900 to get infected........

Kent er iemand een mailomgeving waarin je het aantal CC ontvangers kunt beperken en de limiet van BCC wel groter is?
Ik ken wel mailservers die het aantal RCPT TO items in een mail job beperken, maar dat treft dan zowel CC als BCC.
Bovendien werken de gebruikelijke mailclients hier omheen door zodra ze die melding terug krijgen de job te splitsen
in meerdere jobs met een kleiner aantal ontvangers (zonder dat de gebruiker hier wat van ziet).

Die imaginaire mailomgeving die ik niet ken die zou dus de CC header van de mail moeten inspecteren en actie ondernemen
als die te groot is. Komt dat voor? Ik ken dit wel als een heuristic bij spamfiltering (vele ontvangers -> enige spampunten),
maar niet als beperking van uitgaande mail. Wie wel?

Mijn werkgever heeft ook een keer zoiets gedaan. Wist ik meteen wie er nog meer waren aangenomen, was er niet zo blij mee. Ik ga er maar vanuit dat geen een van mijn nieuwe collega's tijd teveel had om te kijken of ik facebook, linkedin etc heb. Gelukkig woon ik niet Limburg want dat adres wat ze van mij hebben wil ik graag spam vrij houden en geef ik dus alleen aan bedrijven zoals rabobank, de tandarts etc.

Banken moeten uitsluitend communiceren via de veilige bankieren-omgeving of via post. Verder niet. E-mail is niet veilig en de rest al helemaal niet.

Het betrof een lokaal evenenment zo iets als klant promotie/binding, het ging niet om de directe bankzaken.

Dat is de houding die je van de echte security specialist verwacht. (++++)

Bestaat het nu niet, dan is het iets om aan te kaarten om als nieuwe gewenste functie er bij te laten komen.

Wat weet ik:
- een mailing list is op te zetten aan de server kant, maar niet of het dan alleen aan de CC te koppelen is.
- De grotere organisaties zullen een exchange (MS) dan wel Lotus (IBM) gebruiken. Deze bieden de meeste fucntionaliteit.
- het lijkt wel mogelijk te zijn om bcc mails te achterhalen (achteraf) van distribution groups. De woorden hiervoor zijn her en der anders.

MS https://technet.microsoft.com/en-us/library/dn770225(v=exchg.150).aspx via de Messaging policy and compliance https://technet.microsoft.com/en-us/library/aa998599(v=exchg.150).aspx the transportation group contains a lot (all is configurable) at [url https://technet.microsoft.com/en-us/library/jj919235(v=exchg.150).aspx [/url Transport rule conditions (predicates) is een note over distribution groups.

IBM http://www-01.ibm.com/support/knowledgecenter/SSKTMJ_8.5.3/com.ibm.help.domino.admin85.doc/H_FILTERING_OUT_UNWANTED_EMAIL_OVER.html. Het maken van de rules is helaas niet verder uitgewerkt. Als conditie mis ik helaas lengte.

- Je kunt dat verder doorlopen. Bestanden met bepaalde extensies zijn uit te sluiten. (tegenwoordig standaard setup actie).

Dit is voor alle normale interne bedrijfszaken. Gezien de hoeveelheid rompslomp die dat met zich meebrengt moet je re rekening mee houden dat mensen andere wegen gaan bewandelen als ze er niet goed mee kunnen werken, Ze moeten wat. Een niet werkend systeem kan wel heel veilig (secure) zijn maar is nutteloos.

een gewone bankmedewerker had al lang error 542 543 moeten krijgen.
too many recipients.
er is geen reden om 900 klanten in 1 keer te mailen.

Zeepkist ....

Iets wat voor Postfix werkt (en dacht ik al achterhaald is door iets wat handiger werkt, maar ik ben daar nooit ingedoken), waar serieuze spam- en malwarefilters mee zijn opgezet, waar in principe élke filterwens mee geïmplementeerd kan worden, en waar ik zelf wel eens een eenvoudig filter voor gemaakt heb is het volgende:
• Je filter draait in een apart proces, dat zowel als SMTP-server als -client fungeert.
• Postfix is geconfigureerd om alle op de standaard SMTP-poort binnenkomende e-mail niet de normale verwerking in te laten gaan maar via SMTP aan het filterproces door te geven.
• Het filter doet zijn werk, en kan een e-mail weigeren, accepteren, en eventueel ook aanpassen (voor de duidelijkheid: een Received-header toevoegen is al een aanpassing).
• Als het filter een e-mail accepteert dan legt het via een alternatieve poort verbinding met Postfix en levert daar de (al dan niet aangepaste) e-mail aan. Postfix is geconfigureerd om mail die op deze poort binnenkomt wél de normale verwerking in te laten gaan.
• Belangrijk detail: pas als Postfix de ontvangst van de gefilterde e-mail heeft bevestigd bevestigt het filter op zijn beurt de ontvangst van het origineel aan Postfix over de nog openstaande originele verbinding. Hierdoor kan het filter volledig meeliften op alle maatregelen die Postfix neemt om geen e-mails kwijt te raken. Het filter hoeft niet zelf iets op te slaan bijvoorbeeld.

Ik heb jaren geleden zo'n filter gemaakt, met voor die server specifieke filterwensen (die op zich niet ingewikkelder waren dan wat jij nu wilt). Het is het eerste wat ik ooit in Python heb geschreven (op wat vingeroefeningen na) en het bleek kinderlijk eenvoudig te zijn (voor een ervaren programmeur dan), alles wat ik nodig had zat al in de standaard-library van Python, en het was zelfs zo recht voor zijn raap dat het domweg in een keer bleek te werken, iets wat maar zelden gebeurt. Als je een basis hebt die filters als functies kan aanroepen dan is een functie om bijvoorbeeld alle e-mails te weigeren die meer dan 5 externe e-mailadressen in de To- en Cc-headers heeft staan waarschijnlijk een kwestie van slechts een paar regels Python-code. Voor de duidelijkheid: alle bestemmingsadressen worden via het SMTP-protocol afgehandeld zonder onderscheid te maken tussen To, Cc en Bcc. De eerste twee zijn gewoon MIME-headers waarin adressen herhaald worden die ook in de SMTP-dialoog voorkomen, en SMTP bemoeit zich helemaal niet met die headers, voor SMTP is dat data die onderdeel uitmaakt van het bericht. Wat Bcc wordt genoemd is simpelweg het ontbreken van bestemmingsadressen in de To- en Cc-headers.

Natuurlijk kan de werkelijkheid een stuk weerbarstiger zijn dan ik het hier even luchtig opschrijf. Als je organisatie niet ingericht is op het zelf schrijven en onderhouden van software dan komt er schrikbarend veel meer bij kijken dan even wat in elkaar flansen. En als de mailserver grote volumes moet kunnen verwerken dan moet je rekening met schaalbaarheid houden. De opzet is op zich uitermate schaalbaar, het is gewoon een SMTP-server extra in de pijplijn, maar het filterproces moet natuurlijk de volumes ook aankunnen.

Het is ook iets wat in een mailsysteem met iedere SMTP-server die ik serieus zou willen nemen ingebouwd moet kunnen worden, SMTP-servers moeten tenslotte in staat zijn om e-mail direct naar een andere SMTP-server door te routeren, en aan die mogelijkheid van Postfix is dit opgehangen.

Ik reageer met deze beschrijving omdat je uit lijkt te gaan van mogelijkheden die een ander (leverancier) in een mailsysteem heeft ingebouwd. Daar is niets mis mee, maar zie niet over het hoofd dat dat soort software vaak ook generieke uitbreidingsmogelijkheden heeft waar gebruikers met voldoende kennis van zaken hun eigen wensen in kunnen implementeren.

Nee, de medewerker is te stupide om het verschil tussen Bcc en Cc voldoende te realiseren. Lijkt mij meer de oorzaak dan de (hier) irrelevant problemen van email (al ben ik het wel met je eens).
Als dat werkelijk al tegen de grenzen van de capaciteiten van je personeel aanzit, dan kun je misschien beter alle internet bankieren afschaffen. Of personeel upgraden. Of beter: misschien 'ns stoppen met zinlose nieuwsletters, en focussen op hetgeen waar een bank voor is.