30 Dic 2014

Viva gli standard aka Quando la Mela è bacata!

Dal 12 dicembre 2014 i server mail degli indirizzi email forniti da Apple (@icloud.com, @mac.com, @me.com) hanno cominciato a rifiutare svariate email.

Dopo qualche test ho verificato che l'errore era il seguente:

550 5.7.1 Success delivery receipts not accepted: emailaddress@domain

Fatte un po' di ricerche su Google non ho trovato informazioni e quindi mi sono messo a fare prove per scoprire che i mail server di Apple forniscono quell'errore in risposta al comando RCPT TO nel caso venga passato l'attributo NOTIFY con un valore che contenga il valore SUCCESS.

Apple mail server bugs

Ma che cosa è l'attributo NOTIFY e a cosa serve?

L'attributo NOTIFY passato come parametro del comando RCPT è stato introdotto con l'estensione DSN del protocollo SMTP (vedi RFC3471) e permette ad un client che si connette ad un server che supporta tale estensione (e la dichiara quindi durante la connessione) di specificare in quali condizioni si vuole ricevere un Bounce (DSN) per l'email in questione. In particolare l'estensione permette quindi di stabilire se non si vogliono bounce (NEVER), se li si vogliono solo per i FAILURE oppure per i DELAY o anche per i SUCCESS. Quindi è possibile chiedere ad un server di creare un bounce anche per consegne avvenute con successo.

Perchè Apple ha deciso di non supportare NOTIFY=SUCCESS?

Probabilmente perchè genera parecchio traffico in uscita: per ogni email inviata ad apple usando questa configurazione, Apple deve inviare una email al mittente per dire che la prima email è stata consegnata con successo.

E' un diritto di Apple configurare i suoi mail server in quel modo?

Sì, tecnicamente uno può fare ciò che vuole con i propri server, ma NO, in quanto le specifiche del protocollo SMTP sono chiare e non permettono il nuovo comportamento dei mail server di Apple che comportandosi in questo modo sono dei cattivi cittadini di internet e se ne fregano delle specifiche che tutti gli altri rispettano da decenni.

Apple può decidere se supportare l'intera estensione DSN: se decide di NON supportarla allora è sufficiente che durante la connessione non dichiari di supportarla, ma se decide di dichiarare di supportare l'estensione DSN (come fa) allora deve supportarla secondo le specifiche.

telnet mx1.mail.icloud.com 25
Trying 17.158.8.67...
Connected to mx1.mail.icloud.com.
Escape character is '^]'.
220 nk11p00mm-smtpin010.mac.com -- Server ESMTP (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014))
ehlo pippo.com
250-nk11p00mm-smtpin010.mac.com
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-DSN
250-ENHANCEDSTATUSCODES
250-EXPN
250-HELP
250-XADR
250-XSTA
250-XCIR
250-XGEN
250-XLOOP 65D9EA355E88A1C707125B6A790706DC
250-STARTTLS
250-ETRN
250-NO-SOLICITING
250 SIZE 28311552
quit
221 2.3.0 Bye received. Goodbye.
Connection closed by foreign host.

In particolare ecco cosa recita l'RFC in merito

5.1 SMTP protocol interactions If an SMTP client issues a RCPT command containing any valid NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST return the same response as it would to the same RCPT command without those NOTIFY and/or ORCPT parameters. A conforming SMTP server MUST NOT refuse a RCPT command based on the presence or absence of any of these parameters.

Non mi pare che ci siano dubbi di interpretazione di questa clausola. Eppure sono passati quasi 20 giorni ed Apple continua a mostrare lo stesso comportamento.

Io ho modificato i nostri mail server per evitare di chiedere il NOTIFY=SUCCESS per le email inviate ad Apple, ma devo dire che la cosa proprio non la digerisco!

Di seguito due thread dove altri parlano del problema, senza avere soluzione, chiaramente:

https://discussions.apple.com/thread/6720948

https://forums.novell.com/showthread.php/480972-mail-to-iCloud-com-mac-com-me-com-rejected

Che possiamo fare a parte perdere tempo adattandoci? Diffondere la voce sul fatto che Apple viola le specifiche probabilmente non aiuta ma può essere liberatorio!

Aggiungi un commento

Filtered HTML

  • Indirizzi web o e-mail vengono trasformati in link automaticamente
  • Elementi HTML permessi: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Linee e paragrafi vanno a capo automaticamente.

Plain text

  • Nessun tag HTML consentito.
  • Indirizzi web o e-mail vengono trasformati in link automaticamente
  • Linee e paragrafi vanno a capo automaticamente.