E allora qui il problema del dmarc in se, il problema e dell'implementazione su Exchange... E vabbè quando si tratta d M$ non entro in merito...

Fidati :) Se fai una ricerca per problemi tra OOF di Exchange e il DMARC che li blocca troverai un bel po di segnalazioni purtroppo che cadono nel vuoto senza soluzione. So anche io che il DMARC controlla l'allineamento dell'SPF e/o del DKIM, anche io non so cosa centri, eppure parlano del fatto che il return-path è vuoto negli OOF. Diciamo che li ho implementati con poco supporto da parte del fornitore e mi sono dovuto fare una cultura personale, magari uno più ferrato saprebbe indicarmi la causa. Però vedi, queste situazioni poco chiare con un protocollo standardizzato non ci dovrebbero essere, mentre con standard "imposti" ci possono essere meccanismi non del tutto rodati su funzioni specifiche di un vendor.

non capisco la connessione con i messaggi OOF e dmarc. Dmarc è solo un modo per dire il tipo di allineamento che vuoi frà il domio e quello nel mail from nell'spf e dkim (nel caso del dkim si guard il campo d= contenuto nell'header con il parte cifrata). Ed entrambi i due, che mi risulti, non hanno niente a che fare con gli OOF o il return-path.

Usata per comunicazioni di media importanza provvederò a chiuderla presto. penso sia inammissibile un errore del genere nel 2023 e scusarsi solo con 2 righe e spammare ogni comunicazione sto ca*** di "da oltre 25 anni." c'è nettamente di meglio in giro.

Beh anche se è sempre il ramo informatico, sviluppatore, sysadmin, networker, dba, ecc.. sono lavori completamente diversi. Poi nelle realtà piccole poche persone fanno quasi tutto, nelle realtà gradi c'è molta settorializzazione delle figure IT. Cosi quando c'è un problema nelle realtà Enterprise, iniziano le guerre all'interno dell'IT per capire di chi sia la colpa di un malfunzionamento: Colpa del codice, no del server, no della rete, no del database, ecc...

Sul punto 1 molti usano i parametri meno restrittivi perchè appunto hanno paura che si ottenga l'effetto opposto. Ad esempio io ho un problema sul dmarc in reject che non riesco a far digerire agli altri sistemi i messaggi OOF perchè il return-path è vuoto. Dalle ricerche che ho fatto non ho trovato una soluzione. Per quello ho scritto che SPF, DKIM e DMARC mi sembrano solo delle pezze perchè sono macchinosi e complessi da gestire. Servirebbe una modifica all'SMTP per fare in modo che all'interno del protocollo ci sia un sistema di controllo del mittente gestito appunto dal protocollo, senza richiedere configurazioni e impostazioni disparate che rischiano di bloccare la posta e quindi si procede con i piedi di piombo ad implementarli.

mah... secondo me i problemi sono 2.
1) Adozione di standard condivisi da tutti. Personalmente penso che dkim, spf e dmarc, se correttamente configurati, aiutano parecchio. Il problema è che devi usare dei parametri restrittivi. Ad esempio, sul'spf, andrebbe usato il -all, mentre troppi domini ancora usano ?all o ~all. Come pure sul dmarc, si dovrebbero usare in produzione i parametri p=reject; adkim=s; aspf=s; Il problema è che molti non lo fanno, per semplicità o perchè usano servizi per invio di newletters etc, e configurano parametri più rilassati per comodità e poi non terminano l'hardening, lasciando il fianco agli spoofer.
2) Concentrazione sui grandi provider. Ormai google, microsoft e pochi altri si stanno spartendo il 90% degli MX, e fanno quello che gli pare e piace, senza guardare in faccia nessuno. Per cui, se comunque non usi i loro servizi, ti bannano a prescindere. Sopratutto Microsoft: capita speso ti mandi in blacklist senza che ci sia un reale motivo, solo perchè magari il tuo ip è nella stessa subnet di un altro che spamma. Poi il delisting è un problema perchè non hanno sistemi decenti per un controllo. Salvo poi loro hanno centinaia di account @outlook.com che spammano a destra e manca.

Però lo spam mortaccivostra funziona sempre alla grande....mai visto una casella mail attirare così tanto spam!!!!

Mi sa che facevano più bella figura a dire che era stato un attacco hacker.

ed il system admin cos'è?
Un idraulico? genio...

mancano gli hacker russi, è indecente dimenticarli

che c'entrano gli sviluppatori quando questo è un lavoro da system administrator?
Hai voluto fare il fico facendo questa lista e non sai neanche chi deve fare cosa!

tutta Italia

Mai sentita una problematica del genere

Però credo che sarebbe ora di rivedere l'SMTP, soprattutto per migliorare la sicurezza. Ok SPF, DKIM e DMARC ma non mi sembrano cosi infallibili, "basterebbe" riscrivere il protocollo per far si che non si possano mandare email con un determinato dominio se il server che le manda non è "gestito" da quel dominio. Non è possibile che con una semplice server SMTP si possano mandare email fake con una semplicità disarmante. Il DMARC aiuta, ma è troppo macchinoso.

Ho commentato ieri i miei dubbi e anche io sono curioso di che storage abbiano usato, soprattutto per il down totale quando il 25% poteva rimanere operativo visto che, a detta loro, era ancora sul vecchio sistema. Però, ci stavo pensando ora, Il 75% si riferisce alla percentuale degli account o all'occupazione del nuovo storage? Da come hanno scritto, hanno migrato il 75% degli account ma il valore di soglia è molto fumoso. Di cosa? IOPS, spazio occupato, ecc..? Va bene che può succedere di tutto, ma se mancava ancora il 25% da migrare credo che lo storage ne avesse ancora di spazio disponibile se no hanno cannato in pieno il dimensionamento e in quel caso, questo valore manda in blocco lo storage che, invece di proteggerlo, fa più danni?

Sembra tutto essere tornato alla normalità: 4 email ricevute, e tutte e 4 erano di spam. Funziona come prima.

Ma chi le usa ancora

provato ora, a me funziona

OT: perchè se provo a inviarmi una mail da gmail1 a gmail2 non vengono inviate e restano in "posta in uscita"?

Su numeri così grandi costa.
Durante il tempo di migrazione + test i dati cambiano (l'utente può ricevere, inoltrare e cancellare mail) quindi poi si deve fare una sincronizzazione che spesso è più complicata del "semplice" spostamento.

Probabilmente sarebbe costato anche fare la migrazione a blocchi o un account alla volta (automatizzando la procedura). Che è un'altro modo per fare il passaggio riducendo al minimo i disguidi.

in linea di massima comunque si possono settare i valori di timeout e retry. Comunque si, SMTP non è mai stato pensato come messaggistica istantanea, ma piuttosto per essere robusto.

appunto... capisco che 4 petabyte siano tantini, ma appunto solitamente si portano tutti i dati in copia, per vedere se funziona tutto, e poi, finiti i test si sincronizza il delta.

Storage con soglia al 75% ??? cos'era un Netapp ?

Questo lo sappiamo tutti, tranne loro. O fan finta.

Ma costava troppo :
- mantenere in piedi il vecchio sistema
- migrare tutti i dati al nuovo sistema e fare test
- portare gli utenti sul nuovo sistema

?
Dovrebbe essere l'abc degli sviluppatori, avere almeno 1 sistema sempre funzionante..

Beh, il protocollo smtp in realtà funziona così... se il server di destinazione risponde con un errore temporaneo, il client deve riprovare per un po' di tempo prima di dare forfait.
Diciamo che è una delle cose in cui l'email mostra di essere stata progettata un bel po' di tempo fa, quando la gente che mandava un'email non pensava di usarla come una messaggistica istantanea come facciamo oggi. Quindi il protocollo smtp è un po' carente da questo punto di vista.

Il server mittente le reinvia solo se riceve un messaggio di errore transiente (4xy), sarebbe da capire che risposte hanno dato i loro server, in ogni caso se anche avessero risposto di riprovare, nessun mail server credo che riprovi per giorni e giorni...

aaaa... quelle che ti hanno inviato durante il disservizio mi spiace per te, o te le rimandano o non ti arriveranno mai... dopo 24 ore in genere il server di invio se non riesce a recapitarle smette di recapitarle e le elimina avvisando l'utente che ha inviato la mail che non è stata recapitata... almeno cosi mi è successo alle mail che ho inviato a indirizzi in questa settimana, primo avviso non recapitato e tento nelle prossime 24 ore e altro avviso che il server non è riuscito a consegnarle saluti ed abbracci

In particolare, ciò che è accaduto è il raggiungimento di un determinato valore di soglia presente nel sistema operativo del fornitore dello spazio di archiviazione, il quale ha portato al blocco dell'accesso alla memoria, di conseguenza all'impossibilità di consultare la posta o di riceverne di nuova. Tale valore, stando a quanto riferito da Italiaonline, era del tutto sconosciuto e impossibile da tenere in considerazione, dal momento che era noto esclusivamente al produttore dello storage e non pubblicamente documentato

Sarà ma secondo me qualche testa salta... anche perchè mi sembra un errore da principianti sia da una parte che dall'altra

Migrato tutto su Gmail, ho una mail da 25 anni la terrò giusto di riserva

selezione naturale della specie

morissero

Attenderemo con ansia il report tecnico!

è vergognoso e basta, fare operazioni del genere senza mettersi ai ripari in caso di problemi, mah..e poi funzionante..nn mi pare cosi funzionante ad oggi..

ahahahah si quelle non mancano mai!!! ahahah

ma era un bug o una soglia non documentata?

A me sembra che non rinviare una email è una cosa normale perché dopo 3-5 ore di mancata consegna è giusto notificare al mittente il fallito recapito. Non mi sembra giusto lasciare un utente per 2 giorni convinto di avere inviato l'email e venirlo a sapere così tardi, come per esempio fa Gmail.

Così ho fatto e dopo uno scambio di email mi hanno aiutato e risolto il problema, ora posso entrare con nuova mail di registrazione e nuova pass.

Contatta direttamente l'amministrazione o la proprietà del sito in questione, identificati e spiega loro la tua situazione.

Dalle carte dei processi sono saltate fuori informazioni ben più importanti e scandalose di quelle che possono venire fuori qui e visto l'alto numero di persone coinvolte dubito fortemente che certe cose possano rimare sepolte in tribunale.

C'è un sito al quale mi sono registrata con libero, ora quel sito non riconosce più i miei dati, che so essere giusti. Non posso neppure tentare di recuperare o cambiare la pass, perché il link di recupero non arriva alla casella mail... Quindi io a quel sito non posso più accedere, e mi serve perché lì mi deve arrivare un importante documento...

Mannaggia, ho sbagliato! :(
https://uploads.disquscdn.c...

si anche io non voglio usare pop3 ma te l'ho scritto nel caso ti potesse servire come purtroppo non è stato...

io, a dire il vero, la migrazione l'avevo già cominciata qualche tempo fa ma è una cosa lunga, noiosa e non così semplice almeno nel mio caso...

Insomma:
1) il problema non è colpa loro ma del produttore (rigorosamente anonimo) che non ha documentato quello che avrebbe causato il problema.
2) Le mail non ricevute non sono colpa loro ma dei server dei mittenti che non le reinviano.

Uao

Eh ma non credo che lo potranno rendere pubblico. Penso che sta cosa di Libero altre i loro utenti imbestialiti, la stiano seguendo anche gli addetti ai lavori per sapere come "salvarsi" da un casino simile :D Pensa se venisse fuori che lo storage era del vendor PincoPalla senza capire meglio cosa sia successo, tutti gli IT inizieranno a chiedere fix, controlli, ecc.. e non fidarsi più di quel fornitore.

Che non verrà fatto nulla non ne sono sicuro, perchè se partono (e sicuramente partono!!) delle class action in tribunale non si ci possono presentare dicendo "S.O. aveva un bug"... Speriamo solo che queste info vengano trattare dalla stampa e non cada tutto del dimenticatoio perchè parlare dell'Iphone XX tira più click...