Ciao Giulio. Potresti aprire i messaggi da browser e farmi sapere se da li i link sono accessibili? Ho studiato e sotto posto il tutto al service del servizio con il quale go avuto uno scambio rilevante di messaggi. Questo è il loro messaggio finale:

Buonasera,

In questo caso si tratta di qualcosa che può accadere con altri server di posta elettronica, poiché questi a volte non interpretano correttamente il contenuto dell'e-mail e possono limitare il reindirizzamento di alcuni link. Purtroppo non possiamo correggere questa situazione, in quanto deriva dall'interpretazione da parte di altri servizi postali.


Fammi sapere

Si, sul browser i link si vedono evidenziati e cliccabili.

Non c'azzecca nulla il server di posta elettronica. E' un problema di formattazione del messaggio.

La direttiva RCF-vattene-a-pesca dice chiaramente che o si mandano i messaggi in plain-text oppure in HTML. Gli ibridi non sono ammessi.
Racchiudendo i link in un anchor-element HTML (specificando anche l'href) il problema si risolve.

Soluzione ancora più facile: mandare tutto in plain-text come era prima, eliminando qualsiasi formattazione HTML. Tanto oramai tutti i client di posta riconoscono un link nel testo (anche se non è racchiuso fra parentesi angolate come imporrebbe l'RCF-vattene-a-pesca di cui sopra).

Io c ho capito solo RCF che mi ricorda gli altoparlanti delle guardie.

Dimostri padronanza dell'argomento. So bene che i link racchiusi nell href di html sono interpretati come indirizzamento verso la pagina stessa contenuta in esso.. Il che lo dimostra dal fatto che se apri le mail "incriminate" dal browser invece, sono regolarmente apribili.
Quindi, se il problema a quanto pare lo rilevi solo te si presuppone sia il tuo Client di posta elettronica che dal 1 novembre per qualche motivo ha smesso di interpretarle come si deve.anche perché il supporto esterno SMTP è iniziato prima del 1 novembre.

Non credo che il mio client Thunderbird abbia smesso di funzionare a dovere di punto in bianco. Vedo invece che il testo dei messaggi è cambiato di punto in bianco dal 1° Novembre in poi. Inoltre, tutti i messaggi "funzionanti" venivano per anni (dal 2015 in poi) da aruba.it, mentre dal 1° Novembre arrivano da un sito francese. Quindi c'é qualcosa che hanno cambiato i tizi a cui ti appoggi.

testo delle email fino al 1° Novembre:



Testo delle email dopo il 1° Novembre:




Esperimento: mi sono auto-mandato delle email di puro testo ed i link sono interpretati correttamente da parte di Mozilla-Thunderbird.

Comunque, dai. Mi tengo le email così ed amen...

Dimostrate entrambi assoluta conoscenza e padronanza della materia..... che ne dite di entrare in società? Vorrei spostare qualche milione di euro da alcuni conti bancari sul mio conto bancario.....
Se poi la cosa vi pare noiosa lasciamo perdere..... ma potremmo craccare il sistema di lancio missilistico degli USA, sai che divertimento

Giulio puoi fare qualche verifica

https://support.mozilla.org/it/kb/colle ... funzionano

Il problema a quanto pare lo hai solo te.....

Vedrò casomai in futuro di fare qualche variazione.
Un saluto

Ho controllato e ricontrollato (e ricontrollato ancora) le impostazioni di Thunderbird. Tutto ok.

Poi ripeto: per il mio lavoro ricevo giornalmente decine e decine di email di ogni tipo e da ogni angolo del mondo (Giappone e Cina inclusi), e da ogni tipo di soggetto. Persone, ditte e forum. I link funzionano tutti. In questo panorama internazionale le uniche email che non "funzionano" sono quelle da questo forum. Boh!

Comunque non è grave. Sopravviverò.

Io non ci capisco niente ma in ufficio anche noi con thunderbird abbiano problemi sui link.
Cisa che non mi capita con outlook e bluebird (che rimane il mio preferito)

Inviato dal mio GM1900 utilizzando Tapatalk

Non conosco bene le codifiche utilizzate per la formattazione del testo dai client di posta "intelligenti", ma quella usata nel messaggio postato da freno io non l'ho mai vista: un misto di tag HTML misti a "url encoding" ficcati anche anche nel testo normale, con il carattere "=" che prende il posto del carattere "%" (per non parlare degli "=" presenti prima degli a capo). Per esempio la URL richiamata nel testo di freno:

https://www.guzzistelvio.net/sito/forum/ ... e=3D363577

messa così com'è in un browser non funziona, non viene interpretata correttamente. Ma se sostituite il carattere "=" con il carattere "%" ottenete una URL corretta e funzionante:

https://www.guzzistelvio.net/sito/forum/ ... e%3D363577

che viene interpretata correttamente dal parser del browser e ridirezionata in HTTPS su:

viewtopic.php?f=4&t=13985&p=363577#p363577

Le triplette del tipo %nn (con n cifre esadecimali) sono caratteri "url encoded" come da tabella:

https://www.bettiolo.com/tools/Utilit%C ... +caratteri

La cosa strana e che caratteri "url encoded" (a meno dell' "=" al posto del "%" e degli "=" a fine riga) sono usati anche all'interno del semplice testo:

Ciao frenostanco,<br/><br/>ricevi questa notifica perche' stai controllando=
il forum =22All' =22Ermanno<br/>bar=22=22 su =22FORUM degli appassionati =
MOTO GUZZI STELVIO e della nuova MOTO<br/>GUZZI V85TT=22.

che dovrebbe essere:

Ciao frenostanco,<br/><br/>ricevi questa notifica perche' stai controllando
il forum %22All' %22Ermanno<br/>bar%22%22 su %22FORUM degli appassionati
MOTO GUZZI STELVIO e della nuova MOTO<br/>GUZZI V85TT%22.

che corrisponde a:

Ciao frenostanco,<br/><br/>ricevi questa notifica perche' stai controllando
il forum "All' "Ermanno<br/>bar"" su "FORUM degli appassionati
MOTO GUZZI STELVIO e della nuova MOTO<br/>GUZZI V85TT".

e che dovrebbe essere visualizzato così (con gli a capo corrispondenti ai tag HTML <br/>):

Ciao frenostanco,

ricevi questa notifica perche' stai controllando il forum "All' "Ermanno
bar"" su "FORUM degli appassionati MOTO GUZZI STELVIO e della nuova MOTO
GUZZI V85TT".

Adesso, i caratteri "url encoded" sono interpretati dal parser del browser e da particolari campi delle form, ma non mi risulta che siano resi in HTML nei corrispondenti caratteri ASCII. Adesso non so se esistano particolari standard di codifica ad uso dei client di posta, ma la formattazione del messaggio di freno mi sembra un pò strana. Non so bene nemmeno che ci facciano quegli "=" alla fine di tutte le righe, quasi fossero dei caratteri di a capo. Ma nel testo di freno i caratteri CR (carriage return) e LF (line feed) ci sono e sono quelli che fanno andare a capo la riga, come si può vedere editando in esadecimale il testo (allego immagine del testo in un editor esadecimale, i CR e LF sono gli esadecimali 0D e 0A verso la fine della quinta riga).



Non sono un grande esperto di roba web, forse ci sono delle regole per la gestione dei caratteri "=" ed "%" nell'encoding dei caratteri in esadecimale, però posso immaginare che un messaggio scritto a quel modo possa non funzionare sempre bene, oppure non essere interpretato al meglio da tutti i client.

Sto facendo delle prove con altro servizio.....Vediamo come va....Quando vuoi Freno dammi un feedback
Work in progress....

Esadecimale...che ricordi!!!

non si potrebbe bannare freno cosi abbiamo risolto?

@Bencio
per ora le notifiche mi continuano ad arrivare con la stessa formattazione. Appena cambia qualcosa ti informo.

@TopoPoldo
Mi sa che hai scovato il problema.

I link funzionano di nuovo!


Ecco come mi appare una notifica ora:



Ed ecco qua sotto i caratteri del messaggio. E' tutto testo puro:

Meno male... eravamo in ansia.

Inviato dal mio SM-G950F utilizzando Tapatalk

Vero eh?

Il problema è risolto e quindi non c'è bisogno di altro, ma a titolo di curiosità vi riporto la risposta che mi ha dato un collega più ferrato di me in materia, a cui oggi avevo rigirato il quesito. Il collega mi ha risposto che molto probabilmente il risultato che vede freno è dovuto ad un problema di encoding, che forse nel messaggio di partenza non è dichiarato, oppure non corrisponde esattamente a quello usato nel messaggio. L'encoding si vede nell'header del messaggio (su gmail per esempio si vede se si seleziona l'opzione "visualizza originale" nel menù a tendina in alto a destra).

Mi ha ribadito che i problemi legati alla corretta comprensione di cosa sia esattamente il processo di encoding, non sono banali e di immediata risoluzione; dipendono sia dai set di carattere, che dai sistemi su cui i messaggi sono elaborati. Soprattutto se si usano caratteri propri di lingue molto diverse su sistemi diversi (ovviamente se si usano solo le lettere dalla "a" alla "z" problemi non ce ne sono), si potrebbe arrivare anche a situazioni in cui non sia possibile visualizzare correttamente tutte le parti del messaggio (a meno che questo non sia codificato come "multipart" con il giusto encoding parte per parte, ed ogni parte abbia solo caratteri con un solo encoding).

Per esempio il mio client di posta IBM su Windows (che per l'Europa occidentale usa l'encoding "Windows-1252") a volte, specialmente in risposta a messaggi a loro volta originati su sistemi Unix (che generalmente invece usa l'encoding "UTF-8") o Apple (e quindi con un encoding ancora diverso), mi mostra un avviso di possibile conflitto di conversione del set di caratteri nel formato MIME (posta internet). Comunque di solito un risultato finale non ben formattato è una somma di contributi: il messaggio iniziale costruito in un modo non del tutto impeccabile dal sistema mittente (tipo con un header icompleto o non del tutto coerente con il contenuto del messaggio), seguito da manipolazioni non ottimali da parte dei server SMTP attraversati, con in ultimo il comportamento del client di posta che cerca (chi più chi meno) di rimettere a posto le cose. Ci sta che un diverso sistema di invio possa aver modificato il risultato che si osserva in ricezione.

@freno: dal tuo client puoi vedere se nell'header del messaggio (quello che non visualizzavi correttamente) l'encoding è dichiarato o no, e nel caso, quale sia? Se per caso non fosse dichiarato, ogni macchina che mette le mani sul messaggio proverà a capire da una porzione del messaggio stesso quale sia l'encoding più appropriato da utilizzare per manipolarlo, ed a volte questo, a causa di una scelta infelice, può anche scombinare tutto.

Ahahahaahahahhah
Vally non ti conosco ma ti trovo particolarmente in forma oggi! Darti al fai da te fa bene! :Chessyrin

Inviato dal mio K10000 Pro utilizzando Tapatalk

@TopastroPoldo

Messaggio correttamente visualizzato:



Messaggio non correttamente visualizzato:



Come avevo scritto, la spiegazione è tutta nell'RCF-vattene-a-pesca. In questo caso il documento è l'RFC 1341 - Sezione 5.1.
Alla pagina 15 puoi trovare la spiegazione agli strani segni di uguale ('=') e di altre anomailie disseminate nel testo.

Windows-1252 lo usava mio nonno quando Bill Gates aveva i calzoni corti (formato proprietario di Microsoft usato negli anni dal 1985 al 1992).
UTF è lo standard universale oggi. E' uno standard che permette la codifica di tutte le lingue (ovvero i caratteri/glifi) conosciute sul pianeta terra. E' uno standard internazionale ISO.
Lo standard windows-1252 codifica solo i caratteri latini e poca altra roba.

Info più dettagliate sulla struttura dei messaggi email la si può trovare nell'RCF-2046.

La discussione si fa interessante... Intendo nel senso informatico. Unix (Linux), IBM(Zos) ... Sono a casa mia...

Bando alla ciance così chiudiamo questo argomento poco motociclistico...
Freno come li vedi ora i link(senza tracciamento)?

Beh, praticamente avevi un messaggio HTML in Content-Transfer-Encoding "quoted-printable" interpretato (forse dal client per chissà quale motivo?) come semplice testo, che alla fine ti faceva vedere in chiaro tutte le codifiche...

P.S.
Chi l'ha detto che non è un argomento poco motociclistico? Adesso con il cruscotto collegato allo smartphone, gli sms al posto del contagiri, la playlist che si seleziona dallo stesso menù dei riding mode, alla fine discuteremo di quanta RAM ha la moto piuttosto che di quanta coppia...

L'avevo capito subito che era un problema di encoding prematurata con scappellamento a destra.... Ovvio

Aaaaaaa... Che sollievo!!!! [emoji3][emoji3]

Inviato dal mio Redmi Note 8 Pro utilizzando Tapatalk