Notificações por Push para o Secure Mail

O Secure Mail para iOS e o Secure Mail para Android pode receber notificações sobre email e atividades de calendário quando o aplicativo está sendo executado em segundo plano ou está fechado. O Secure Mail para iOS oferece suporte a notificações fornecidas através de atualização de aplicativo em segundo plano ou notificações por push fornecidas através do serviço Apple Push Notification (APNs). O Secure Mail para Android oferece suporte a notificações fornecidas através do serviço Firebase Cloud Messaging (FCM).

Como funcionam as notificações por push

O Secure Mail envia notificações por push para as seguintes atividades da Caixa de entrada:

  • Novo email, solicitações de reuniões, cancelamentos de reuniões, atualizações de reuniões: Quando o APNs envia notificações para uma caixa de entrada, o Secure Mail atualiza todas as pastas, incluindo o Calendário, de modo que as alterações de reuniões sejam refletidas imediatamente nos calendários dos usuários.

  • Para iOS, o status do Secure Mail muda de lido para não lido e vice-versa. O ícone do Secure Mail mostra o número de mensagens não lidas e novas na caixa de entrada do Exchange apenas. O ícone do Secure Mail é atualizado depois que os usuários leem os emails em um computador desktop ou laptop.

    Para iOS, o Secure Mail ainda fornece a contagem de emails não lidos da caixa de entrada do período de sincronização. Se a política Controlar notificações de tela de bloqueio está Ativada, as notificações por push aparecem na tela de um dispositivo bloqueado depois que o iOS desperta o Secure Mail para executar uma sincronização.

    Durante uma instalação ou atualização, o Secure Mail para iOS avisa aos usuários para que permitam notificações por push. Os usuários também podem permitir notificações por push mais tarde usando as configurações do iOS.

Para fornecer notificações por push para iOS e Android, a Citrix hospeda um serviço de ouvinte no Amazon Web Services (AWS) para executar as seguintes funções:

  • Escutar notificações por push de Serviços Web do Exchange (EWS) enviadas por servidores Exchange quando há atividade na caixa de entrada. O Exchange não envia nenhum conteúdo de email para o serviço Citrix.

    Nenhuma informação pessoalmente identificável é armazenada pelo serviço da Citrix. Em vez disso, um token de dispositivo e ID de assinatura identifica o dispositivo específico e pasta de caixa de entrada para ser atualizada dentro do Secure Mail.

  • Enviar notificações de APNs, que contêm apenas contagem de indicador de contagem para o Secure Mail em dispositivos iOS.

  • Enviar notificações de FCM para o Secure Mail em dispositivos Android.

O serviço de ouvinte da Citrix não prejudica o tráfego de dados de email, que continua a fluir entre dispositivos do usuários e servidores do Exchange por meio do ActiveSync. O serviço de ouvinte, que está configurado para alta disponibilidade e recuperação de desastres, está disponível em três regiões:

  • Américas
  • Europa, Oriente Médio e África (EMEA)
  • Ásia-Pacífico (APAC)

Requisitos do sistema para notificações por push

Caso a sua configuração do NetScaler Gateway inclua o Secure Ticket Authority (STA) e encapsulamento dividido está desativado, o NetScaler Gateway deve permitir o tráfego (quando encapsulado a partir do Secure Mail) para as seguintes URLs do serviço de ouvinte:

Região URL Endereço IP
Américas https://us-east-1.pushreg.xm.citrix.com 52.7.65.6; 52.7.147.0
EMEA https://eu-west-1.pushreg.xm.citrix.com 54.154.200.233; 54.154.204.192
ÁSIA-PACÍFICO https://ap-southeast-1.pushreg.xm.citrix.com 52.74.236.173; 52.74.25.245

Configuração de Secure Mail para notificações por push

Para configurar notificações por Push da Apple ou FCM para o Secure Mail para distribuição em loja de aplicativos, no console Endpoint Management, defina notificações por Push como Ativado e, em seguida, selecione a sua região. A seguinte figura apresenta a configuração para iOS.

Imagem da configuração de notificação por push no Endpoint Management

Para o Android, a figura a seguir mostra a mesma configuração de notificação por push que para o iOS. Além disso, se o EWS estiver hospedado em uma região diferente daquela em que o servidor de email está localizado, defina a configuração de Nome de host do EWS. A configuração padrão é vazia. Se você deixar a configuração vazia, o Endpoint Management usará o nome do host do servidor de email.

Imagem da configuração de notificação por push para Android no Endpoint Management

Configure o Exchange e o NetScaler para permitir que o tráfego flua para o serviço de ouvinte.

Configuração do Exchange Server

Permita SSL de saída (pela porta 443) do firewall para o URL do serviço de ouvinte para a região onde o seu Exchange Server está localizado. Por exemplo:

Região URL Endereço IP
Américas https://us-east-1.mailboxlistener.xm.citrix.com 52.6.252.176; 52.4.180.132
EMEA https://eu-west-1.mailboxlistener.xm.citrix.com 54.77.174.172; 52.17.147.220
ÁSIA-PACÍFICO https://ap-southeast-1.mailboxlistener.xm.citrix.com 52.74.231.240; 54.169.87.20

Se você tiver um servidor proxy entre Serviços Web do Exchange (EWS) e o dispositivo ouvinte da Citrix, você pode optar por uma das seguintes possibilidades.

  • Envie tráfego EWS pelo proxy e, em seguida, para o dispositivo ouvinte.
  • Ignore o proxy e roteie o tráfego EWS para o dispositivo ouvinte diretamente.

Para enviar tráfego de EWS através do servidor proxy, configure o arquivo EWS web.config na pasta ClientAccess\exchweb\ews folder, como indicado a seguir.

<configuration>
<system.net>
<defaultProxy>
<proxy usesystemdefault="false"
proxyaddress="http://proxy.example:8080"
bypassonlocal="true” />
</defaultProxy>
</system.net>
</configuration>`

Para ambientes do Exchange 2013, você deve adicionar a seção system.net ao arquivo web.config manualmente. Caso contrário, as configurações descritas neste artigo devem funcionar para Exchange 2013. Para solução de problemas, entre em contato com o administrador do Exchange.

Para ignorar o servidor proxy, configure a lista de ignorar para que permita conexões ao serviço de ouvinte da Citrix.

Quando o Secure Hub é registrado com a autenticação baseada em certificado, você também deve configurar o Exchange Server para autenticação baseada em certificado. Para obter detalhes, consulte o artigo em Conceitos avançados do Endpoint Management.

Configuração do NetScaler Gateway

Embora o Exchange server deva permitir o tráfego para o serviço de ouvinte, o NetScaler deve permitir o tráfego para o serviço de registro. Dessa forma, os dispositivos podem se conectar para registrar para notificações por push.

Se o EWS e ActiveSync servidores forem diferentes, configure a política de do NetScaler para permitir o tráfego de EWS.

Solução de problemas

Para solucionar problemas de conexões de saída, verifique os logs de eventos do Exchange, que incluem as entradas de log quando uma solicitação de assinatura ou a notificação para uma assinatura é inválida ou falha. Você também pode executar rastreamentos de Wireshark no Exchange Server para controlar o tráfego de saída para serviço de ouvinte da Citrix.

Para outros problemas, tente a ferramenta de teste do Secure Mail.

Perguntas frequentes de notificação por push do Secure Mail

Quando o iOS fornece notificações para Secure Mail?

Se o Secure Mail estiver sendo executado em primeiro plano, as notificações serão sempre entregues para Secure Mail. Esta é a única ocasião em que a Citrix pode garantir que as notificações são entregues. Quando o Secure Mail entra no segundo plano, o indicador de contagem do aplicativo é sempre atualizado. No entanto, as notificações (de tela de bloqueio e de faixa) baseiam-se na atualização do aplicativo em segundo plano – especialmente quando o iOS suspende ou termina o aplicativo – portanto sua ocorrência não é uma certeza. Os seguintes fatores estão fora do controle da Citrix.

Os seguintes casos podem afetar a entrega de notificações:

  • A bateria está fraca.
  • O Secure Mail não é usado com frequência (raramente aberto no primeiro plano).
  • Emails recebidos fora dos horários centrais de uso em que o aplicativo está suspenso por um longo período em segundo plano, por exemplo, entre a meia-noite e 6 da manhã.

As notificações não são entregues ao Secure Mail nos seguintes casos:

  • Se o usuário fechar o Secure Mail, até que o usuário reabra o aplicativo manualmente.
  • Se o sistema tiver terminado o Secure Mail e o aplicativo não tiver sido reiniciado automaticamente.
  • Quando o Secure Mail não está ativo.

Importante:

As notificações não podem ser entregues ao Secure Mail quando ele não estiver ativo por vários motivos, incluindo, sem limitação, os casos a seguir:

  • Se o dispositivo estiver no modo de baixa energia e o Secure Mail estiver no segundo plano. Este é o tipo mais comum de ocorrência na qual as notificações deixam de ser entregues.
  • Se a atualização de aplicativo em segundo plano do Secure Mail estiver desativada e o Secure Mail estiver em segundo plano. Observe que os usuários controlam esta configuração.
  • Se o dispositivo tiver conectividade de rede deficiente. Essa situação depende totalmente do dispositivo iOS.

Quando o Secure Mail não recebe uma notificação, o Secure Mail não sincroniza novos dados para o dispositivo. Como consequência, ocorrem as seguintes situações:

  • O Secure Mail sincroniza dados somente quando os usuários colocam o aplicativo no primeiro plano.
  • As notificações de bloqueio de tela param de ocorrer para novos emails. No entanto, os lembretes de calendário ainda aparecem.

Quando o Android envia notificações para Secure Mail?

No Android, as notificações são sempre enviadas ao Secure Mail.

Como o FCM afeta as notificações de email que aparecem na tela de bloqueio?

As notificações de novos emails que aparecem na tela de bloqueio do dispositivo são geradas com base nos dados que são sincronizados com dispositivo pelo Secure Mail. É importante ressaltar que essas informações não vêm do serviço de ouvinte.

Para mostrar notificações de novos emails, o Secure Mail precisa ter a capacidade de sincronizar dados do Exchange para que o Secure Mail tenha as informações disponíveis para criar as notificações.

Quando você recebe um novo email, é exibida a notificação FCM Você tem novas mensagens. Depois que a sincronização de email for terminada em segundo plano, o novo email aparecerá no Secure Mail.

Como a atualização de aplicativo em segundo plano afeta o Secure Mail e APNs?

Se o usuário desativa a atualização de aplicativo em segundo plano, ocorrem as seguintes situações:

  • O Secure Mail não recebe notificações quando não é o aplicativo em segundo plano.
  • O Secure Mail não atualiza a tela de bloqueio com novas notificações de email.

Desabilitar a atualização de aplicativo em segundo plano tem um grande efeito no comportamento do Secure Mail. Como especificado anteriormente, as atualizações do contador baseadas em APNs ainda ocorrem, mas os emails não são sincronizados ao dispositivo nesse modo.

Como o modo de baixa energia afeta o Secure Mail e APNs?

O comportamento do sistema com relação ao Secure Mail é o mesmo em modo de baixa energia que quando a atualização de aplicativo em segundo plano está desativada. Em modo de baixa energia, o dispositivo não ativa aplicativos para atualização periódica e não fornece notificações para os aplicativos em segundo plano. Os efeitos colaterais, portanto, são os mesmos que constam da seção “Atualização do aplicativo em segundo plano” acima. Note que no modo de baixa energia as atualizações do contador ainda acontecem com base em notificações de APNs.

Como os APNs afetam as notificações de email que aparecem na tela de bloqueio?

As notificações de novos emails que aparecem na tela de bloqueio do dispositivo são geradas com base nos dados que são sincronizados com dispositivo pelo Secure Mail. É importante ressaltar que essas informações não vêm do serviço de ouvinte.

Para mostrar notificações de novos emails, o Secure Mail precisa ter a capacidade de sincronizar dados do Exchange para que o Secure Mail tenha as informações disponíveis para criar as notificações.

Se as notificações de APNs não forem entregues ao Secure Mail em segundo plano, o Secure Mail não detecta as notificações e, portanto, não sincroniza novos dados. Como não existem novos dados disponíveis para o Secure Mail, não são geradas notificações na tela de bloqueio do dispositivo, mesmo que as notificações de APNs não sejam entregues.

Que outros problemas podem causar falha na sincronização em segundo plano comandada por FCM?

Vários problemas podem causar falha na sincronização em segundo plano comandada por FCM, entre eles os seguintes:

  • Um tíquete de STA inválido.
  • Quando o Secure Mail sai do segundo plano, o aplicativo tem 10 segundos para sincronizar todos os dados do servidor.

Se alguma das condições anteriores ocorrer, o Secure Mail não pode sincronizar dados. Como resultado, as notificações não são exibidas na tela de bloqueio.

O que outros problemas podem causar falha na sincronização em segundo plano comandada por APNs?

Vários problemas podem causar falha na sincronização em segundo plano comandada por APNs, entre eles os seguintes:

  • Um tíquete de STA inválido.
  • Uma conexão de rede lenta. Quando o Secure Mail sai do segundo plano, o aplicativo tem 30 segundos para sincronizar todos os dados do servidor.
  • Se a política de proteção de dados estiver acionada e o Secure Mail for ativado por uma notificação de APNs, quando o dispositivo está bloqueado, o Secure Mail não pode acessar o armazenamento de dados e a sincronização não ocorre. Observe que isso só se aplica quando o sistema está tentando iniciar o Secure Mail a frio. Se um usuário já tiver iniciado o Secure Mail em algum momento depois de ter desbloqueado o dispositivo, a sincronização comandada por APNs ocorre mesmo se o dispositivo estiver bloqueado.

Se ocorrer alguma das condições precedentes, o Secure Mail não pode sincronizar dados e, portanto, não pode exibir notificações de bloqueio de tela.

De que outros modos o Secure Mail gera notificações de bloqueio de tela quando as notificações não são entregues ou os APNs não estão sendo usados?

Se os APNs forem desativados, o Secure Mail ainda é ativado por eventos periódicos de atualização de aplicativo em segundo plano do iOS, partindo-se do pressuposto de que a atualização de aplicativo em segundo plano está ativa e de que o modo de baixa energia está desligado.

Durante esses eventos de ativação, o Secure Mail sincroniza novos emails provindos do Exchange Server. Estes novos emails poderão ser usados para gerar notificações por email na tela de bloqueio. Assim, mesmo quando as notificações de APNs não são entregues ou as APNs estão desativadas, o Secure Mail pode sincronizar dados em segundo plano.

É importante notar que isso ocorre menos em tempo real que quando as APNs estão em uso e quando as notificações de APNs são enviadas para o Secure Mail. Quando o iOS rotei as notificações de APNs para o Secure Mail, o aplicativo sincroniza imediatamente dados provenientes do servidor e as notificações de bloqueio de tela parecem ser em tempo real.

Caso sejam necessárias ativações de atualização de aplicativo em segundo plano, as notificações de bloqueio de tela não ocorrem em tempo real. Nesse caso, o Secure Mail é ativado com uma frequência determinada totalmente pelo iOS. Sendo assim, pode demorar algum tempo entre o momento da chegada de um email a uma caixa de entrada do usuário no Exchange e o momento em que o Secure Mail sincroniza a mensagem de notificação e gera a notificação de tela de bloqueio.

Observe também que o Secure Mail recebe essas ativações periódicas mesmo que as APNs estejam em uso. Em todos os casos em que a atualização de aplicativo em segundo plano é ativada, o Secure Mail tenta sincronizar dados provenientes do Exchange.

Como o Secure Mail difere de outros aplicativos que mostram o conteúdo na tela de bloqueio?

Uma diferença muito importante - e outra que gera confusão - é que o Secure Mail nem sempre mostra novos emails em tempo real na tela de bloqueio do mesmo modo que fazem o Gmail, o Microsoft Outlook e outros aplicativos. O principal motivo dessa diferença é a segurança. Para alinhar com o comportamento dos outros aplicativos, o serviço de ouvinte da Citrix requer as credenciais de usuário para autenticar com o email do Exchange para obter conteúdo e também passar este conteúdo de email por meio do serviço de ouvinte da Citrix, bem como o serviço de APNs da Apple. A abordagem da Citrix relativa às notificações APNs não requer o serviço de ouvinte da Citrix para adquirir ou armazenar a senha dos usuários. O serviço de ouvinte não tem acesso à caixa de correio de usuário ou à senha.

Uma observação sobre o aplicativo de email nativo iOS: o iOS permite que seu próprio aplicativo de email mantenha uma conexão persistente com o servidor de email, o que garante que as notificações são sempre entregues. Aplicativos de terceiros além do email nativo não tem permissão para usar esse recurso.

Comportamento do aplicativo Gmail: A Google é proprietária e controla o aplicativo Gmail e o servidor do Gmail. Isso significa que o Google pode ler o conteúdo da mensagem e incluir o conteúdo da mensagem na carga de notificação de APNs. Quando o iOS recebe esta notificação de APNs do Gmail, o iOS faz o seguinte:

  • Atribui ao contador do aplicativo o valor especificado na carga de notificação.
  • Exibe a notificação de tela de bloqueio usando o texto da mensagem que está contido na carga de notificação.

Esta é uma diferença crítica: é o iOS, e não no aplicativo Gmail, que exibe a notificação de bloqueio de tela Com base nos dados contidos na carga. Na verdade, o iOS nunca pode ativar o aplicativo Gmail, de modo semelhante à forma como o iOS não pode ativar o Secure Mail quando uma notificação chega. No entanto, como a carga contém o trecho da mensagem, o iOS pode exibir a notificação de tela de bloqueio sem precisar que os dados de email sejam sincronizados com o dispositivo.

No Secure Mail, essa situação é diferente. O Secure Mail precisa primeiro sincronizar dados da mensagem do Exchange para que o aplicativo mostre a notificação de tela de bloqueio.

Comportamento do aplicativo Outlook para iOS: a Microsoft controla o Outlook para iOS. A organização à qual o usuário pertence, no entanto, controla os servidores Exchange dos quais os dados são obtidos. Apesar dessa configuração, o Outlook pode exibir notificações de tela de bloqueio com base nos dados que o Microsoft fornece na notificação de APNs porque o Outlook para iOS faz uso de um modelo no qual o Microsoft armazena as credenciais do usuário. A Microsoft então acessa Diretamente a caixa de correio do usuário do seu serviço de nuvem e detecta a existência de novos emails.

Se houver novos Emails, o serviço de nuvem da Microsoft gera uma notificação de APNs que contém os nodos dados de email. Esse modelo opera de modo semelhante ao modelo do Gmail em que o iOS simplesmente usar os dados para gerar uma notificação de bloqueio de tela com base naqueles dados. O aplicativo Outlook para iOS não é envolvido no processo.

Nota de segurança importante sobre o Outlook para iOS: Há implicações de segurança importantes na abordagem do Outlook para iOS. As organizações têm de confiar na Microsoft com senhas para seus usuários para que a Microsoft possa ter acesso à caixa de correio do usuário, o que oferece um risco de segurança. Para obter mais informações sobre a forma como o Microsoft gerencia as senhas do usuário, consulte Microsoft TechNet.

Para mais perguntas frequentes específicas aos administradores sobre notificações por push, consulte este artigo de suporte do Knowledge Center. Para mais perguntas frequentes específicas ao usuário, consulte este artigo de suporte do Knowledge Center.