Door Anoniem: Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?
Echt niet ingewikkelder dan spam- en malwarefilters.
Een mogelijkheid die ik ooit bij Postfix heb toegepast was om Postfix te configureren alle inkomende e-mail via SMTP door te sluizen naar een filter-daemon, die zijn ding doet en een e-mail op een alternatieve poort weer teruggeeft aan de Postfix-daemon, die vervolgens doorgaat met het bezorgen van de e-mail. Die opzet was geen eigen bedenksel, die werd gewoon in de documentatie van Postfix beschreven.
Die filter-daemon is verrassend simpel. Die ontvangt zoals gezegd een e-mail over SMTP, maar laat als de complete e-mail binnen is nog even na in de SMTP-dialoog de goede ontvangst te bevestigen. Eerst doet hij zijn controles, aanpassingen, wat de filtertaak ook inhoudt, en als de e-mail doorgaat levert hij hem als SMTP-client via de alternatieve poort terug aan Postfix. Die eindigt de interactie met een goed- of foutmelding. De SMTP-dialoog waarmee de e-mail werd aangeleverd aan het filterproces staat nog open, en pas wanneer het teruggeven aan Postfix goed is gegaan meldt die dat de ontvangst goed is gegaan. Als je dat goed doet dan hoeft de filter-daemon verder geen maatregelen te nemen om zeker te stellen dat e-mails niet verloren gaan, die lift volledig mee op de robuuste faciliteiten van de eigenlijke SMTP-daemon en daarmee is de belangrijkste bron van complexiteit in het filterproces geëlimineerd.
In dit geval zoekt die simpelweg de To-header op, telt het aantal e-mailadressen daarin en als die over een ingestelde grens gaan wordt óf de e-mail niet terugbezorgd aan Postfix en een foutcode aan de aanleverende dialoog afgegeven, óf wordt simpelweg de To-header uit de e-mail geknipt waardoor het effectief een Bcc wordt, om hem daarna verder te verwerken zoals ik al beschreven heb. Ik zou voor de foutcode gaan, dat is lastiger voor de verzender maar die wordt wel scherp gehouden door met zijn fout geconfronteerd te worden, wat helpt de kans laag te houden dat die elders dezelfde fout maakt.
Dat vond ik al niet moeilijk, er zijn libraries beschikbaar waarmee zowel de SMTP-server als -client een fluitje van een cent zijn om op te zetten. Daarbij moet ik wel moet aantekenen dat het niet om hoge volumes ging en ik niet met schaalbaarheidsproblemen geconfronteerd werd. Bedenk wel dat dit een aanzienlijk lichtere controle is dan een spam- of malwarescan, dus de schaalbaarheidsproblemen zullen eerder op andere plaatsen optreden dan bij deze bewerking. Postfix heeft meen ik tegenwoordig een andere manier toegevoegd om dit soort dingen te doen die (nog) eenvoudiger is. Hoe het met andere SMTP-servers gaat weet ik niet, maar als dit overdreven moeilijk is dan kan je je afvragen of je met de juiste SMTP-server werkt. Maar je kan sowieso elke SMTP-server configureren om alle uitgaande e-mail bij een andere server af te leveren, en zo kan je het beschreven proces altijd tussen twee "echte" SMTP-servers inhangen.
Ik vind overigens dat dit soort constructies niet eens nodig zouden moeten zijn. To gebruiken in plaats van Bcc is een vergissing die zo makkelijk en zo vaak gemaakt wordt dat ik eigenlijk vind dat in elke e-mailserver én elke e-mailclient het maximum toegestane aantal e-mailadressen geconfigureerd moet kunnen worden. Misschien zijn er produkten waarbij dat ook kan, dat overzie ik niet (ik ben nu ook niet meer met dat soort dingen bezig). Als je ermee te maken hebt en die mogelijkheid niet beschikbaar hebt wordt het misschien tijd om een feature-request bij je leverancier in te dienen.