Loading

'Relay di email' Salesforce con Office 365

Data pubblicazione: May 7, 2021
Descrizione
A causa della natura multitenant dell'instradamento email di Office 365 e Salesforce, il relay di email non è pronto all'uso come accade, invece, con le soluzioni in loco (on-premise) e pertanto non è consigliato. Consultarsi con il Supporto tecnico di Microsoft per configurare Exchange e Office 365 in modo che accettino le email da Salesforce.

A causa dell'instradamento interno di Microsoft e della convalida delle email tenant che necessitano di relay (inoltro) su Internet, alcune organizzazioni possono riscontrare errori quali 'Relay Access Denied ATTR36' (Accesso per l'inoltro negato ATTR36) quando le email vengono trasferite all'MTA (Message Transfer Agent) di Microsoft. Questo sembra essere correlato all'instradamento delle email da parte di Microsoft da IP condivisi. A causa di questo fattore, il relay di email tramite Office 365 potrebbe non funzionare in modo coerente senza l'utilizzo di un gateway SMTP standalone per far sì che il dominio di un'organizzazione trasferisca la posta al tenant Office 365.
 
 
  • Salesforce invia e inoltra le email utilizzando l'indirizzo email aziendale dell'utente come indirizzo email del mittente.
  • Office 365 accetterà la posta sulla porta 587 in questo scenario, ma necessita dell'autenticazione SMTP. Benché O365 effettuerà l'autenticazione SMTP a un livello Utente, Salesforce necessita di una funzionalità di relay server-a-server quando si utilizza il tenant Office365.
  • Attualmente, l'impostazione di un 'Connettore partner' sulla porta 25 con TLS e IP Salesforce dovrebbe consentire il relay delle email da Salesforce a Office 365 e quindi su Internet, se lo si desidera.
  • Per gli IP degli MTA di Salesforce, vedere la sezione 'Gli indirizzi utilizzati per il relay di email includono:' dell'articolo What are the Salesforce IP Addresses & Domains to allowlist? (Quali sono gli indirizzi IP e i domini Salesforce da inserire nell'elenco consentiti?)
Risoluzione


Quando si imposta il relay di email, prestare attenzione ai seguenti punti per garantire la sicurezza dell'inoltro:

  1. Configurare l'MTA ricevente in modo che consenta unicamente le email inviate dagli IP di relay di Salesforce (e da qualsiasi altro IP da cui ci si aspetta di ricevere email).
  2. Configurare il relay di Salesforce in modo che utilizzi TLS (in via facoltativa usare le opzioni Richiedi TLS o Verifica obbligatorio per verificare il nome host sul certificato del ricevente).
  3. Configurare l'MTA ricevente in modo che controlli il certificato e il nome di dominio del mittente per assicurarsi che corrisponda al certificato presentato.
  4. Configurare l'MTA ricevente per assicurarsi che il dominio mittente sia il proprio dominio di email.
  5. Configurare l'MTA ricevente in modo che verifichi la presenza di una header X-SFDC-LK contenente il proprio ID organizzazione.
  6. Impostare la firma DKIM in Salesforce.
  7. Configurare l'MTA ricevente in modo da verificare che lo stato di DKIM sia pass (DKIM=pass) e che il dominio per il quale è stato firmato sia il proprio dominio.


Se si utilizza Office 365 Exchange, i punti 1 - 3 sono possibili e possono essere eseguiti quando si imposta il proprio il relay in Exchange. È anche possibile creare regole in Exchange per verificare i punti 4-7. Tuttavia, il fatto che le regole impostate siano applicate o meno dipende dalla destinazione verso cui vengono instradate le email.

Se si inoltra solo la posta destinata al proprio dominio in Exchange, le regole che si sono create per testare i punti 4-7 verranno eseguite ed applicate. Se, invece, si sta inoltrando la posta che è destinata a un qualche altro dominio non associato al proprio tenant (che sia su Exchange o altrove in Internet), le regole non verranno applicate. In questo caso, anche se il relay in teoria potrebbe è attualmente in funzione, potrebbe, però, non instradare nel modo previsto (ad esempio, non esegue le regole create).

Perché le regole configurate nel tenant di Office 365 Exchange non vengono applicate?
Quando la posta viene instradata in questo modo tramite Exchange, le regole devono mapparla a un tenant appropriato nella propria infrastruttura. Un modo per farlo è l'IP di invio. Se Salesforce offrisse IP dedicati, sarebbero univoci per un cliente/dominio di posta e potrebbero facilmente mappare a uno specifico tenant univoco che configura il connettore partner in modo da consentire la posta dagli IP determinati. Dal momento che, però, Salesforce non offre attualmente IP dedicati nel servizio CRM, gli IP usati per il relay vengono condivisi tra più clienti. Pertanto, se più clienti configurano gli stessi IP in Exchange, l'IP di invio non è univoco di un specifico tenant ed Exchange non è in grado di mappare la posta in arrivo a un tenant specifico. Sanno che la posta proviene dagli IP da cui i loro attuali clienti inviano email, ma non può essere collegata a un cliente univoco. In questo scenario, questo può significare che la posta è mappata su un 'tenant sicuro' che utilizza un insieme condiviso di IP. Quando viene usato questo 'tenant sicuro', la posta inviata potrebbe avere una minore capacità di consegna. Inoltre, Microsoft sta lavorando per ridurre e infine eliminare i percorsi che fanno sì che la posta passi attraverso il 'tenant sicuro'. Non è detto che la posta funzioni bene sempre, solo perché oggi è filato tutto liscio. L'altro problema con l'instradamento attraverso il 'safe tenant' è che le regole create non saranno applicate.
 
Come posso verificare se le mie regole vengono eseguite in una determinata email che viene inoltrata tramite Exchange?
Exchange consente di eseguire una traccia messaggio che descrive in modo dettagliato le email inviate tramite il proprio tenant. Se la traccia messaggio non mostra il messaggio, significa che il messaggio non è strato instradato tramite il proprio tenant.
 

Esiste una soluzione temporanea a questo problema?

Se la posta che si inoltra da Salesforce è destinata unicamente a un dominio collegato al proprio tenant su Exchange, non dovrebbero esserci problemi e le regole verranno applicate come previsto. Se, invece, si invia ad altri domini non associati al proprio tenant, bisogna prendere in considerazione l'eventualità di impostare il proprio server di relay di email e/o altre opzioni.

Se si necessita di una maggiore flessibilità in merito al relay di email, potrebbe essere utile impostare un server IIS o altro server relay nel proprio spazio di dominio per accettare la posta da Salesforce prima di passarla alle proprie implementazioni 365 per la consegna interna e l'inoltro in Internet.

Note:
Numero articolo Knowledge

000387487

 
Caricamento
Salesforce Help | Article