Ma all’interno del file XML fattura che hai ricevuto, il fornitore ha valorizzato la tua PEC (quella lì che si vede in parte oscurata: amministrazione@pec… )?
oppure lo SDI di sua iniziativa ha inviato a quell’indirizzo PEC ancorchè il fornitore non aveva valorizzato il campo 1.1.6 PECDestinatario?
Volevo comunque auto-confermarmi e confermarvi che le fatture inviate allo SDI e contenenti sia CodiceDestinatario (diverso da 0000000 e XXXXXXX) che PECDestinatario valorizzato vengono correttamente inviate e otteniamo ricevute di consegna.
2 Mi Piace
beh! questo è il minimo sindacale 
Forse dipende dal fatto che in questi giorni circolano tante fakenews sul sistema SDI che non funzionerebbe ma come ho avuto già modo di dire queste disfunzioni dipendono da portali privati accreditati che non stanno operando correttamente e che fanno credere a tanti operatori (e anche ai media che sono usciti con certi titoloni sui giornali! ) che il problema sia addebitabile alla Sogei 
In realtà l’ho scritto perchè originariamente esisteva il controllo 00426 dove sembrava non fosse possibile valorizzarli entrambi. Controllo “svanito” nelle ultime versioni della documentazione
2 Mi Piace
Ciao a tutti, una domanda forse “offtopic”…
Qualcuno di voi ha implementato una controllo sulla validità di un indirizzo email di tipo PEC ovvero se il dominio di posta (@legalmail.it , @pec.it, etc…) è di tipo PEC ???
1 Mi Piace
Qualcuno di voi ha implementato una controllo sulla validità di un indirizzo email di tipo PEC
“Ahi, ahi, ahi che peccato, mi è caduto sulla PEC signor @Lucio_Landi”
La PEC esiste per la verifica, e deve rispondere in accettazione con la notifica XML, per cui è vero il contrario:
non esiste modo di essere certi di una mail NON PEC,
Esistono dei registri/elenchi con tutti i domini di secondo livello PEC ?
Sul sito https://www.agid.gov.it/it/piattaforme/posta-elettronica-certificata/elenco-gestori-pec
c’è l’elenco dei gestori ma niente in merito ai domini “gestiti”
1 Mi Piace
Esiste una directory LDAP, prevista dalla specifica PEC RFC 6109 sez. 4.5. e gestita da DigitPA che contiene tale elenco, ma è accessibile solo ai gestori PEC accreditati. Ogni gestore PEC aggiorna quotidianamente tale directory, esponendo un file LDIF ad un certo URL, a piacere ma non noto, con i propri domini gestiti, e scarica una copia cache locale del resto della directory. Ciò non esclude la possibilità che un gestore conceda in virtù di un accordo l’accesso a tale database alle software house che ne necessitano. Ti ricordo poi i database INI-PEC e Registro Imprese, che contengono gli indirizzi PEC comunicati dai contribuenti (sicuramente validi al momento della comunicazione in quanto vengono verificati tramite invio di un messaggio, ma senza nulla dire riguardo alla validità nel momento in cui effettui la ricerca).
Fatta questa premessa, puoi determinare se un dominio può ricevere messaggi PEC verificando nei record DNS se esiste un record MX che risolve verso (un indirizzo IP corrispondente all’hostname di) un server SMTP di uno dei gestori accreditati presenti nell’elenco che hai linkato. I nomi dei server MX dei gestori accreditati sono dichiarati nel Manuale Operativo che ogni gestore pubblica sul proprio sito web (ai sensi del DPR 68/05). L’interrogazione dei record DNS e le risoluzioni IP ↔ hostname sono operazioni standard.
Inoltre puoi risolvere, solo parzialmente, ma in totale autonomia, il problema della verifica dell’esistenza di un indirizzo PEC (o mail ordinaria). Più precisamente, è possibile scrivere una funzione che, dato un indirizzo e-mail, ci dice se, nel momento della verifica:
- sicuramente non è valido;
- non si può sapere se è valido o no.
Per il caso 1), si può affermare che un indirizzo sicuramente non esiste:
- se il dominio non presenta alcun record DNS di tipo MX;
- se collegandosi al server SMTP indicato dal record MX presente, inviando il comando RCPT TO si ottiene risposta negativa (550).
Con questa tecnica è possibile soltanto stabilire se un indirizzo sicuramente non esiste, ma non il contrario, perché alcuni server SMTP sono configurati per rispondere sempre positivamente (250) al comando RCPT TO, anche qualora l’indirizzo non esista, scelta operata da alcuni sysadmin per contrastare lo spam o per implementare caselle e-mail catch-all (NB: non esistono PEC catch-all).
Nel tuo caso, è possibile verificare se un dominio può ricevere posta PEC, mentre per la verifica della validità di un indirizzo PEC, pur non potendo implementare una verifica precisa in tutti i casi, puoi comunque intercettare alcuni indirizzi sicuramente sbagliati.
L’ho implementato per alcuni siti web e software che gestisco.
1 Mi Piace
Grazie 
Poi qualcuno mi spiegherà perché in un epoca di “opendata” di opti per non rendere pubblici questi dati… bahhhhh
Ciao @Lucio_Landi
già quel poco che abbiamo è stato oggetto di interpelli al Garante Privacy perchè per alcune associazioni gestiamo già di più di quello che dovremmo.
Poi questa benedetta PEC, gli mandi una mail con subject “verifica PEC” se dopo 5 minuti NON ricevi nulla è farlocca, ma se e’ valida entro 2 o 3 minuti ti arriva la notifica di accettazione con la response in XML.
Per cui la verifica non è online ma almeno è automatizzata con una indeterminazione di pochi minuti.
Per le e-mail NON PEC si fa come si è sempre fatto, si invia la mail di verifica con il backlink.
Ottimismo 
Notifica di consegna (o mancata consegna).
si OK per essere paranoici si può aspettare anche la notifica di consegna, mi già quella di accettazione è sinonimo di casella esistente. magari invece di attendere 5 attendi 10 min…
No, la notifica di accettazione è inviata dal tuo gestore per confermare la presa in carico del messaggio e la sua validità sintattica e formale. L’equivalente della ricevuta che ti da la posta se spedisci una raccomandata. Non dice nulla riguardo all’esistenza della casella.
1 Mi Piace
Grazie, hai ragione, in effetti la ia verifica era bacata, non mi sono mai accorto perchè per puro caso il 100% dei miei test dopo l’accettazizone era sempre giusta.
Ti devo un 
1 Mi Piace
Buongiorno, sapete se quanto descritto è ancora valido, oppure se invece il controllo 00426 è stato riattivato, nel frattempo?
Cordialità
Non credo che il 00426 sia stato riattivato o quanto meno non avrebbe senso riattivarlo.
obbligherebbe ad emettere fatture con un codice destinatario o con pec
1.1.6 <PECDestinatario> valorizzato a fronte di 1.1.4 <Codice Destinatario> con valore diverso da 0000000
specie perchè partita IVA non vuol dire possedere una PEC.
Un regime forfettario ad esempio potrebbe non avere un codice SDI o la PEC dato che non l’obbligo di averli. Darebbe errore continuo.
Da quanto vedo, ogni mese inoltriamo qualche migliaio di fatture senza PEC e CodSdi 0000000
1 Mi Piace
Grazie. Abbiamo fatto delle prove e l’errore effettivamente non si presenta. All’AdE dovrebbero aggiornare il documento (V1.7) dove vengono descritti gli errori…