maximum grootte email attachement

[legolas82]

Ik ben op zoek naar informatie over een (eventueel) technisch maximale grootte voor een emailbijlage (dus niet provider-afhankelijk)
Ik moet dit weten ivm mijn scriptie over computercriminaliteit om commentaar te leveren op een stelling die onze minister aanneemt in zijn Memorie van Toelichting. Het handelt over de grens tussen spam en het nieuwe artikel 138b WvSr (belemmeren geautomatiseerd werk)
Spam an sich valt hier niet onder, maar indien het een dusdanig grote email is, kan het wel onder de werking van artikel 138b vallen.
GoT, Wiki en google leveren niets op... sommige providers hanteren 50 mb, universiteit Groningen 100 mb.
En als potentiele verdachte zelf een emailserver heeft, kan er toch nog gesproken worden over een maximum?

[Krypt]

Staat zoiets niet in het RFC van het SMTP protocol?

[edit]
Zoals wica hieronder al zegt.. volgens 't RFC is het oneindig. Er wordt zelfs geadviseerd om geen limiet in te stellen.

message content
The maximum total length of a message content (including any
message headers as well as the message body) MUST BE at least 64K
octets. Since the introduction of Internet standards for
multimedia mail [12], message lengths on the Internet have grown
dramatically, and message size restrictions should be avoided if
at all possible. SMTP server systems that must impose
restrictions SHOULD implement the "SIZE" service extension [18],
and SMTP client systems that will send large messages SHOULD
utilize it when possible.

_bron

[ Voor 88% gewijzigd door Krypt op 15-08-2006 16:39 ]

[wica]

Volgens de RFC maakt het niet uit.
Maar een max van 10MB is adviseerbaar. En sommige snmp server accepteren maar 2MB.

[barfieldmv]

De maximale grootte van een email bericht in informatie is zogoed als oneindig. In elk email berichtkan zoveel informatie staan dat de grootte van het bericht er absoluut niet meer toe doet.

Emails kunnen applicaties bevatten en linkjes naar alle informatie op het internet.

Voor gewoon dagelijks persoonlijk en professioneel email gebruik is 1mb als maximum verstandig, heel veel ontvangers willen of kunnen niet meer ontvangen.

[Verwijderd]

De enige beperkende factor die ik kan bedenken is de software op de mailserver. Deze zou een limiet kunnen stellen, voor de rest wordt de attachment opgedeeld in hapklare pakketjes en verstuurd, dus dat geeft geen beperking.

[PipoDeClown]

legolas82 schreef op dinsdag 15 augustus 2006 @ 16:27:
GoT, Wiki en google leveren niets op... sommige providers hanteren 50 mb, universiteit Groningen 100 mb.

in dat geval moet je toch echt iets doen aan je vraagstelling. meer info enzo.
je kunt iig al een lijstje maken met technische beperkingen die je wel eenvoudig te weten kunt komen als: maximale grootte bestand op een bestandssysteem, beperking van het emailprogramma, etc etc

[legolas82]

dus puur theoretisch is het mogelijk om een email met een bijlage van 30 GB te versturen die ook ontvangen zal worden door een gebruiker?

edit: reactie op pipo.
Ik snap je.. emailprogramma's zullen het niet trekken, maar het gaat om de theorie om op zo'n manier de haalbaarheid (of onhaalbaarheid) te toetsen van zo'n artikel. Als het namelijk theoretisch al niet mogelijk is, is dat praktisch ook niet haalbaar

[ Voor 50% gewijzigd door legolas82 op 15-08-2006 16:42 ]

[Mizitras]

Technisch gezien is de grootste attachement bepaald volgens:

ALS ((Grootte attachement + grootte bericht) kleiner zijn dan toegelaten groottes verzender ISP EN ontvanger ISP) EN ( grootte/snelheid-traagste-verbindingen is kleiner dan de tijd dat de servers/routeringsstationnen sessies toelaten) DAN
verzenden e-mail (met attachement erin) en tot punt van ontvangen


Zoiets?

[Remy]

theoretisch, sure: in de praktijk: 30 GB, weet je zeker dat iemand uberhaupt genoeg schijfruimte heeft voor 30GB, laat staan dat een mailserver dat accepteert danwel mailaccount dat aankan? :)\

Als het gaat om technische max: FAT32 kan bestanden tot 4GB aan: geen idee hoe dit zit bij NTFS en de Linux-FS'en

[Wolfboy]

Ja, theoretisch zeker.

In de praktijk zal het alleen niet lukken doordat
• de mailserver het niet accepteerd (al dan niet door ingestelde limieten)
• de mailserver te weinig schijfruimte heeft
• de mailclient crasht door de grootte

[legolas82]

het hoeft ook niet helemaal ontvangen te worden. Er hoeft slecht te worden aangetoond dat normaal gebruik van het geautomatiseerde systeem niet meer mogelijk is. In zo'n geval (dus als bijvoorbeeld outlook begint met binnenhalen van een inmense mail) valt het onder 138b en anders onder spam

@ wolfboy: dat geldt dus ook voor een zelf gemaakt mailserver (dus software-restrictie)?

[ Voor 13% gewijzigd door legolas82 op 15-08-2006 16:44 ]

[Mizitras]

@Wolfboy

off-topic: So, leuke avatar.

[DataGhost]

legolas82 schreef op dinsdag 15 augustus 2006 @ 16:39:
dus puur theoretisch is het mogelijk om een email met een bijlage van 30 GB te versturen die ook ontvangen zal worden door een gebruiker?

edit: reactie op pipo.
Ik snap je.. emailprogramma's zullen het niet trekken, maar het gaat om de theorie om op zo'n manier de haalbaarheid (of onhaalbaarheid) te toetsen van zo'n artikel. Als het namelijk theoretisch al niet mogelijk is, is dat praktisch ook niet haalbaar

afhankelijk van de implementatie (wordt het direct gedecodeerd of wordt het eerst volledig in het RAM-geheugen geladen?), de serverhardware en het gebruikte bestandssysteem (en quota-instellingen, ik kan me voorstellen dat je op een server met veel gebruikers geen 30GB gaat toestaan omdat je dan *eigenlijk* 30GB x aantal gebruikers in je server moet hebben, en dat een dure grap kan worden) zou ik zeggen: ja dat kan
edit: laat

edit2:
edit3: dat was stom, verkeerde topic

[ Voor 50% gewijzigd door DataGhost op 15-08-2006 17:05 ]

[Krypt]

Wie zegt dat ie het op moet slaan.. het gaat om ontvangen..
Dus TCP receiveWindow vol... flush TCP receiveWindow en weer verder..

Maar goed.. als je wilt weten of het theoretisch kan, dan mag je daar geen andere restricties aan leggen.. volgens de specificatie kan het, dus het is mogelijk.. dat er andere belemmeringen zijn, tja.. dat wil je niet weten. En als je het wel wilt weten, dan wil je dus niet weten of het theoretisch mogelijk is, maar of het in praktijk ook mogelijk is..

Making any sense

[ Voor 88% gewijzigd door Krypt op 15-08-2006 16:49 ]

[legolas82]

Krypt schreef op dinsdag 15 augustus 2006 @ 16:47:
Wie zegt dat ie het op moet slaan.. het gaat om ontvangen..
Dus TCP receiveWindow vol... flush TCP receiveWindow en weer verder..

Maar goed.. als je wilt weten of het theoretisch kan, dan mag je daar geen andere restricties aan leggen.. volgens de specificatie kan het, dus het is mogelijk.. dat er andere belemmeringen zijn, tja.. dat wil je niet weten. En als je het wel wilt weten, dan wil je dus niet weten of het theoretisch mogelijk is, maar of het in praktijk ook mogelijk is..

Making any sense

gek genoeg.. ja, you're making any sense.. all of you .

thx... ik kan weer stukje verder..

[CyBeR]

Krypt schreef op dinsdag 15 augustus 2006 @ 16:47:
Wie zegt dat ie het op moet slaan.. het gaat om ontvangen..
Dus TCP receiveWindow vol... flush TCP receiveWindow en weer verder..

Zo werken mail servers niet. Die ontvangen je bericht, slaan 't op op schijf in hun queue en die queue wordt op een gegeven moment afgewerkt.

[Krypt]

Dat weet ik, maar hier wordt gevraagd naar de theoretische grote van een mail die verstuurd kan worden... Dan is het opslaag ervan in de queue helemaal niet aan de orde, en moet je die restrictie ook niet meenemen (daarom heb ik die situatie geschetst).

Het gaat om de restrictie van het SMTP protocol en die bestaat niet. Het is dus wat de TS wilt weten: theoretisch limiet, of in praktijk..

[ Voor 9% gewijzigd door Krypt op 15-08-2006 17:10 ]