Google verhoogt limiet voor inkomende Gmail-bijlagen naar 50MB

Google heeft een verandering van zijn Gmail-dienst aangekondigd, waardoor gebruikers grotere bijlagen kunnen ontvangen. De maximale bestandsgrootte is verhoogd naar 50MB. Dit geldt niet voor verstuurde bijlagen.

Google maakt de verandering bekend op zijn G Suite-blog. Daarin stelt het bedrijf dat de grotere bestandsgrootte vanaf donderdag ingaat voor alle Gmail-gebruikers. Zij moeten in de komende drie dagen van de nieuwe functie gebruik kunnen maken.

Tot nu toe gold er een limiet van 25MB voor het ontvangen van bijlagen. Voor grotere bestanden moeten gebruikers uitwijken naar Google Drive, aldus de zoekgigant. Gebruikers die zelf een bijlage willen versturen, zitten nog wel vast aan de limiet van 25MB. Waarom daar geen wijziging in komt, maakt Google niet bekend. Ook blijkt niet dat er plannen zijn om de maximale bestandsgrootte voor uitgaande bijlagen aan te passen.

Google begon in 2004 met het aanbieden van Gmail-accounts met een opslag van 1GB, wat in eerste instantie werd gezien als grap. Inmiddels is de gratis opslag opgelopen tot 15GB per gebruiker, die wordt gedeeld tussen Gmail, Drive en Photos. Google maakte eerder bekend dat sinds deze maand geen javascript-bestanden meer als bijlage verstuurd kunnen worden uit veiligheidsoverwegingen.

Reacties (117)

[CAPSLOCK2000]

Gebruikers die zelf een bijlage willen versturen, zitten nog wel vast aan de limiet van 25MB. Waarom daar geen wijziging in komt, maakt Google niet bekend. Ook blijkt niet dat er plannen zijn om de maximale bestandsgrootte voor uitgaande bijlagen aan te passen.

Het is voor mij wel duidelijk waarom ze dat niet doen, de rest van de wereld ondersteunt het namelijk niet*. Google kan wel mailtjes van 50MB gaan versturen maar geen enkele mailserver gaat dat accepteren. Al die mail gaat dus retour afzender. In de ogen van de gebruiker is het dan alsof GMail stuk is.

Ik heb eigenlijk liever dat Google hier van af blijft. De wereld van e-mail is niet gericht op het verplaatsen van bestanden, dat is maar gruwelijk inefficient en zorgt overal voor problemen. Tal van bedrijven hebben nog kleine mailboxen omdat een grote Exchange-omgeving met gigabytes aan storage per gebruiker veel te duur is. Dat zorgt weer voor talloze problemen en afschuwelijke hacks om daar om heen te komen (je weet wel, gerommel met PST-files).
Laat het versturen van grote bestanden per e-mail nu maar een stille dood sterven, er zijn zat alternatieven.

* ok, er zijn een paar uitzonderingen, maar dat zijn het: uitzonderingen

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 17:42]

[jiriw]

Wat ik me vooral afvraag; waarom (zeker bij webmail-diensten en zeker bij Google waar GMail en Drive al gebruik maken van dezelfde storage pool) is dat hele grote attachmentgedoe niet al weggeautomatiseerd?
Gewoon standaard een 'achter de schermen' webdownloadfolder aanmaken als een gebruiker grote attachments mee wil sturen. Een verwijzing ernaar als attachement in de e-mail. Het liefst in een gestandaardiseerde vorm, zodat het transparant kan worden tussen verschillende e-mail providers. Dan net als een 'no-script' detectie, bij gebruikers die 'ouderwetse email zonder grote bestandsondersteuning' lezen, in een e-mail client die dit nieuwe systeem nog niet ondersteunt, de download link zichtbaar hebben zodat zij weten dat ze hun bestanden bij de storage dienst kunnen ophalen.
Voor alle anderen lijkt het gewoon op iedere andere attachment. Alleen in de achtergrond wordt er een download van een storage dienst gestart in plaats van een bestand gedecodeerd uit de e-mail zelf. Werkt in ieder geval niet veel anders voor IMAP, waarbij de mail toch standaard op de server van de provider blijft. Als je POP gebruikt en verwacht dat de e-mail inclusief attachements van de servers van je mail provider wordt geplukt en op je PC wordt opgeslagen, is het misschien een iets ander verhaal. Maar zelfs daar kan je met een geupdate client er voor zorgen dat die attachments ge-'pre'-download worden. Houd je alleen de mensen over die nooit hun software updaten. Tsja...

[Transferno]

Goeie vraag en het antwoord is dat het voor GMAIL al zo werkt. Je kunt gewoon grote files in je mail plakken en GMAIL geeft dan aan dat deze te groot is en dus via google drive (link) wordt verstuurd.
Werkt goed moet ik zeggen.

Hier staat een beetje info erover:
https://support.google.co....Platform%3DDesktop&hl=nl

[djwice]

Simpel, mijn powerpoint voor de keynote voor volgende week kon ik begin deze week niet van m'n werkmail naar Gmail krijgen, omdat Gmail dat niet accepteerde.

Nu gaat dat wel.

[Reactie gewijzigd door djwice op 23 juli 2024 17:42]

[BeosBeing]

Gewoon standaard een 'achter de schermen' webdownloadfolder aanmaken als een gebruiker grote attachments mee wil sturen. Een verwijzing ernaar als attachement in de e-mail. Het liefst in een gestandaardiseerde vorm, zodat het transparant kan worden tussen verschillende e-mail providers. Dan net als een 'no-script' detectie, bij gebruikers die 'ouderwetse email zonder grote bestandsondersteuning' lezen, in een e-mail client die dit nieuwe systeem nog niet ondersteunt, de download link zichtbaar hebben zodat zij weten dat ze hun bestanden bij de storage dienst kunnen ophalen.

En dan heeft het bedrijf waar je werkt je toegang tot internet geblokkeerd en kun je alleen op bedrijfsinterne webservers. Bij grote bedrijven is dit vaak het geval.

[jiriw]

Dat soort grote bedrijven hebben ook het IT personeel en geld om een proxy op te zetten voor die attachments. Vooral als dit 'grote attachment protocol' gestandaardiseerd is tussen verschillende e-mail providers, is daar prima software voor te schrijven. E-mail scannen doen ze nu toch al. Om virussen te voorkomen of te voorkomen dat medewerkers bedrijfsadressen voor persoonlijke doeleinden gaan gebruiken. Kunnen ze ook wel iets schrijven/installeren dat die linkjes volgt en de attachments preventief gaat downloaden.

[BeosBeing]

5 woorden. Dat doen ze dus niet.

[page404]

Overigens heeft Apple wel een elegante oplossing gevonden met zijn mail-app. Mails die via iCloud verzonden worden, hebben een max. attachmentgrootte van 5 gigabyte. Het leuke is dat tussen iCloud gebruikers deze overdracht geheel transparant gaat, maar voor niet-iCloud ontvangers van zo'n mail is er een handige oplossing verzonnen: zij ontvangen gewoon een linkje naar het bestand vanwaar ze het kunnen downloaden. Dat is dus de "wetransfer' oplossing, maar tussen iCloudgebruikers is die volledig transparant.
Het heet trouwens Maildrop.

De normale limiet ligt op 20MB bij iCloud.

[raro007]

Je bedoeld net als met gmail je voegt Google drive link?

[monojack]

Het verschil is dat bij Apple Mail het allemaal gebeurt net zoals je een bijlage aan een mail toevoegt. Als de ontvanger ook over Apple mail beschikt dan is het zelfs geen link en komt het als bijlage in je mailbox terecht.

Het is echt een veel elegantere oplossing dan dat geklooi met Google Drive

[RielN]

Een Google-gebruiker ziet die bijlage van een google Drive-link echter ook als een bijlage

Hetzelfde principe, even elegant. En dan kun je ook nog tot 5 terabyte gaan

[Reactie gewijzigd door RielN op 23 juli 2024 17:42]

[Hieronymus.B]

Dat document verwijst naar de verzend limieten van icloud. Hier is de (correcte) directe link naar maildrop:
https://support.apple.com...le=en_US&viewlocale=nl_NL

N.B. Hier is nog de link over verzendlimieten gewoon in het plat nederlands:
"Grootte van postbus en verzendlimieten voor berichten in iCloud"
https://support.apple.com/nl-nl/HT202305

[Reactie gewijzigd door Hieronymus.B op 23 juli 2024 17:42]

[Jazzy]

Weet niet precies wat je met 'de rest van de wereld' bedoelt maar Exchange Online in Office 365 ondersteunt 150 MB. Is gewoon een kwestie van met de tijd en met de ontwikklingen mee gaan.

[CAPSLOCK2000]

Weet niet precies wat je met 'de rest van de wereld' bedoelt maar Exchange Online in Office 365 ondersteunt 150 MB.

Er zijn altijd uitzonderingen, maar organisaties die meer dan 25MB (unencoded) of 50MB (encoded) accepteren zijn zeldzaam.

Is gewoon een kwestie van met de tijd en met de ontwikklingen mee gaan.

Ja en nee, met je tijd mee gaan kan ook iets anders zijn dan "meer en groter", soms moet je dingen anders aanpakken. Op een gegeven moment moet je stoppen met snellere paarden te fokken en overstappen op een auto.

Het SMTP-protocol is helemaal niet handig om grote bestanden te versturen, de overhead is gigantisch en er is geen resume-optie om grote bestandsoverdrachten te hervatten. Hoe groter de mail die je stuurt hoe groter de kans dat er een foutje optreedt waardoor je opnieuw moet beginnen.

Ik zou nog wel te porren zijn voor een nieuwe versie van SMTP om de boel flink te moderniseren. Dan kunnen we ook wel weer eens naar het mailen van grote files kijken, maar met het huidige SMTP zou ik die hond liever niet meer wakker maken.

[rbr320]

Ik zou nog wel te porren zijn voor een nieuwe versie van SMTP om de boel flink te moderniseren. Dan kunnen we ook wel weer eens naar het mailen van grote files kijken, maar met het huidige SMTP zou ik die hond liever niet meer wakker maken.

In dat geval kan je die S in SMTP wel weg laten
Overigens ben ik het met al je argumenten eens, email is nooit bedoeld geweest om grote bestanden te verplaatsen, daar zijn inmiddels betere oplossing voor dus laat men die dan ook gebruiken.

[quinn77]

Outlook (particulieren) zit anders nog steeds op 15MB
Idem voor mijn werk email (vreselijk irritant )

[RobbyTown]

En dan heb je mensen die nooit mails weggooien en dan klagen dat Outlook traag is met 15 GB + nog extra mailboxen van collega's die elk ook 8 tot 12 GB zijn

[DonnyBe]

of met 8 shared mailboxen van elk 10GB to max 30GB
gelukkig heeft MS nu 50GB ruimte voor elke mailbox.

[Hann1BaL]

Offtopic maar Microsoft heeft voor O365 de mailboxen vergroot naar 100GB.
Dat geeft wel aan dat email zich toch ontwikkelt naar groter en meer en het is geen vreemde gedachte om dan ook grotere bijlages toe te staan. Ik begrijp dat het niet zo efficient is, maar een 50MB limitatie is niet erg laag.

[DonnyBe]

Die 100GB is idd mogelijk, aan de dubbele prijs van 50GB, en niet standaard in de Office Business Premium die we hier hebben.

[Hann1BaL]

In de E3 licentie zit de verhoging van de mailbox standaard bij.

[lukjah]

Probleem met standaarden is dat bijna iedereen ze moet gebruiken voordat je ze fatsoenlijk kan gebruiken. Leuk dat MS 150mb ondersteunt maar dat vindt de rest van de wereld niet zo leuk.

[Jazzy]

MB, hoofdletters. In dit geval gaat het niet om een standaard maar om een geleidelijke ontwikkeling. De ene partij loopt een beetje voorop, de andere volgt wat later. Maar zoals ik net ook in een andere reactie zei, een beetje attachment is al snel groter dan 15 MB. Dat is nu heel anders dan het 10 jaar geleden was, hetzelfde geldt voor bandbreedte en opslag. Dan is het ook logisch dat dit soort limieten verhoogd worden.

[DarkSide]

En zelf vind ik dat wel onzinnig. de 25mb limiet is misschien wat klein.
Zeker voor opa en oma die wat foto;s (een dslr neemt tegenwoordig al 15-20mb in beslag) willen versturen.
Voor de rest heb je idd (zoals ergens al vermeld is) zaken als google drive, one-drive etc om zo grote bestanden te delen. Dat hoort ook bij office 365. Dan stuur ik niet bergen met attachments maar links naar mijn onedrive om samen te werken.

Voor de wat oudere onder ons misschien nog niet te begrijpen.
Laatst ook met mijn vader zo een document verstuurd. Die stond verbaasd dat hij zomaar was aangepast :-)

[GeoBeo]

[...]

Het is voor mij wel duidelijk waarom ze dat niet doen, de rest van de wereld ondersteunt het namelijk niet. Google kan wel mailtjes van 50MB gaan versturen maar geen enkele mailserver gaat dat accepteren. Al die mail gaat dus retour afzender. In de ogen van de gebruiker is het dan alsof GMail stuk is.

Ik heb eigenlijk liever dat Google hier van af blijft. De wereld van e-mail is niet gericht op het verplaatsen van bestanden, dat is maar gruwelijk inefficient en zorgt overal voor problemen. Tal van bedrijven hebben nog kleine mailboxen omdat een grote Exchange-omgeving met gigabytes aan storage per gebruiker veel te duur is. Dat zorgt weer voor talloze problemen en afschuwelijke hacks om daar om heen te komen (je weet wel, gerommel met PST-files).
Laat het versturen van grote bestanden per e-mail nu maar een stille dood sterven, er zijn zat alternatieven.

Ik heb geen ervaring met bedrijfsinfrastructuren opzetten, maar dit lijkt me allemaal erg karig? Waarom?

Waarom kan een bedrijf's mailserver(cluster) anno 2017 geen emailtjes van 50mb?! Of liever nog: waarom geen attachment van 1 GB ondersteunen?

Zoals je zelf ook zegt: "er zijn genoeg alternatieven voor email" om grote bestanden te versturen. Dus dat kan/mag dan wel? Waarom kan een groot bestand wel "op een alternatieve" manier verstuurd worden over/vanuit/naar een bedrijfsnetwerk, maar niet via een mailserver?!

Heeft het ermee te maken dat je als bedrijf voor je exchange licentie moet betalen per hoeveelheid opslag o.i.d.?

[CAPSLOCK2000]

Zoals je zelf ook zegt: "er zijn genoeg alternatieven voor email" om grote bestanden te versturen. Dus dat kan/mag dan wel? Waarom kan een groot bestand wel "op een alternatieve" manier verstuurd worden over/vanuit/naar een bedrijfsnetwerk, maar niet via een mailserver?!

Ten eerste encoding. E-mail is gemaakt voor tekst, niet voor binaire bestanden. Daarom moeten binaire bestanden worden ingepakt, daarmee worden ze zo'n 50% groter. Erg efficient is het dus zeker niet.
Verder heb ik begrepen (en ik ben geen expert, verre van dat) dat Exchange nogal zwaar is en veel overhead met zich mee brengt. Om het goed te doen heb je een hele stack aan professionele apparatuur en software nodig, een gespecialiseerde backup oplossing, een gespecialiseerde virusscanner, een mannetje om het allemaal te beheren en weet ik veel wat nog meer. Als je een bepaalde drempel over gaat dan vliegen de kosten om hoog. Daarom worden er vaak strenge regels en limieten opgelegd zodat het allemaal werkt met de beschikbare hardware. (Nogmaals, ik heb geen eigen ervaring met Exchange, er zijn hier vast mensen die het beter weten).

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 17:42]

[rbr320]

Ik kan alle veronderstellingen die je doet over de kosten en load van een Exchange omgeving beamen. Ik heb zelf jarenlang op een universiteit gewerkt waar men had besloten om de email zelf te gaan hosten in plaats van dit uit te besteden aan bijvoorbeeld Google of Microsoft. Het personeel en alle studenten samen zijn zo'n 30.000 mensen, dat is behoorlijk wat maar Microsoft had beloofd dat het geen probleem zou zijn. Er werden zware limieten ingesteld op de maximale grootte van mails (ik dacht 50MB) en de totale mailbox (1GB voor studenten, 2GB voor personeel). Men is begonnen met virtuele servers maar dat liep voor geen meter. Zelfs op krachtige bare-metal servers bestond de totale mail omgeving uiteindelijk uit meerdere machines en waren er nog steeds regelmatig problemen met performance. Het kost dan ook een flink aantal manuren om de boel in de lucht te houden en die zijn ook niet goedkoop. Al met al geen succes wat mij betreft, maar ik was gelukkig niet verantwoordelijk voor het beheer.

[tc-t]

Waarom kan een bedrijf's mailserver(cluster) anno 2017 geen emailtjes van 50mb?! Of liever nog: waarom geen attachment van 1 GB ondersteunen?
...
Heeft het ermee te maken dat je als bedrijf voor je exchange licentie moet betalen per hoeveelheid opslag o.i.d.?

Omdat er gebruikers zijn die alles bewaren (jarenlang) net zoals er gebruikers zijn die nooit iets bewaren.
Als je dus pech hebt zit die leuke bijlage van 1GB in de sent items van user1 én in de inbox van user2.
En dan gaat het maar over 1 mailtje...

De diskruimte in de mailserver is niet onbeperkt, en uiteraard moet dat ding ook nog gebackupt worden 's nachts.

[GeoBeo]

[...]

Omdat er gebruikers zijn die alles bewaren (jarenlang) net zoals er gebruikers zijn die nooit iets bewaren.
Als je dus pech hebt zit die leuke bijlage van 1GB in de sent items van user1 én in de inbox van user2.
En dan gaat het maar over 1 mailtje...

De diskruimte in de mailserver is niet onbeperkt, en uiteraard moet dat ding ook nog gebackupt worden 's nachts.

Dan stel je toch een user-inbox opslagruimte limiet in? Die is er sowieso al lijkt me?

Ik snap nogmaals het probleem niet?

[tc-t]

Dan stel je toch een user-inbox opslagruimte limiet in? Die is er sowieso al lijkt me?
Ik snap nogmaals het probleem niet?

Dat zou een oplossing kunnen zijn.
Standaard is die limiet er niet - alleszins: niet in het product dat wij gebruiken.
En enkele van die personen die alles bijhouden zijn onze technische directeur en 1 van de verkopers. Daar valt niks tegen te beginnen.

Dat zijn natuurlijk gewoon bedrijfspolicies (of in ons geval: geen policies) en zal natuurlijk niet overal zo zijn. Wij zullen toch wel niet de enigen zijn met soortgelijke problemen.

[GuruMeditation]

Dan stel je toch een user-inbox opslagruimte limiet in? Die is er sowieso al lijkt me?

Dan zet je een limiet van 100GB en gaat de gebruiker vervolgens klagen dat hij maar een paar, of voor een zeer korte periode, mailtjes kan bewaren. En loop je weer achter de feiten aan. Want als ze eenmaal grote bestanden kunnen mailen gaan ze er uiteraard ook volop gebruikt van maken.

[GeoBeo]

Dan stel je toch een user-inbox opslagruimte limiet in? Die is er sowieso al lijkt me?

Dan zet je een limiet van 100GB en gaat de gebruiker vervolgens klagen dat hij maar een paar, of voor een zeer korte periode, mailtjes kan bewaren. En loop je weer achter de feiten aan. Want als ze eenmaal grote bestanden kunnen mailen gaan ze er uiteraard ook volop gebruikt van maken.

100GB? Dat is per gebruiker/inbox neem ik aan? Zodra de gebruiker klaagt krijgt hij gewoon en bericht te zien dat hij wat moet verwijderen. Net als bij *elke andere* maildienst, inclusief de huidige van het bedrijf?

Aan de kosten kan het niet meer liggen. Voor minder dan 500 EUR heb je een 10TB schijf, laten we dat ruimhartig x2 doen voor backups en je kunt 100 werknemers van zowat ongelimiteerde inboxes voorzien de komende 5 jaar (en daarna met nieuwere hardware de opslag weer keihard omhoog gooien). Dat is voor een bedrijf met 100 werknemers kleingeld. Om maar een voorbeeld te noemen.

Ik heb toch een beetje het idee dat de sysadmin mentaliteit is blijven hangen rond het jaar 2000 ofzo.

[Sysosmaster]

Das een non argument als je het hebt over de Send / Recieve buffers.
De belangrijkste reden dat dit beperkt is heeft er mee te maken met hoeveel mailtjes je tegelijkertijd kunt verwerken.
Ieder mailtje kost namelijk tot de maximum ruimte in de buffer totdat deze afgeleverd is in de gebruikers mailbox.

Hoe groter de buffer hoe minder mailtjes je kunt verwerken.
Bij systemen die meer dan 32K mailtjes per seconden moeten kunnen verwerken heb je dus al 32Gig geheugen nodig per mail buffer.

Dus 2 Mail Buffers ala 32Gig is dus al 64Gig voor enkel Mail buffer (en nee dat kun je dus niet ff naar disk schrijven ivm. performance)

Pak daar een standaard setup bij at scant op spam / virus en andere zooi, (buffer *2), zitten we al op een systeem met 128 Gig enkel voor mail handeling. De systeemen die dat soort geheugen aan kunnen zijn niet goedkoop. en je moet ook nog je mailtjes ergens (tenminste 2 keer) opslaan. Met clustering kun je dit probleem wel oplossen maar het kost je hoe dan ook veel effort.

De Disk ruimte die je mail-boxen in nemen hoewel groot is al jaren niet meer de beperkende factor als het om mail gaat.

[tc-t]

Kan best zijn, maar ík heb het niet over send/receive buffers.
Ik probeer aan te geven waarom sommigen niet zitten te wachten op attachments van 1GB zoals GeoBeo suggereert.

[Jazzy]

Een fatsoenlijk geïmplementeerde Exchange-omgeving kan gewoon attachments van meerdere honderden megabytes verwerken, dat is het probleem niet. Qua licenties maakt het niets uit en aangezien je tegenwoordig goedkope 4TB SAS of SATA disks kunt gebruiken speelt opslag ook amper meer een rol.

Dat was een jaar of tien geleden wel anders. Toen waren schijven van 150GB nog heel erg duur en had je veel meer IOPs nodig. Veel bedrijven zitten nog steeds een beetje in die mindset.

Maar als je nu een hosted Exchange Online mailbox koopt krijg je dus ook gewoon een 100 GB mailbox die attachments van 150 MB ondersteunt. Aan Exchange ligt het niet.

[ZpAz]

Google zou met een vergelijkbare oplossing kunnen komen als Apple's MailDrop. Hiermee kan je bestanden tot 5GB versturen. Bijlage's groter dan ik meen 25MB worden dan encrypted naar iCloud upgeload.

Bekijk je het bericht in een Apple Client dan lijkt het net op een normale bijlage, bekijk je het in een andere client, dan zie je een download link vergelijkbaar met als je iets via WeTransfer zou sturen.

[Transferno]

Dit bedoel je?
https://support.google.co....Platform%3DDesktop&hl=nl

[ZpAz]

Ja, dat lijkt hetzelfde principe te hanteren.

[B64]

Als het echt zo zwart-wit is, dan is dit dus eigenlijk een verbetering voor de bühne. Want als niemand (of bijna niemand) mail van 50MB kan ontvangen, dan kan ook (bijna) niemand ze versturen. Dus dan rijst alsnog de vraag voor wie ze dit doen?

[CAPSLOCK2000]

Als het echt zo zwart-wit is, dan is dit dus eigenlijk een verbetering voor de bühne. Want als niemand (of bijna niemand) mail van 50MB kan ontvangen, dan kan ook (bijna) niemand ze versturen. Dus dan rijst alsnog de vraag voor wie ze dit doen?

Goede gewoontes, wees progressief in wat je accepteert van anderen en conservatief in wat je naar anderen toestuurt. Als er genoeg organisaties zijn die aankondigen dat ze vanaf nu grotere mails accepteren dan kan vroeg of laat de limiet voor verzenden ook omhoog.

[bilbob]

fastmail.com ondersteund al jaren 50 MB

Is zelfs iets hoger ivm encoding.

--uit de help gecopypast--
You may send any kind of attachment, as long as the resulting email is under 70 MB in size (due to encoding issues this usually means an attachment of 50 MB). Attachments with double file extensions (e.g. filename.doc.exe) are not allowed, as they are commonly used for virus transmission.

The same maximum size limit of 70 MB (due to encoding issues this usually means an attachment of 50 MB) applies to received email as well.
----

ik vind overigens niet dat het handig is om zulke grote bestanden per e-mail te versturen.

[Reactie gewijzigd door bilbob op 23 juli 2024 17:42]

[mmniet]

buiten het feit dat het een aardig punt is wat je noemt dat gebruikers dan denken dat google stuk is, kunnen ze daar iets intelligents op maken dat de foutmelding die terug komt userfriendly gemaakt wordt. Voor de gemiddelde leek is het vaak onduidelijk wat die bounce mailtjes betekenen.

Verder snap ik het niet van Google waarom ze dan uitgaande in zijn geheel beperken tot 25 mb, want je kunt toch stellen dat als je als GMAIL onderling mailt het wel zou moeten werken? Een beetje ontwikkelaar bouwt het zo dat je kijkt bij het emailadres naar het domein en dan ziet dat het gmail is en dan accepteert het ding wel meer dan 25 mb

[CAPSLOCK2000]

buiten het feit dat het een aardig punt is wat je noemt dat gebruikers dan denken dat google stuk is, kunnen ze daar iets intelligents op maken dat de foutmelding die terug komt userfriendly gemaakt wordt. Voor de gemiddelde leek is het vaak onduidelijk wat die bounce mailtjes betekenen.

Eerlijk gezegd is dat een beetje windmolens vechten, de meeste gebruikers proberen niet eens om foutmeldingen te begrijpen, maar dat is een rant voor een andere keer.

Verder snap ik het niet van Google waarom ze dan uitgaande in zijn geheel beperken tot 25 mb, want je kunt toch stellen dat als je als GMAIL onderling mailt het wel zou moeten werken?

Ik denk dat ze het nu als test doen om te zien hoeveel mailservers grote bestanden naar gmail toe gaan sturen. Aan de hand daarvan kunnen ze een inschatting maken hoeveel mailservers grote attachments ondersteunen.

Ik verwacht dat de volgende stap is dat je inderdaad met andere Google-gebruikers grotere bestanden kan uitwisselen, al dan niet aangevuld met mailservers die ze in de eerste stap hebben verzameld.

Een beetje ontwikkelaar bouwt het zo dat je kijkt bij het emailadres naar het domein en dan ziet dat het gmail is en dan accepteert het ding wel meer dan 25 mb

Het lijkt met niet wenselijk om voor 1 partij een uitzondering in te bouwen in algemene software. Morgen is er een ander die hetzelfde wil. Je kan onmogelijk voor alle domeinen gaan bijhouden hoe groot de attachments zijn, er zijn miljoenen domeinen. Misschien dat je het automatisch kan bijhouden zoals ik hierboven omschreef, maar dat blijft een beetje onhandig.

[mmniet]

een uitzondering bouwen en dan steeds handmatig een domein/server toevoegen die het ook kan is wat dat te ver gaat, maar niet moeilijk. Je kunt heel eenvoudig voor gmail een uitzondering bouwen. Simpelweg reden genoeg om te doen om je eigen dienst voor te trekken en te laten zien wat je allemaal kunt.

om automatisch domeinen toe te voegen vind ik op zich ook geen technische uitdaging (en dat zeg ik als techneut). Je kunt op een gegeven moment dan gewoon alle mailservers als uitgaand accepteren. Kan een ontvangende partij het niet aan, dan is het op een gegeven moment de uitzodnering. De wereld kan het allemaal wel aan. Die ene oude server die het niet kan heeft dan pech.

[BeosBeing]

De wereld van e-mail is niet gericht op het verplaatsen van bestanden, dat is maar gruwelijk inefficient en zorgt overal voor problemen. Tal van bedrijven hebben nog kleine mailboxen omdat een grote Exchange-omgeving met gigabytes aan storage per gebruiker veel te duur is. Dat zorgt weer voor talloze problemen en afschuwelijke hacks om daar om heen te komen (je weet wel, gerommel met PST-files).

Klopt. Echter je gaat niet zo gemakkelijk de gebruiker zijn gewoontes laten veranderen tenzij je een alternatief bied dat voor de gebruiker makkelijker is.

Dat inefficiënt is dan ook vooral vanuit het oogpunt van computing- en netwerkresources.

Als je gemak/efficiëncy van de gebruiker hoger stelt, dan is het ook niet optimaal (zoek dat bestand van vorig jaar maar op, velen vinden het nooit en ook wie het wel vindt heeft daaraan te veel tijd verspilt. Maar daarvandaan is het al minder erg. Wetransfer en Dropbox en dergelijke zijn vanuit gebruiksoogpunt ook niet efficient, slechter nog dan e-mail. Daarbij levert ook Dropbox problemen in bedrijfs- en soortgelijke omgevingen.

Laat het versturen van grote bestanden per e-mail nu maar een stille dood sterven, er zijn zat alternatieven.

Dat is afhankelijk van de omgeving. Bedrijfsintern kun je linkjes doorsturen maar dan moeten op de share wel de rechten goed staan en hoeveel mensen sturen dan niet een link naar het bestand hun eigen personal share of eigen c:-schijf. Gebruikt men wel een share dan kiest men vaak de verkeerde en meestal staan de rechten te restrictief. Immers wil je als (groot) bedrijf ook niet dat ieder zijn eigen versie gaat bijhouden.

Naar buiten de organisatie wordt het al moeilijker. Ja je kunt een webserver gebruiken om dingen op te plaatsen maar toegang wordt dan een extra administratieve last. Met dropbox kan de grbruiker dat zelf regelen maar dan ben je als bedrijf al snel de controle kwijt.

Andere cloud-opslag, er zijn veel grote bedrijven die hun werknemers wel voorzien van e-mail maar hun internetgebruik aan banden leggen. Op de bedrijfseigen cloud kan wel (zie webserver) maar als mensen moeten samenwerken met externen is het ook een probleem.

[beerse]

Detail: Er zit een groot verschil tussen de maat van het bestand wat je wilt meesturen en de maat van het bericht dat je verstuurt! Bestanden die als bijlage worden meegestuurd, worden met mime gecodeerd, wat inhoud dat het 'leesbare ascii' wordt en netjes in regels van maximaal 76 karakters. Daarmee wordt een bestand ongeveer een derde groter!

Oftewel: een foto van 3 MB per mail versturen maakt een bericht van 4 MB.

En als je grote bestanden verstuurt moet de ontvanger het ook maar kunnen ontvangen. Niet iedere email-provider accepteert mailtjes van meer dan 10 MB. Dat mislukt pas als het bericht bij binnenkomst over die grens gaat.

[P1nGu1n]

Extra info: hier wordt doorgaans Base64 voor gebruikt.
3 bytes worden omgezet naar 4 karakters en iedere 76 karakters een nieuwe regel, vandaar de toename van 37%

quote: https://en.wikipedia.org/wiki/Base64#MIME

Thus, the actual length of MIME-compliant Base64-encoded binary data is usually about 137% of the original data length, though for very short messages the overhead can be much higher due to the overhead of the headers. Very roughly, the final size of Base64-encoded binary data is equal to 1.37 times the original data size + 814 bytes (for headers).

[Reactie gewijzigd door P1nGu1n op 23 juli 2024 17:42]

[BeosBeing]

Detail: Er zit een groot verschil tussen de maat van het bestand wat je wilt meesturen en de maat van het bericht dat je verstuurt! Bestanden die als bijlage worden meegestuurd, worden met mime gecodeerd, wat inhoud dat het 'leesbare ascii' wordt en netjes in regels van maximaal 76 karakters. Daarmee wordt een bestand ongeveer een derde groter!

Daarbij ben ik al veel mails tegengekomen waar die leesbare ascii ergens voorbij halverwege wordt afgekapt en dus door de ontvangende client niet meer wordt herkend. Zie ik in mijn mailbox een bericht met dergelijke encoding er onder dan doe ik al geen moeite meer.

[alwaysleft]

Als je een bijlage wilt versturen met bv 60 Mb aan foto's raad ik de app Google Photo's aan. Albumpje maken en link delen via de mail, ideaal. Doe niets anders meer, met afgelopen kerst bv. super handig

[Reactie gewijzigd door alwaysleft op 23 juli 2024 17:42]

[Cergorach]

Dit is dus precies de reden waarom ze die limiet van 25mb niet verhogen. E-mail is geen bestand verzend systeem.

[monojack]

Ik verstuur regelmatig mails van 200mb en meer. Ik sta dan ook eigenlijk versteld dat Gmail nog steeds zo'n lage limiet heeft. Via Apple Mail verstuur je tegenwoordig tot 5GB

[Raventhorn]

Waarom mails van meer dan 200Mb? (er van uitgaande dat je MB bedoeld, anders effectief 25MB; zelfde als de Google limiet dus...)
Is het niet veel sneller/praktischer/logischer om een FTP-share te gebruiken, of via een clouddienst (Mega, WeTransfer, OneDrive, Google Drive, Dropbox etc) dat soort formaten te delen?

Persoonlijk verbaas ik me er meer over dat mensen blijkbaar niet genoeg hebben aan 25MB voor een e-mail...
Al verbaas ik me er niet over dat mensen een systeem (mis/ge)bruiken waar het niet voor bedoeld is.

[catfish]

Emails versturen gaat gewoon zeer gemakkelijk.
Ik verbaas me er dagelijks in dat men nog steeds geen gebruiksvriendelijke manier heeft bedacht om grote bestanden te versturen.
Hoe het achter de schermen werkt is niet belangrijk voor de gebruiker, die wil gewoon een bestand versturen. Een emailclient die zelf het bestand upload naar een service en de ontvanger een link geeft lijkt mij bv een oplossing.
Zaken zoals Wetransfer zijn gewoon niet gemakkelijk in gebruik.

[monojack]

Dat is dus wat Apple Mail doet. Je voegt je bestand toe aan je mail en verstuurd hem. Achter de schermen wordt dat natuurlijk upgeload (via Maildrop). maar voor de gebruiker is het zo simpel als een groot bestand toevoegen aan een mail

[RobLemmens]

Hoezo is mail niet bedoeld om grote bestanden te versturen. In de tijd dat het voor het eerst gebruikt werd was 1MB enorm groot. Het is voor heel veel mensen eerder gek dat het nog steeds maar 20MB is terwijl ze dagelijks met bestanden van meerdere gigs werken. Wij tweakers snappen maybe dat het nogal een belasting is voor alle mailservers maar leg dat maar eens aan een niet it er uit.

[Raventhorn]

Hoezo is mail niet bedoeld om grote bestanden te versturen.

Het kunnen meesturen van bestanden is pas in een latere revisie er bij gekomen E-mail stamt (als ik het goed heb) uit de jaren 60, pas in de jaren 70 kwam daar de mogelijkheid voor bijlagen bij. (Destijds nog op het ARPANET)
Alleen worden die niet heel erg efficiënt gecodeerd (wordt omgezet in leesbare karakters), waarbij het formaat met iets van 37% oploopt... Dat betekent dus dat je 37% meer gegevens moet downloaden, wat bij grote bestanden flink oploopt...

Met bestanden van 1MB gaat het wel, dan wordt het grofweg 1,37 MB. Maar bij 100MB wordt het al 137MB. Bij 1GB wordt het dus 1,37GB...
En die bijlagen moeten ook worden opgeslagen op een mailserver, je wil ze uiteraard niet zomaar kwijt zijn.
Vanwege de extra data en de beperkte internetsnelheden werd destijds FTP (File Transfer Protocol) aangeraden om grotere bestanden te versturen. Daar heb je geen last van de extra data, alles kan 1-op-1 worden overgedragen.
Tegenwoordig worden vooral clouddiensten aangeraden; die zijn wat voor veel mensen toegankelijker en gebruiksvriendelijker dan een FTP server, maar in essentie doen ze hetzelfde.

Wij tweakers snappen maybe dat het nogal een belasting is voor alle mailservers maar leg dat maar eens aan een niet it er uit.

In sommige gevallen is het ook gewoon niet uit te leggen aan niet-IT'ers...

[monojack]

Een systeem misbruiken? En dan nog komen vertellen dat FTP praktischer of logischer zou zijn?

Hoe zou een FTP share, of Mega, WeTransfer, etc. praktischer of logischer zijn als je gewoon je bestand met je mail kan mee sturen? Ik denk dat je niet veel ervaring hebt met MacOS anders zou je zo'n onzin niet vertellen!

Ik geef je een voorbeeld van het soort mails dat ik verstuur. Ik ben muziekproducer en werk samen met andere artiesten. Ik stuur dan ook regelmatig een DAW bestand rond dat ook wordt teruggestuurd naar mij. Vermits de DAW bestanden veel audiobestanden bevatten lopen die als snel op tot soms meer dan een Gig. Het enige wat ik moet is het bestand toevoegen aan mijn mail, versturen en klaar is kees. Ik moet geen browser openen en het bestand uploaden en de ontvanger hoeft ook geen browser te openen om het te downloaden.

Vroeger gebruikte ik dropbox om grote bestanden te versturen maar vermits het nu veel gemakkelijker kan via Apple Mail snap ik echt niet waarom ik de zaak hopeloos ingewikkelder zou maken zoals via de alternatieven die je voorstelt.

[Cergorach]

Dropbox, Onedrive en Googledrive zijn alternatieven die daar voor bedoeld zijn (met vele anderen). Aangezien iedereen die Google Mail heeft ook Google Drive heeft (in theorie), gaat Google NOOIT die 25MB verhogen als ze zelf die dienst aanbieden.

Bijna alle zakelijke diensten (waar Apple Mail er geen één van is) hebben een dergelijke limiet voor ontvangen mail (Office 365, Google Apps for Busines, ect.). Dat heeft een hele goede reden, mailboxen beheren met al die meuk is een crimé...

[Raventhorn]

Een systeem misbruiken? En dan nog komen vertellen dat FTP praktischer of logischer zou zijn?

Yep. E-mail is in de basis niet ontworpen om bestanden te versturen, en al helemaal niet in die orde van grootte
Net als dat briefpost niet ontworpen is om een MacBook mee te versturen. Daar is pakketpost voor...

Hoe zou een FTP share, of Mega, WeTransfer, etc. praktischer of logischer zijn als je gewoon je bestand met je mail kan mee sturen? Ik denk dat je niet veel ervaring hebt met MacOS anders zou je zo'n onzin niet vertellen!

Ik ga er van uit dat je logisch na kan denken, maar dat je misschien niet heel technisch onderlegd bent, anders zou je zelf wel zien dat het onzin is...
Apple heeft de keuze voor de online filesharingdienst/FTP-site gewoon al voor je gemaakt, en upload het daar onderwater naar toe. Je gebruikt dus nog steeds een filesharing dienst, alleen de handmatige acties zijn handig weggestopt en geïntegreerd in je e-mail applicatie.
Oftewel, Apple doet voor jou precies waarvan ik aangaf dat het misschien handiger zou zijn... Alleen dan niet met OneDrive, Google Drive of Dropbox, maar met Mail Drop.

[FreshMaker]

Ik verstuur regelmatig mails van 200mb en meer. Ik sta dan ook eigenlijk versteld dat Gmail nog steeds zo'n lage limiet heeft. Via Apple Mail verstuur je tegenwoordig tot 5GB

Lekker handig, ik ben blij dat mijn mails zo groot niet zijn. ( gmail, dus nu max 50MB )

[Transferno]

Technisch gezien klopt je stelling niet. De apple mail verstuurd de bestanden ook niet via mail maar zet ze in de icloud en stuurt een link mee. Google's Gmail doet hetzelfde in combinatie met zijn drive.
De werkelijke limiet is 20MB voor apple mail en 25MB voor GMAIL, dus een beetje gelijkaardig. GMAIL doet er dan nu een schepje bovenop en laat ook toe om bijlage tot 50 MB te ontvangen (zo ver ik zie nog 20MB bij apple).

[Transferno]

Ja, ik begreep wel wat je bedoelde. Maar het artikel ging erom wat je via mail kunt versturen. En je verstuurd geen 5GB bestanden via de mail maar enkel een "slimme" link. En dat is een erg nette oplossing, daar niet van.

[BeosBeing]

Dus technisch mag de stelling niet kloppen in gebruikerservaring klopt de stelling wel.

Klopt, met één verschil. Veel mensen slaan bestanden uit hun mail niet op op hun HDD maar laten dit in de mail staan. Met zo'n oplossing als maildrop, ongeacht of het die van Apple, Google of een ander betreft blijft die 'bijlage' niet staan. Op een gegeven moment heb je een mail met een dode link in je archief terwijl een echte bijlage wel in je mail-archief zit.

Bij Wetransfer is het duidelijk dat iets daar maar tijdelijk staat.

[Jazzy]

Je punt maken gaat een stuk beter als je de goede eenheid gebruikt. Het is MB, niet mb.

[DonLexos]

Ja die limiet van 25 MB bij versturen is al redelijk fors. Of dat werkt hangt vooral ook af van de partij die de email gaat ontvangen. Die kan m ook doodleuk wegstuiteren boven de 5 MB.

Los even of e-mail nu de beste methode is om grote bijlages te versturen (tov dropbox/drive shares, WeTransfer, etc).

[Jazzy]

Ik zit voor mijn vak in de e-mail en zie zo heel kalmpjes aan een verschuiving naar 40-50 MB bij bedrijven die zelf hun mail regelen. Er zijn altijd uitschieters, zoals Exchange Online met 150 MB, maar die oude 10 MB is niet meer realistisch nu een beetje PDF al snel 12 MB is en een paar foto's van een gemiddelde telefooncamera al 5 MB per stuk zijn.

[FreshMaker]

Ik zou zowel ontvangen als verzenden inderdaad op 50MB willen dan, heb je in ieder geval geen gedoe met ontvangen, maar niet doorzenden.

Al gaan foto's hier via owncloud/dropbox of extern via wetransfer

[Jazzy]

Denk inderdaad dat 50 MB een mooie 'sweet spot' is op dit moment.

[bilbob]

ik raad een wetransfer linkje aan.. Daar worden de ontvangers meestal blijer van.

[alwaysleft]

Qua foto's vind ik Google Photo's veel gebruiksvriendelijker. Fijne is ook dat als iemand anders je Google Photo's linkje stuurt je die gelijk kan importeren naar je eigen cloud en ze dan op datum staan.

[Transferno]

Helemaal mee eens. En voor de andere files werkt de drive van google ook perfect.
Wetransfer werkt ook wel goed, maar veel mensen hebben toch al een gmail account en daardoor is het toch nog net iets makkelijker (je kunt kiezen of je een bijlage lokaal download of meteen in je drive laat zetten).

[slijkie]

of je neemt een Tweakers Abbo en heb je ruimte voor je foto's

[FreshMaker]

transip.nl -> stack -> 1TB

[slijkie]

Heb ik ook ja, alleen dan moet je wel direct een invite hebben

[legacio]

Goed nieuws! Ik liep regelmatig tegen de 25MB limiet aan als ik bijvoorbeeld iemand foto's moest sturen van m'n marktplaats advertentie. Bovendien was het best frustrerend (met mijn trage uploadsnelheid) dat wanneer je de limiet overschreed, je dit pas te zien kreeg als de mail teruggekaatst werd na verzending

[DaaNMageDDoN]

Helaas begrijp je het verkeerd: het gaat alleen om de inkomende email, niet wat je probeert te versturen.

[Zuury]

maar hoe kan je 50mb binnen krijgen als je het niet kan versturen? Volgens mij zijn meeste andere email providers nog lager dan 25mb versturen.

[bytemaster460]

Bij de meeste grote providers wel, maar eigen mailservers of die van een bedrijf kun je instellen op iedere grootte.

[hndrk]

Hij heeft het waarschijnlijk over het verzenden met een andere dienst dan Gmail. Als je iets naar een Gmail adres stuurt dat groter is dan 25MB krijg je een fout bericht terug geloof ik.

[DaaNMageDDoN]

Ja precies, ik ken er niet zo eentje die het toestaat, maar je zou bijvoorbeeld ook een eigen email server kunnen inrichten die wel toestaat berichten > 25MB te versturen.
SMTP is eigenlijk helemaal niet bedoeld voor zulke berichten, maar goed met de resoluties van de huidige smartphone camera's zit je met een paar kiekjes al zo aan bijvoorbeeld 15MB, een historisch veelgebruikte grens bij MS exchange.

[Xellence]

Je kunt tot 50 MB ontvangen, niet versturen. Die limiet blijft op 25 MB staan.

[TheFes]

Je hebt gelezen dat die beperking er nog steeds is? Je kunt nu alleen meer ontvangen. Versturen is nog steeds beperkt tot 25MB

[Optik]

best om we transfer te gebruiken.

[DonLexos]

Als je in dat geval veel grote foto's wil versturen en niet direct aan de dropbox of googledrive shares wil kan je altijd WeTransfer gebruiken. Bijkomend voordeel voor jou is dat je een notificatie ontvangt zodra ze zijn gedownload.

[Euronitwit]

Gebruik dan https://wetransfer.com krijg je ook nog automatisch een notificatie als het bestand is gedownload. Tot 2 GB ineens.

[Rastapopoulos]

In het artikel staat dat de verhoging van de limiet geldt alleen voor het ontvangen van bestanden en dus niet voor het verzenden van je bestanden...

[Xellence]

Vraag me wel af wat er dan gebeurt als je een mail ontvangt met een 30 MB bijlage en die probeert door te sturen. Mag dat dan wel of gaat hier de uitgaande 25 MB limiet ook op?

[EnigmaNL]

Doorsturen is versturen en die limiet staat nog op 25MB dus dat gaat niet lukken.

[DarkSide]

Wat denk je zelf?
Limiet is op versturen. Hoe deze binnenkomt maakt niets uit.
Het is toch ook niet zo. als ik 4 mailtjes met bestanden van 10 mb binnenkrijg.
Dat ik ze dan wel als 1 mail mag versturen?

[pietje63]

Het proces is vaak anders, zeker als de grootte check plaatsvindt op het moment van toevoegen/uploaden. Zo gek is de vraag dus niet.

[DarkSide]

Meest kan je gewoon toevoegen wat je wilt. En krijg je pas een error als je gaat zenden

[loki504]

Ja maar stel ik verstuur iets van 30mb naar jou. En jij kan hem gewoon ontvangen(het is minder dan 50mb). Maar Nu stuur jij het zelfde mailtje naar door iemand. En zou dus over de 25mb komen. Theoretisch niet mogelijk gezien het limiet van 25. Maar misschien dat Google het wel toelaat omdat de oorspronkelijke bijlage niet van jou was. Al met al niet een hele rare vraag.

[Transferno]

Ik verwacht dat dan het standaard mechanisme in werking treed en de bijlage gewoon in de drive wordt gezet en een link wordt toegevoegd.

[Xellence]

Ik denk dat ik een vraag heb over hoe het proces verloopt wanneer je een mailtje binnen krijgt met een bijlage van groter dan 25 MB en deze probeert door te sturen of dan de 25 MB limiet voor dit mailtje ook geldt. Mijn vraag gaat over een enkele binnenkomende e-mail, meerdere losse e-mails als een enkele e-mail proberen door te sturen staan hier natuurlijk volledig los van.

[Perkouw]

Als je het zelf niet kan versturen, ook niet onderling?, dan zie ik het nut er niet zo van in behalve leuke gimmick. Grote bestanden versturen ben ik nu zo al gewend via andere wegen te doen diensten als DropBox e.d. dan wel WeTransfer.

Kon je het nu nog onderling naar elkaar sturen kon ik me nog wat indenken bij het versturen van foto's en zo. Die worden immers ook steeds groter, maar goed. Leuke gimmick.

[majic]

Zo...dat werd tijd. Super!

[Stranger__NL]

Mail 1.0 is inderdaad al jaren stuk.
- missende gegarandeerde afleveringen/ontvangstbevestiging
- missende track-and-trace
- missende geverifieerde eigenaars
- missende encryptie
- Spam

En voor alles is een oplossing voorhanden, maar nog niet netjes in 1 out-of-the-box outlook-applicatie zonder dat ik daarvoor door hoepels moet springen.

Ik wil best naar mail 2.0. Nu gebruik ik Whatsapp als ik een bevestiging wil hebben van aflevering en lees status.

[gekkie]

Niet iedere *ontvangende partij* wil altijd door jouw hoepeltje springen van een gegarandeerde aflevering en leesstatus.

Met Mail 1.0 is eigenlijk niet eens zo veel mis in mijn ogen, sterker nog het is zo verdomd flexibel dat het een van de weinige communicatie protocollen is op applicatie niveau dat we nog steeds zo massaal gebruiken. Daarnaast is het nog steeds niet gelukt voor partijen om een vendor-lockin te verzorgen al zouden ze dat ongetwijfeld het liefste willen.
Kom daar maar eens om in de IM scene.

[Stranger__NL]

Het gaat ook niet om jan-en-alleman. Het gaat om klanten en bijv om factuurverzendingen tussen 2 geverifieerde personen. En die zouden heel graag geverifieerde ontvangstbevestigingen willen. Ik snap dat jij je "blauwe vinkjes" van WA soms uit hebt staan, maar ik heb ze aanstaan. En mijn klanten vinden dat fijn. Ik zou dat ook voor mail willen.

Het feit dat mailtjes nu soms 'missing" gaan is niet fijn.
Ook het feit dat het lastig is (en lastiger wordt) om spam van echte mail te onderscheiden is zand in de email-motor.

Er is echt wel behoefte aan een mail 2.0. Maar zoals je zegt: het moet wel een flexibel open inzetbaar protocol blijven. Dat mag zeker niet aangetast worden nee.

[gekkie]

Als je klant dat wil, dan stuurt hij toch gewoon een bevestiging terug ?
(automatische garanties zijn namelijk wat dit betreft heel moeilijk te maken en derhalve "tot de voordeur", een echte garantie dat het gelezen is is het namelijk niet, kan nog steeds een client zijn die dat automagisch erop plakt zonder dat het volledig gelezen en begrepen is)

En als het dan toch niet gegarandeerd hoeft te zijn en het aan en uit moeten kunnen , wat belet je dan om momenteel samen met je klanten die dat willen toch gewoon gebruik maken van de ook in mail 1.0 beschikbare opties tot aflever en leesbevestigingen ?

[Zebby]

Product dat wij verkopen doet exact wat jij aangeeft, echter is dit momenteel een business oplossing en verkopen wij niet aan particulieren gezien er z.g.a. geen vraag naar is (niet gratis).
Het is in principe een cloud oplossing als Gmail, met Outlook plugin of API als additionele gebruiksmogelijkheden.

[Stranger__NL]

Maar het product moet dan wel door beide partijen gebruikt worden neem ik aan? Dat wordt lastig doorvoeren. Binnen 1 organisatie gaat dat nog wel werken. Maar eer dat ' de wereld' zover is moet het een geaccepteerde standaard worden.

[Zebby]

Ligt aan de gewenste oplossing. Je kan bestanden versturen en toelaten dat ze gedownload worden middels de link, zonder account. Dan kun je dus alleen bij het bestand met de URL, en staat het bestand encrypt op onze server. De veiligere variant vereist dat de ontvanger een account heeft/aanmaakt, en hiermee inlogt - dan kan alleen deze persoon erbij. Alle tekst staat ook encrypt opgeslagen, waarbij je kan kiezen of je tekst decrypt wilt meesturen of niet, en er is bounce/opening/zegel tracking. Nadeel is, het oogt allemaal nog wat ouderwets Hier gaan we wel mee aan de slag.

[Torrentus]

Wauw, dat ervaar ik toch wel heel anders dan jij;
Zo goed als alle taken die ik uitvoer op een dag komen per mail binnen of worden per mail gerapporteerd; alle bestellingen die ik doe worden per mail bevestigd, als ik een vraag heb aan een kennis die niet direct in mijn vriendengroep valt stuur ik een mail, etc etc etc.

[DonLexos]

Maar verstuur je dan ook (grote) bestanden mee? Kan toch veelal mail zijn met info over welke zaken er op network shares zijn geupdate of mogelijk in ander systeem zitten?

[rvt1]

Uit nieuwsgierigheid, wat voor zaken gaan nu 'anders' (ik heb geen iedee hoe anders is...), dus waar je vroeger email voor gebruikte gebruikt je nu wat voor andere service?

Update linked in -> email
Update basecamp -> email
Bestandje versturen -> email
Nieuwe freelance job -> email
Accountant communicatie -> email
website XYZ denk dat ik lid van ze moet worden -> email
Join seminar XYZ -> email
Uw bestelling is vertuurd -> email

zo kan ik nog wel even door gaan...

[DonLexos]

In de regel kan je dit ook gewoon uitzetten, dat is net wat je voorkeur heeft.

[rvt1]

Dat snap ik, maar mijn vraag is ook van mij aan Qinshi hoe hij dat nu anders oplost, immers heel veel zaken werken alleen met email, en RSS grotendeels een gepasseerd station. Iets anders zo ik nu niet echt actief worden, ja, je heb natuurlijk via het web momenteel notifications, maar dat is ook heel minimaal..

[Superkanjo]

Email is nog steeds groeiende, weet natuurlijk niet voor welke doeleinden.

http://www.radicati.com/w...019-Executive-Summary.pdf

[SampleUser]

In de open-source wereld wordt het nog veel gebruikt voor mailinglists.

[dakathefox]

Het aantal e-mails neemt hier alleen maar toe. Ik zit nu op gemiddeld zo'n 10.000 mails per jaar.

[Euronitwit]

Wat gebruik jij dan?
Ik Twitter, Whatsapp and Facebook niet.

[Fermion]

Vandaar dat het limit wordt verhoogd? Email gebruik ik voornamelijk zakelijk, privé ontvang ik voornamelijk van webshops te bevestiging van mijn aanschaf.

[Transferno]

Buiten werk zeg ik: Alles waarbij je een zekere orde wil waarborgen en een standaard wil gebruiken.
Voorbeeld:
- mails van de school van de kids
- mails van verenigingen
- mails van bedrijven
- etc

Waar ik het niet meer vaak voor gebruik is inderdaad het doorsturen van info of files tussen vrienden en familie. Die zitten vaak in een whatsapp of messengergroep en dan is dat een snellere manier.