- Perspectiva para o futuro próximo:
- Em um futuro próximo, estará disponível online um Portal de Revendedor para você como (potencial) revendedor de nossa White Labeled Benno Cloud (WLBC), que permitirá o seguinte:
- – Registro como novo revendedor WLBC (autosserviço)
- – Painel com visão geral dos seus clientes finais e seus arquivos
- – Anlegen, ändern und löschen Ihrer Endkunden und verwalten der Verträge Ihrer Endkunden
- – Visão geral das faturas que lhe enviaremos para WLBC
- Para o onboarding de seus clientes finais, devemos concordar sobre como configurar ou implementar a exportação dos e-mails a serem arquivados, para que os e-mails possam ser arquivados na Benno Cloud.
Aqui, oferecemos várias interfaces que apresentamos e explicamos abaixo. - INTERFACES PARA IMPORTAR E-MAILS NO WLBC
- Com o WLBC, os e-mails de fato de todas as soluções de e-mail (incl. Microsoft 365/Exchange Online) podem ser arquivados.
A importação de e-mails de caixas de correio IMAP (IMAP-Import) não está disponível no WLBC por razões regulatórias (GoBD).não está disponível. - O WLBC tem as seguintes interfaces de importação para importar e-mails dos respectivos clientes ou clientes finais:
1. API REST para importação de sistemas Linux/Unix, bem como upload de e-mails legados por meio de self-service
2. Caixa de correio de diário para M365/Exchange Online
3. Importação SMTP
- 1. API REST para importação de sistemas Linux/Unix
- As e-mails são enviadas como arquivos EML individuais para a API REST da Benno Cloud (upload HTTPS). Os arquivos EML devem ser armazenados em cache diretamente no MTA como uma cópia e posteriormente transferidos via REST.
- 1.1 Linux / UNIX MTA
- Para sistemas Debian GNU/Linux, fornecemos um daemon MILTER como um pacote Debian pronto. O daemon MILTER pode ser conectado a instalações Postfix ou Sendmail.
Todas as e-mails de entrada e saída são armazenadas localmente pelo MILTER. Além disso, as informações do envelope SMTP são armazenadas com os e-mails, de modo que os dados de possíveis destinatários BCC não sejam perdidos.
Os e-mails armazenados em cache são posteriormente transferidos por um job assíncrono para a Benno Cloud (upload https). Também fornecemos um pacote Debian GNU/Linux pronto para isso.
Para outras plataformas, podemos fornecer uma chamada cURL exemplar que pode servir como modelo para uma implementação da conexão.
- 2. Microsoft Exchange Server e Microsoft 365/Exchange Online (M365)
- O Microsoft Exchange Server (MXS) oferece a possibilidade de armazenar todos os e-mails de entrada e saída, bem como os internos, na chamada Caixa de Correio de Registro. Os e-mails são armazenados como e-mails com metadados no corpo e o e-mail propriamente dito como anexo.
Os e-mails podem ser posteriormente exportados via POP3 ou enviados via SMTP para uma caixa de correio externa.
O M365 ou Exchange Online também oferece essa possibilidade de configuração. No entanto, os e-mails aqui não podem ser importados via POP3, mas devem ser enviados obrigatoriamente via SMTP diretamente para uma caixa de correio de coleta (diretamente vinculada à Benno Cloud).
Para a importação do MS Exchange ou M365, fornecemos um endereço de Caixa de Correio de Registro para cada cliente final.
Uma breve explicação sobre a configuração da Caixa de Correio de Registro no Exchange Online pode ser encontrada aqui: https://wiki.benno-mailarchiv.de/doku.php/microsoft_office_365
- 3. Importar SMTP
- Ao importar SMTP na nuvem Benno, os e-mails a serem arquivados são enviados por SMTP para um endereço de e-mail individual (fornecido por nós) da nuvem Benno. Eles chegam diretamente ao arquivo.
- Uma alternativa dinâmica a ser configurada para o MILTER é a possibilidade de enviar os e-mails por encaminhamento de envelope para um endereço de e-mail individual da nuvem Benno.
No MTA Postfix do Linux/Unix, isso é configurado, por exemplo, com a ajuda de mapas BCC (palavra-chave sender_bcc_maps, recipient_bcc_maps).
Este procedimento tem vantagem da configuração mais simples e dinâmica. No entanto, as informações sobre os destinatários que foram endereçados por BCC são perdidas aqui. Os e-mails são então arquivados, mas só podem ser encontrados pelo ADMIN na nuvem Benno sob certas circunstâncias.
- 4Importação IMAP
- ATENÇÃO:
- Devido aos requisitos da GoBD, nenhuma interface está disponível para importação IMAP! Mesmo que a recuperação IMAP fosse tecnicamente viável, uma arquivamento de e-mail em conformidade com a GoBD não é viável por meio do IMAP.
- Caixas de correio do provedor (por exemplo, T-Online, web.de, GMX, etc.) ou caixas de correio de provedores como, por exemplo, All Inkl, que não oferecem interfaces adequadas para arquivamento de e-mail em conformidade com a GoBD ou não as disponibilizam para seus clientes, geralmente não podem ser arquivadas de acordo com a GoBD.
- Para tais casos, uma mudança para provedores de e-mail adequados é inevitável, que fornecem interfaces adequadas para arquivamento. (LWsystems oferece para isso a migração do alojamento de e-mail para a LWsystems Cloud (localização do servidor: Alemanha). Na LWsystems Cloud, operamos a Groupware Zimbra. Existe a possibilidade de escolher entre pastas de e-mail de qualquer tamanho - desde simples caixas de correio IMAP até pastas de e-mail de groupware completas. Estes podem naturalmente também ser usados com o Microsoft Outlook e sincronizados com dispositivos móveis.
- 5. Nota para infraestruturas maiores: Arquivamento de duplicatas em vários servidores de e-mail
- Se os e-mails forem importados de vários sistemas de origem diferentes, existe a possibilidade de que um e-mail seja importado várias vezes ou incorretamente.
Para tais casos, existem opções de configuração correspondentes que podemos usar caso a caso para seus clientes. - No seguinte artigo da Wiki, o problema é explicado:
https://wiki.benno-mailarchiv.de/doku.php/multi-import - Se você tiver uma situação como a descrita no Wiki, entre em contato conosco para esclarecimentos!
- 6. WebApp White Label com domínio individual
- A nossa WebApp da nuvem Benno pode ser facilmente customizada de acordo com o seu design corporativo correspondente e personalizada. Além disso, podemos fornecer e operar a WebApp sob um nome de domínio de sua escolha (por exemplo, mailarchiv.resellername.de).
- Folgende Dinge sind zu konfigurieren:
1. Sie als Reseller richten einen CNAME Record für Ihre Domain ein
2. Wir bereiten die VirtualHost Konfiguration auf dem Webserver vor
3. Wir richten ein Let’s Encrypt (Dehydrated) SSL-Zertifikat für die CNAME-Domain ein.
4. Sie gestalten und branden die WebApp per HTML/CSS und stellen uns die CSS-Datei zum Upload zur Verfügung.
5. Sofern Sie Ihr Logo für die WebApp verwenden möchten, stellen Sie uns dies ebenfalls zur Verfügung.
6. Wir richten Ihre CSS-Datei und Logo usw. auf dem Web-Server ein.
- 7. White Labeling completo - incluindo envio de e-mail
- A partir de 1º de dezembro de 2025, você pode estender o White Labeling da sua Benno Cloud para o envio de e-mail. Os e-mails que seus clientes encaminharem do arquivo serão enviados com seu endereço de remetente e domínio.
- Duas formas alternativas de atingir o objetivo:
- Alternativa 1 – Simples: Nós enviamos através de nossos servidores de e-mail – você ajusta apenas seu registro SPF (
a:mailout.benno-cloud.de) e nos fornece seu endereço de remetente.
Alternativa 2 – Flexível: Você envia através de seus próprios servidores de e-mail – você tem controle total sobre DKIM, DMARC e todos os outros mecanismos de autenticação. - Personalizar modelos de e-mail: Baixe nossos modelos de e-mail padrão (TXT/HTML) aqui, personalize-os de acordo com suas necessidades e envie-os para nós para implementação. Isso é feito de forma descomplicada através de nossa equipe de suporte: support@benno-mailarchiv.de
- Sem sua solicitação ativa de envio de e-mail com marca branca, os e-mails são enviados através de nossos servidores de e-mail com endereços de remetente como
no-reply@benno-cloud.de.
- INTERFACES DE AUTENTICAÇÃO
- Benno Cloud inclui um gerenciamento de usuários local para cada cliente individual. Ele é acessível dentro da WebApp (direitos de administrador do usuário são pré-requisitos).
Além disso, a autenticação dos usuários pode ser feita contra um LDAP local ou Active Directory (AD) ou por meio de OAuth2 (por exemplo, login da Microsoft, login do Google, etc.). - Ao autenticar contra um sistema local no cliente final, não deve haver acesso direto ao serviço LDAP. Em vez disso, fornecemos um pacote Debian GNU/Linux para realizar a autenticação contra o diretório LDAP interno via REST API.