Bij m'n vorige werkgever had ik maar een mailbox van 65 megabyte, en nu moet ik het zelfs zelf regelen: hoewel het een mooi adres is, heb ik zelf gekozen voor Google om m'n mail af te handelen.
En dat is dan ook gelijk wat ik jou aanbeveel:
Je @ziggo adres gebruiken is iets wat ik sowieso afraad, zeker omdat het net zoiets is om je website maar bij Ziggo in je privé space te hosten:
* Stel DAT je van provider wisselt... dag dag e-mail adres!
* Het staat gewoon niet professioneel
* De beperkingen
Naast dat ik onderschrijf dat Base64 encodering voor bestanden sowieso not-done is en ik je dus afraad om ook maar één niet-ascii teken met mail te versturen, is het gewoon een ramp om 20% van je mailbox aan één mailtje te moeten besteden. En geloof me: m'n vorige werkgever was een grote! Ik studeer er ook nog bij, en binnen het instituut waar ik studeer is de mailbox zelfs nog kleiner. Het zou best kunnen dat je "size exceeded" melding niet vanaf Ziggo kwam, maar juist vanaf de ontvanger. En dan heb je een probleem.
E-mail + bestanden is, in verband met spam filters, sowieso een probleem. Er zijn zat bedrijven die *.zip standaard wegfilteren, en zo nog wel meer extenties. Een link mailen is dus het beste.
Je steekt wel hoog van de wal met bandbreedte, maar bandbreedte is niet alles. Storage, efficiëncy, transfer, hosting, security: het zijn allemaal aspecten, en mail is gewoonweg NIET bedoeld waar je het voor gebruikt. Is het niet van jouw kant, dan is het wel van de kant van de ontvanger.
Wil je dit soort dingen doen, ga dan ergens anders de mail hosten. Gmail is zelfs al wat flexibeler. Ik gok dat, aangezien je het vanuit een bedrijf doet (waarom, als bedrijf, ga je sowieso van consumenten lijntjes gebruik maken? Misschien is dit een les voor je dat voor een duppie op de eerste rij zitten niet iets is waar je je bedrijfsprocessen aan wilt toevertrouwen), je toch een mooi @bedrijfsnaam.tld adres hebt, wat je laat forwarden. Verander die forward naar een g-mail of nog beter: ga goed hosten.
En ja, ik ben bekend met bepaalde bedrijfstakken met gekke gewoonten, in mijn geval zijn dat astronomen op dit moment. Absoluut gestoord die gasten: in dit specifieke geval probeerden ze een terabyte aan data uit chili over te pompen. Gelukkig waren zij wél slim genoeg om even rond te kijken of het op een andere manier dan in de e-mail kon. Elke industrie verandert. Als 640K niet meer genoeg is, dan bouw je 2*8gigabyte aan RAM extra in. Is e-mail én inefficiënt, en zijn je bestanden groot geworden? Switch naar andere hosting! Zoals elke industrie dat doet. Base64 heeft, afhankelijk van de inhoud van je file (erg onvoorspelbaar, want ascii gaat haast nooit iets aan verloren en veel fileformats zijn gedeeltelijk ascii), tot wel 30% overhead!
Conclusie: niet zeuren over bandbreedte, en "vechten" tegen het feit dat e-mail geen bestanden kan oversturen zoals je het wilt. Je kunt, zoals je nu doet, flabbergasted blijven doen en verbaasd blijven doen, of je er bij neerleggen dat het een feit is, zoals zoveel doen en je ook zeggen in dit topic, en tot een constructieven oplossing komen. En daar zijn er al ZAT van genoemd.
Vanwege de micro-mailboxes bijvoorbeeld (jaja, sent items telt mee), gebruikt zo'n beetje elke uni/hogeschool een dropbox of blackboard like systeem met personal workspaces waar files in geupload kunnen worden. Ideaal.
Heb je een bewijslast eis? Ga research doen! Newsflash: je bent niet de enige. Financiële instellingen bijvoorbeeld, of zorginstellingen die klanten met een PGB hebben. Stel dat die klant er weg wil, drukken ze dan op delete? Dat màg niet. Dus dat KAN niet. Gemiddeld ERP/CRM pakket stored files vrijwel permanent ook. En dat moet jij ook gaan doen.
Wat voor bedrijven als de jouwe zelfs idealer zou zijn is een systeem à la Microsoft Sharepoint: iteraties van documenten kun je zo zelfs bijhouden!
Van elke persoon en/of elke server krijg ik een ontvangstbevestiging.
Dus je stuurt nog uitvoerbare scripts mee ook met je e-mails? Als men dat in '78 wist, toen het huidige e-mail protocol ontworpen werd (in '78 gebruikten ze bij CERN voor grote bestanden, van 0,5 megabyte etc., gewoon sneakernet. In dit geval in de vorm van een bakfiets), dan had men het gedaan net zoals bij SMS: een 7-bit encodering om alleen de standaard ASCII tabel te kunnen ondersteunen. Dan had men Base64 wel uit z'n hoofd gelaten!
Wat wijzigingen betreft: Sharepoint nogmaals. Leuk! Delta documenten. Misschien koppelen aan een SBM pakketje...
[
Voor 7% gewijzigd door
Umbrah op 17-08-2011 10:47
]
:strip_icc():strip_exif()/u/147658/crop5dcbc3f3ef95c_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/16043/modriaan-compositie_dambord.jpg?f=community)
:strip_icc():strip_exif()/u/93100/crop58a9d2a8b7692_cropped.jpeg?f=community)
:strip_exif()/u/49483/mandarin_sm.gif?f=community)
:strip_icc():strip_exif()/u/372993/crop55da1160c0d23_cropped.jpeg?f=community)
/u/45013/GoT%2520-%2520QR.png?f=community)
/u/61403/crop58bff192a74cb_cropped.png?f=community)
/u/86654/crop68d4ff30987a8.png?f=community)
:strip_icc():strip_exif()/u/135404/crop586e284093763_cropped.jpeg?f=community)
/u/34216/avatar-60x60.png?f=community){kind=avatar}
:strip_exif()/u/32998/tweakpiggy_anim.gif?f=community)
/u/259445/NLDeX.png?f=community)
/u/175440/crop5b5f0d899a5e8_cropped.png?f=community)
:strip_icc():strip_exif()/u/77151/crop56c8611200b21_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community)
:strip_exif()/u/106146/bleach_usericon.gif?f=community)
Dit topic is gesloten.
