Newsgroup: it.comp.software.mailreader
Titolo: gmail e allegati spezzati

ciao
ho provato a mandare allegati corposi (5 mega) ad un amico con gmail per
fare un po' di prove
ma qualsiasi cosa sopra i 100K gli arriva ma quando prova a vederla viene
troncata.
ne avete già parlato?
[ag]

troncata.
Il massimo è 10 MB per ogni mail.
Jolan Tru
-- 
Filippo "Hytok" Simone - L'oracolo sampdoriano di Sunnydale
La Casa degli Elfi - 
http://www.freewebtown.com/lacasadeglielfi/
Enclave del Dominio - S.N.S. Despiser - 
http://ildominio.altervista.org/
Commissione Voyager - 
http://www.voyageritalia.com/

 Il massimo è 10 MB per ogni mail.
quindi 5 dovrebbero starci senza troncarsi nonappena superano i 100K.

 Il massimo è 10 MB per ogni mail.
ecco, questa è una grossa limitazione. Se è vero quindi che offrono 1 
Gbyte è vero anche che diventa difficilmente utilizzabile avendo 
questo limite. Vi sono ISP che offrono in Italia mail di quella 
capacità con un limite di invio nettamente maggiore, ecco, non sono 
gratis però :) Che facciamo?
-- 
Ciao, Dmitry
--
FREENET By X-Privat - 
http://www.x-privat.org/infofreenet.php

1) visualizzata (nonostante quello sia un allegato) 2) troncata.
Sicuro che tu o lui non abbiate filtri che ostacolino spedizione o
ricezione? Prova a spedirla da Gmail.com anche tu.


questo limite.
Facilmente aggirabile. Ieri ho inviato ad un amico un video di 220 MB
spittandolo con Hjsplit.


 ricezione? Prova a spedirla da Gmail.com anche tu.
potrei anche provare
ma io non ho alcun limite dall'indirizzo dal quale ho fatto quella prova,
avrei potuto madnare una mail da 100 mega, tempo e pazienza permettendo...
(cosa inutile! ^___^) ... e se il limite ce l'ha gmail, allora ecco svelato
l'arcano.
se devo usare anche io gmail apposta, allora c'č qualcosa che non va.
il problema č che l'allegato, a parte quando "apri l'e-mail" non viene
troncato, lui c'č, viene segnalato per la sua effettiva grandezza ... ma ,
supponiamo che io abbia inviato il file questo_file.zip da 10 mega con il
testo nel body "ciao amico, eccoti il mio file" ... lui quando apre la mail,
vede il testo del body, e subito i geroglifici corrispondenti
all'attachment, invece di vedere "questo_file.zip" segnato come attachment ,
magari con qualche opzione per scaricarlo o vederlo o ... agire su di lui.

 220 MB spittandolo con Hjsplit.
mettiti dalla parte del niubbio che dice: " caz*o con 1 gbyte di mail 
ho risolto tutti i miei problemi e ci mando anche i CD che 
masterizzo". Tu credi che questa tipologia di utenti sappia usare 
utility del genere? Oppure magari dicono: " non funziona" e mollano 
al secondo tentativo?


 gratis però :) Che facciamo?
cerchiamo di usare quel che ci è dato, cercando di capire come diavolo
funziona.
io per esempio mi accontento di quei 10 mega al colpo, ma se quando provo ad
inviarne la metà il destinatario li trova tutti troncati, mi pare che non ci
siamo.

 spittandolo con Hjsplit.
devo capire che diavolo c'č che non va,  allora.
domani gli faccio visita e vedremo :-)
ciao ciao

al secondo tentativo?
Hai ragione, i niubbi lasceranno perdere, ma pazienza, voglio dire, un
minimo di sniubbamento è richiesto per tutto, anche per fare una scansione
con l'antivirus.


 troncati, mi pare che non ci siamo.
ecco appunto


 devo capire che diavolo c'č che non va...
Potrebbe, /probabilmente/, verificarsi che...
Vedi <1416.1$zspace.it@rez> del 16/11 nel thread "Foxmail e Gmail".
-- 
Saluti
Renato
 

 Vedi <1416.1$zspace.it@rez> del 16/11 nel thread "Foxmail e Gmail".
Ma un MID cosě formato č valido? Mi parrebbe di no.
(Lo so, salvarmi da qualche parte le RFC non farebbe male). 
-- 
daRkSidE, 18/11/2004 12.42.26
[05/11 - Green] R.E.M.: World Leader Pretend

 (Lo so, salvarmi da qualche parte le RFC non farebbe male). 
rfc1036: Standard for Interchange of USENET Messages
2.1.5.  Message-ID
The "Message-ID" line gives the message a unique identifier.  The
Message-ID may not be reused during the lifetime of any previous
message with the same Message-ID.  (It is recommended that no
Message-ID be reused for at least two years.)  
Message-ID's have the syntax: <string not containing blank or ">">
In order to conform to RFC-822, the Message-ID must have the format:
<unique@full_domain_name>
Ecc. ecc.
Beh, il tuo 'uyh16cpyk905$.dlg@darkside.df' donde viene?  :)
-- 
Saluti
Renato
 

 format: <unique@full_domain_name>
di solito si usa usare una qualche combinazione di microtime, ovvero 
la data di creazione di Unix conteggiate in secondi più amenecoli 
vari ... 
-- 
Ciao, Dmitry
--
GIGAMAIL By X-Privat - 
http://www.x-privat.org/gigamail.php

 vari ... 
Infatti. Poiché la RFC propone 'The "Message-ID" line gives the message 
a unique identifier' ho adottato la combinazione *unique*: xxxx.y$ 
dominio.tld@account (indirizzo e-mail ribaltato rispetto alla chiocciola); 
'xxxx' è il giorno del millennio e 'y' il n. progressivo del messaggio.
Altrove uso l'Hash del messaggio: 'SHA-1@dominio' oppure il gruppo data-
orario, nel formato '20041118160725@dominio', come dici tu.
Tuttavia cerco di ridurre le dimensioni al minimo rispettando l'*unique* :)
-- 
Saluti
Renato
 

 <unique@full_domain_name>
rez sarebbe un full_domain_name?
-- 
daRkSidE, 18/11/2004 16.19.11
[02/15 - Freak Out!] Frank Zappa and the Mothers of Invention: I Ain't
Got No Heart

 rez sarebbe un full_domain_name?
Emh, no! :)  Ma il Message-ID almeno è 'unique'!  :))
E poi Robot Moderatore lo conosce e lo fa passare subito...  :))
-- 
Saluti
Renato
 

 rispettando l'*unique* :) 
si, sono tanti i metodi alla fine :)
-- 
Ciao, Dmitry
--
X-Privat "FREE Usenet" - 
http://www.newsserver.it

all'attachment
Questo tipo di errore non ha a che fare precisamente con Gmail, è capitato
diverse volte anche a me (con Tin, Tiscali e Fastweb), sia quando usavo OE
che ora che uso Pimmy, e non ho mai capito bene da cosa dipendesse, se dal
provider o dal client.


 E poi Robot Moderatore lo conosce e lo fa passare subito...  :))
Però non è cliccabile (almeno qui) e dunque non eseguibile.
Follow-up su: it.comp.software.newsreader
-- 
daRkSidE, 18/11/2004 19.52.32

 Jolan Tru
io definisco niubbo anche chi invia per email un video di 220mb pure se lo 
splitta 

splitta 
Spiegami perchč.


 Spiegami perchè.
Forse perché ci sono mezzi migliori e/o più comodi per inviare/scambiare
file di grosse dimensioni?
Bye
-- 
Al Kufr
Non bevo mai in servizio, piuttosto mi dimetto

 inviare/scambiare file di grosse dimensioni?
per queste cose c'č FTP, megio ancora sftp con SSH.


per queste cose c'è FTP, megio ancora sftp con SSH.
Ma non è facile trovare un server ftp che offra un giga di spazio, per
cui è ovvio che bene o male molti preferiscano questo metodo...
-- 
Ciao, Massimo | ICQ# 57669970 | Jabber: 
pet...@jabber.linux.it
- La bellezza salverà il mondo. -

 questo metodo... 
però imho è male. Stento a credere che non vi siano fornitori che 
diano un servizio del genere, ma se è così, credo sia dovuto ad una 
questione strettamente commerciale: manca la domanda. Difatto FTP è 
un protocollo poco conosciuto tra i newbie e invece chi sà, 
preferisci sftp o altro. FTP è un protocollo insicuro per 
definizione. Il fatto è che il mail system è alquanto più conosciuto 
e diffuso, imho.


diano un servizio del genere
Non ce ne sono. Se mi trovi un'alternativa valida, te ne sono grato.


file di grosse dimensioni?
So bene che ci sono icq, mirc e via dicendo, ma presuppongono che le due
persone siano online nello stesso momento. Please, non diamo del niubbo
alla gente alla maniera dell'evangelizzatore pazzo di questo NG.


persone siano online nello stesso momento.
Infatti. E poi che c'č di male a spedire 200 mega di e-mail a qualcuno che
sa di riceverli ed č tecnicamente in grado di farlo. E' normale - credo -
che con l'avanzare della banda larga e di caselle di posta sempre piů
ampie, si approfitti. Anni fa un'email non poteva essere piů di 1 mega
altrimenti ti uccidevano, ma oggi č frequente ricevere e-mail da 5-6 mega
(tipicamente con delle foto).
Ovviamente bisogna accordarsi con il destinatario della missiva...
altrimenti son ca**i :-)
-- 
-angelo-
www.geminisoft.com

Ovviamente bisogna accordarsi con il destinatario della missiva...
Ovviamente, č questione di buona educazione! Stesso discorso per le mail in
HTML. Invece non capisco come mai certe newsletter, che potrebbero
benissimo essere in solo testo, le facciano in HTML (le stesse Google
Alert!).


 alla gente alla maniera dell'evangelizzatore pazzo di questo NG.
Io non ti ho dato del newbie, sei tu che metti le mani avanti: io ho
solo fatto riferimento all'esistenza di metodi più comodi e/o migliori,
tra questi SMTP sta molto in basso nella classifica.
-- 
Al Kufr
La sapienza mi persegue, ma io sono piu' veloce

tra questi SMTP sta molto in basso nella classifica.
Me ne suggerisci uno? Te ne sarei grato.


HTML (le stesse Google Alert!).
AFAIK si possono avere in solo testo.
Ciao.
-- 
Antonio :-D

 Jolan Tru
te lo suggerisco io.
tralasciando la connessione diretta tra le 2 persone che e' la soluzione 
migliore si puo' fare l'upload del file su di uno spazio web
http://www.freewebspace.net/
gratuito o a pagamento e il destinatario se lo scarica in ftp quando gli fa 
comodo
altra soluzione masterizzare il file e spedire il cd. corriere o posta a 
scelta a seconda dell'importanza.
qualche considerazione :
se tutti e 2 avete il tempo di uploadare 220Mb se vi accordate sul momento 
ve le scaricate direttamente l'uno dall'altro, il tempo sara' lo stesso 
(anzi fate prima).
le mail con allegati quando vengono spedite ingrossano e di parecchio 
intasando le connessioni, poi non vi lamentate se non riuscite a collegarvi 
ad internet qualche volta oppure se la connessione e' lenta, succede anche 
perche' qualche buon tempone spedisce email da 220Mb
se tra l'smtp tuo e il pop del tuo destinatario c'e' qualche server 
configurato per rifiutare allegati grandi te lo perdi anche se il suo e il 
tuo li suppportano.
pure le poste rifiutano pacchi di peso superiore ai 30Kg per quelli devi 
usare i corrieri

tuo li suppportano.
In effetti questo pericolo c'è.
Ciao
-- 
-angelo-
Restiamo in contatto! Iscriviti alla nostra newsletter
www.geminisoft.com

AFAIK si possono avere in solo testo.
Non sapevo si potesse, visto che alla sottoscrizione le crea in HTML,
grazie!


questi ultimi.
Perle ai porci.


Quale incremento?
LoSmilzo si riferisce all'incremento legato alla codifica. Se usi BASE64 3
byte diventano 4 byte, quindi il file aumenta del 33% (spero di non aver
sbagliato altrimenti mi uccido).
Comunque per come la penso io: ognuno la propria banda (che paga) la usa
come vuole. Se i server vogliono vietare delle cose hanno solo da vietarle.
Una volta avvisato il destinatario dell'invio il problema non esiste.
-- 
-antonio-
www.geminisoft.com
(email valida sul mio sito)

 Perle ai porci.
che differenza c'e' nel darle alle donne ? 

mail.
:(


e si saturerebbe tutto.
La banda si satura in tanti modi, in particolare grazie alle reti p2p per
scaricare film, mp3, divx da 600MB tutto il giorno tutti i giorni.


ma che cos'e' un ping?
Un apostrofo roseo fra le parole "se' vivo?"
		-- Leonardò

 per scaricare film, mp3, divx da 600MB tutto il giorno tutti i giorni.
questo e' un altro discorso, la banda che viene saturata e' quella per cui 
si paga quindi se uno riesce ad usarla al 100% tanto di guadagnato per lui
se poi le linee non sono in grado di reggere il transito del traffico sta' 
al fornitore di accesso adeguarsi alle esigenze paganti dei suoi clienti.
Mentre invece penso che "intasare" la strada che porta al pop e al smtp con 
traffico anomalo sia "male"

traffico anomalo sia "male"
Banda è banda. Per fortuna ognuno può usarla come gli pare. Per me è molto
peggio il p2p dato che si usa in maggioranza per passarsi film pirata da
600MB.


e si saturerebbe tutto.
Questa preoccupazione per la banda, a mio giudizio, è un po' datata. Siamo
passati dai 56K a 1.2MB in circa 3 anni, la banda della rete è destinata ad
aumentare forse più di quanto sarà possibile sfruttarla.
Questo è il mio parere, ovviamente.
-- 
-angelo-
www.geminisoft.com

in un ufficio.
Naturalmente. Stavo ragionando senza tener conto dei vincoli in presenza
dei quali alcune soluzioni meno buone balzano in testa alla classifica :-)
Ciao
-- 
-angelo-
www.geminisoft.com

Una volta avvisato il destinatario dell'invio il problema non esiste.
Concordo. A me piange il cuore per principio (uno smilzo a 56k! ^__^), ma
poi sono cose che si fanno tranquillamente. La soluzione migliore è IMHO
quella di libero, mi pare, che rende l'allegato disponibile via web,
ovviamente non codificato ma "normale".
Ciao.
-- 
Antonio :-D

(invece yenc dovrebbe contenere di parecchio "l'ingrassamento").
Ancora esatto! yEnc viagga ad 8bit e codifica con due byte solo i byte 00,
gli accapo e il segno = usato come carattere speciale per codificare gli
altri caratteri. L'overhead č quindi variabile a seconda del file, pare
(googlando) sia in media del 3%.


ovviamente non codificato ma "normale".
Prima che ti risponda, Antonio: hai letto tutto il thread?


in un ufficio.
In ufficio si lavora! :-P
 :-))))))))))))))))))))))
Ciao.
-- 
Antonio :-D

Prima che ti risponda, Antonio: hai letto tutto il thread?
Quasi tutto, le polemiche si, e riguardo a quelle ciò che penso è che:
- dell'invio per email mi dispiace per l'overhead, non per l'uso della
banda. MA è solo uno spreco che IO non farei, non lo giudico uno spreco
se lo fanno gli altri, perché se TU lo fai avrai i tuoi buoni motivi.
- potendo userei altri mezzi per trasferire grossi file, compressioni
esotiche e quant'altro, ma se devo farlo lo faccio anch'io.
Quindi non giudicavo nulla, esprimevo solo come IO mi pongo davanti alla
tastiera, in un'immagine che pensavo fosse buffa, di questo smilzo che
inizia a usare rk per comprimere e sopperire all'ingrassamento di
uuencode. :-)
...ho schivato le polemiche? :-D
Ciao.
-- 
Antonio :-D

...ho schivato le polemiche? :-D
E chi parlava delle polemiche? Quel "quasi" spiega tutto: mi hai riproposto
una soluzione (via web) che ho già spiegato perchè mi è inutile ed
inapplicabile, quindi non hai letto tutto il thread.


dei quali alcune soluzioni meno buone balzano in testa alla classifica :-)
Impacchettati nelle intestazioni dei datagrammi IP? :-D
Ciao.
-- 
Antonio :-D

inapplicabile, quindi non hai letto tutto il thread.
Vedi sopra.
Distratto si, ma non così tanto! :-)
Ciao.
-- 
Antonio :-D

avevi parlato di impedimenti alla connessione contemporanea, se non erro.
Esatto.


E' una limitazione vera ma non mia, del mio "corrispondente".
Ok. Ora è chiaro.
Un'idea ce l'avrei. Digli di lavorare! :-)))
No, scherzo, oltre a tunnel ssl e htmp2pop3 non ho altre idee, al momento,
almeno applicabili su windows.
Ciao.
-- 
Antonio :-D

 chiedo)?
Sě. Per quanto riguarda FreePOPs (che č simile, presumo, a html2pop),
viene chiamato sulla porta 2000 e poi accede via http.
-- 
daRkSidE, 30/11/2004 18.15.20

viene chiamato sulla porta 2000 e poi accede via http.
Tnx!
-- 
Antonio :-D

viene chiamato sulla porta 2000 e poi accede via http.
A questo punto mi chiedo se non sarebbe possibile creare direttamente un
programma che vada su uno di quei siti che offrono dello spazio gratuito
e trasformi il file in oggetto in una e-mail da inviare al mailreader...
Uhm, troppo fantascientifico, eh?
-- 
Ciao, Massimo | ICQ# 57669970 | Jabber: 
pet...@jabber.linux.it
- La bellezza salverà il mondo. -

 e trasformi il file in oggetto in una e-mail da inviare al mailreader...
Ma questo non è troppo dissimile da quello che fa FreePOPs; voglio
dire, il testo che va a recuperare dalla webmail è già trasformato in
una email leggibile dal mailreader. Se uno avesse a disposizione un
computer sempre connesso, potrebbe anche con un semplice Hamster
scaricare dai vari POP e con FreePOPs, per poi permettere l'accesso
anche da remoto ad Hamster.
-- 
daRkSidE, 08/12/2004 18.32.22
[02/24 - The Best Of The Columbia Years 1943-1952 (Disc 2)] Frank
Sinatra: Full Moon And Empty Arms