la 25 confermo che è filtrata.
Porta SMTP in uscita con ILIAD
Grazie Daniel.
Facendo qualche prova più approfondita noto:
lft -d 25 gmail-smtp-in.l.google.com
traceroute to gmail-smtp-in.l.google.com (142.251.5.26), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 1.569 ms 2.725 ms
2 * *
3 * *
4 * *
5 * *
6 * *
7 * *
8 * *
9 * *
10 * *
Se dovessi basarmi su quello che vedo dovrei pensare che la IliadBox sia la colpevole.
- Modificato
simonebortolin La porta 465
1) è deprecata
2) è per SMTP su SSL
la porta corretta sarebbe la 587 con SMTP su TLSFrenceFrencedere simonebortolin ho letto oggi che la 465 è deprecata, grazie per l'informazione.
Scusate il piccolissimo offtopic, ma potreste citare le fonti per questa deprecazione? Perché a me risulta esattamente il contrario, ovvero che sebbene le prime RFC raccomandassero STARTTLS (opportunistico) su porte 110/143/587 (pop3, imap, smtp-submission), visto che poi nella real-life lo standard è diventato implicit TLS su porte dedicate 995/993/465, la rfc8314 del 2018 dovrebbero aver raccomandato di usare implicit TLS sulle porte dedicate in virtù di una maggiore standardizzazione e dell'eliminazione completa di comunicazioni in plain-text:
http://www.rfc-editor.org/rfc/rfc8314#page-5
Previous standards for the use of email protocols with TLS used the
STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With
STARTTLS, the client establishes a cleartext application session and
determines whether to issue a STARTTLS command based on server
capabilities and client configuration. If the client issues a
STARTTLS command, a TLS handshake follows that can upgrade the
connection. Although this mechanism has been deployed, an alternate
mechanism where TLS is negotiated immediately at connection start on
a separate port (referred to in this document as "Implicit TLS") has
been deployed more successfully. To encourage more widespread use of
TLS and to also encourage greater consistency regarding how TLS is
used, this specification now recommends the use of Implicit TLS for
POP, IMAP, SMTP Submission, and all other protocols used between an
MUA and an MSP.
lore20 La porta 465 non è più assegnata a smtp dal 1998 tipo.... Come parla nella sezione
7.3. della RFC8314 (che è comunque proposta e modificata dalla rfc8997).
Nonostante secondo le rfc è da usare usare una porta deprecata ed assegnata ad altro da un ente che non ne ha l'autorità(?) attualmente mi risulta molto maggiore l'uso della 587 e che l'eliminazione del plain text è ancora molto lontano.
Attualmente credo che l'uso real-life sia molto ma molto incentrato sulla 587, come dimostra anche una breve ricerca su google che da sempre 587 come preferita eccetto su serverfault dove trovi commenti molto diversi.
[cancellato]
simonebortolin modificata dalla rfc8997
Questa depreca solo TLS 1.1. È un po' un ciclo... prima i client che supportavano STARTTLS erano meno di quelli che supportavano la connessione TLS diretta, e alcuni non supportavano alcuna cifratura, ma questo richiedeva due porte per le connessioni cifrate e non. Ad utilizzare la 25 poi non si poteva vietare l'autenticazione su quest'ultima per il relay, aumentando i tentativi di bruteforcing senza cifratura (che scala di più).
Così si è pensato di usare una porta unica separata per i client (il delivery server-to-server rimane sulla 25, ma si accetta solo la posta per i domini locali) sia in chiaro che non. Poi però ci si è accorti che alla fine è meglio instaurare la connessione TLS direttamente... così ci sono server che usano sia la 465 con TLS obbligatorio, e la 587 con STARTTLS. Basta che un giorno si decidano...
[cancellato] Basta che un giorno si decidano...
Non succederà mai...
francesco2022 Ho attivato oggi fibra iliad e la posta in uscita (avevo la porta 25 non crittografata) ha smesso di funzionare. E' ripartita utilizzando la porta 465 con TLS.
Non c'è nessun motivo tecnico (spama compreso) per tenere la porta 25 in uscita chiusa.
A mio avviso è un errore grossolano in quanto anche free (da cui hanno copiato le configurazione) ha la porta chiusa ma via pagina web di gestione il cliente può con un click riabilitarla.
Prova ad aprire un ticket.
Avendo un server di posta a casa, confermo, dopo un mese di telefonate con operatrici molto gentili e livello tecnico imbarazzante, che Iliad ha la porta 25 chiusa "per motivi di sicurezza". Questa è stata la risposta seguita a precisa domanda inviata via PEC, dopo che al telefono mi sono sentita rispondere da cosiddetti tecnici cose molto fantasiose: "chieda al suo provider", "non siamo una ditta informatica", eccetera eccetera.
Qualcuno per caso ha informazioni o esperienze diverse?
barbaran4w giusto per snoffare:
A.chieda al suo provider
B. Ma siete voi il mio provider
A. perfetto allora sappiamo già tutto.
La chiusura della porta in uscita non può essere legata a un motivo di sicurezza.
E' un errore e non vogliono ammetterlo.
Santo Levi.... e non dico altro
[cancellato]
Blocca gli spambot che non possono funzionare. Magari avranno avuto il loro problemi perché linee con un upload elevato sono comunque un buon target per i bot. Se blocchi la sola 25 in entrata blocchi solo i mail server locali ma non l'invio, se la blocchi in uscita puoi anche avere un mail server locale, che però non potrà mai inviare, come i bot.
aggiornamenti
ecco qui la risposta via PEC appena ricevuta:
Gentile Utente,
come da conversazione telefonica intercorsa, Iliad Italia S.p.A. (“Iliad” o la “Società”) è a confermare l’assegnazione dell’IP full stack xx.xx.xx.xx sulla linea xxxxxxx a Lei intestata; Iliad Le suggerisce di mettersi in contatto con il Suo provider di dominio per richiedere il reverse DNS.
La Società è altresì a confermare che, per ragioni di sicurezza informatica e antifrode, Iliad non può procedere con l’abilitazione della porta 25, pertanto la Sua richiesta non può essere accolta.
Alla luce di quanto sopra, la Società è a comunicare il rigetto del reclamo xxxxx, aperto a seguito della sua richiesta a mezzo PEC.
Cordiali saluti,
Iliad Italia S.p.A.
Glielo spiegate voi che sono loro il mio provider?
- Modificato
barbaran4w prova a farglielo spiegare dal conciliatore tramite conciliaweb, però poco ma sicuro non otterrai mai l'apertura di quella porta
francesco2022
La 25 spesso si tende a bloccarla anche in uscita per evitare che venga utilizzata come veicolo massivo di spam verso altri server su connessione non sicura.
Si tende a tenere aperte la 587 e la 465 perché intrinsecamente più sicure.
Ho letto che usi dispositivi IoT, per come la vedo io, dovrebbero essere loro ad essere aggiornati a non usare più una porta oramai considerata estremamente insicura.
Pensaci, è un po' come la HTTP su porta 80, quale sito la utilizza ormai? A meno di siti amatoriali, sono tutti in HTTPS 443.
In ogni caso, per provare a risolverti il problema: guarda il contratto cosa dice, se c'è scritto che non bloccano niente puoi farlo presente all'assistenza, magari anche via PEC e come ultimo step, provare con Conciliaweb.
[cancellato]
- Modificato
quantum-pipe verso altri server su connessione non sicura.
Si tende a tenere aperte la 587 e la 465 perché intrinsecamente più sicure.
Il problema in realtà è che i server mail devono accettare connessioni non autenticate sulla 25 - perché così è che i server trasferiscono la posta tra di loro. Questo però fa sì che chiunque si può connettere alla porta 25 di un qualsiasi server mail e inviare posta alle mailbox di quel server. Poi anche sulla 25 si può usare STARTTLS per inviare i dati su una connessione crittografata, e anzi si può richiederlo usando MTA-STS (purché il server dall'altra parte lo usi, rimane il problema che non c'è una vera validazione dei certificati).
Sulla 25 si deve accettare posta solo per i domini locali per evitare di fare da open relay, ma questo non ferma lo spam destinato localmente - a meno ovviamente di non usare una batteria di filtri per tentare di limitarlo.
Sulle porte 465 e 587, poiché sono usate solo dalle connessione client-server e non server-server è possibile imporre l'autenticazione per inviare email, così che il server non è aperto a dogs+pigs. Su queste porte si accetta solo mail da mailbox locali verso destinazioni locali o remote. Questo traffico è anche crittografato, ma non è il solo motivo per usare porte diverse.
La questione sicurezza/antifrode è una scusa bella e buona.
Inoltre nel contratto iliad non fa presente questa situazione.