Binarus's questions

Temos um locatário do Microsoft 365 e encontramos um problema com o roteamento de e-mails devido a um requisito incomum.

Conectamos o domínio example.com ao locatário, e o e-mail que é enviado [email protected]é colocado na caixa de correio do Exchange para o respectivo usuário (Exchange Online). Na maioria dos casos, esse é o comportamento desejado.

No entanto, para certos usuários, os e-mails não devem chegar às caixas de correio do Exchange Online desses usuários, mas, em vez disso, devem ser encaminhados para outro MX que lida com as mensagens recebidas desses usuários. Isso parece impossível de ser alcançado se houver o requisito adicional de que as caixas de correio do Exchange Online desses usuários permaneçam habilitadas.

Para explicar com um exemplo:

Os usuários [email protected]e [email protected]ambos têm suas caixas de correio do Exchange Online habilitadas. As mensagens de e-mail para [email protected]devem ser colocadas na respectiva caixa de correio do Exchange Online, mas as mensagens para [email protected]devem ser encaminhadas para outro MX externo que lida com e-mails de entrada para [email protected], mas não para [email protected].

Para que isso acontecesse, fizemos o seguinte:

• Crie um conector com as seguintes propriedades:
  • Cenário de fluxo de e-mail: do Office 365 para o servidor de e-mail da sua organização
  • Nome:Bypass_Exchange
  • Status: Ativado
  • Uso do conector: Use somente quando eu tiver uma regra de transporte configurada que redireciona mensagens para este conector
  • Roteamento: roteie mensagens de e-mail por meio destes hosts inteligentes:‎mx.otherdomain.com
  • Restrições de segurança: (não relevante aqui)
  • Validação: Último resultado da validação: ‎Validação bem-sucedida‎ (o restante da propriedade de validação não é relevante aqui)
• Crie uma regra com as seguintes propriedades:
  • Status: Habilitado
  • Nome da regra:Bypass_b
  • Modo: Aplicar
  • Gravidade: Não especificado
  • Definir intervalo de datas: O intervalo de datas específico não foi definido
  • Endereço do remetente: Cabeçalho correspondente
  • Prioridade: 0
  • Para erros de processamento de regras: Ignorar
  • Aplique esta regra se: qualquer endereço de destinatário corresponder a estes padrões:[email protected]
  • Faça o seguinte: Roteie a mensagem usando o conector chamadoBypass_Exchange
  • Comentários sobre as regras: (nenhum)

Isso funciona até a metade:

Se alguém enviar um e-mail para [email protected], a mensagem chega na respectiva caixa de correio do Exchange Online. Se alguém enviar um e-mail para [email protected], a mensagem é encaminhada para mx.otherdomain.com, que a manipula adequadamente porque está configurado para cuidar de mensagens para [email protected].

Mas se alguém enviar um e-mail para ambos os destinatários (por exemplo, [email protected]se [email protected]ambos estiverem no To:cabeçalho), as coisas dão errado e o remetente recebe uma notificação de não entrega.

Entendo por que isso acontece: o Microsoft 365 aciona a regra porque um endereço de destinatário corresponde [email protected]a , e encaminha a mensagem para mx.otherdomain.com, que por sua vez enlouquece porque não está configurado para lidar com e-mails para [email protected].

Embora tenha entendido o problema, não consegui encontrar uma solução para ele, mesmo depois de ter analisado de perto todas as condições possíveis no editor de regras e seu possível uso. Nas configurações de fluxo de e-mail no Microsoft 365, é possível de alguma forma "dividir" as mensagens recebidas em duas cópias, onde uma cópia vai apenas para os destinatários que são manipulados pelas caixas de correio do Exchange Online e a outra cópia vai apenas para os destinatários que são manipulados por mx.otherdomain.com?

Eu tenho um chassi com o backplane Supermicro BPN-SAS3-826EL1. Este backplane permite que 12 HDDs sejam conectados. No entanto, eu obviamente ainda não entendi o cabeamento entre o HBA e o backplane que eu preciso para usar todas as 12 portas do HDD.

De acordo com o primeiro desenho na página 3-1 do manual , PRI-J1 e PRI-J2 devem ser conectados ao HBA (e portanto são "entradas"), enquanto PRI-J3 e PRI-J4 são "saídas" que podem ser conectado a um backplane em cascata, que eu não tenho.

O manual diz ainda que os PRI-Jn são conectores SFF-8643, que podem transportar os sinais para 4 drives SAS ou SATA. Isso significa que posso usar 8 HDDs com o backplane, embora ele forneça mecanicamente 12 conectores de unidade.

O que preciso fazer para usar 12 HDDs com esse backplane?

Por favor, perdoe-me se a pergunta for burra, mas ainda não tenho experiência com backplanes, e estudei este e outros manuais da Supermicro várias vezes, mas ainda não entendo a situação.

Atualização / Esclarecimento

Lamento muito não ter sido suficientemente claro:

Eu gostaria de usar drives SATA (não SAS), e já tenho um LSI 9361-8i conectado ao backplane, usando dois cabos com conectores SFF-8643 em cada extremidade. Dessa forma, o controlador está vendo 8 unidades. Agora gostaria de saber como posso usar as 4 unidades restantes.

A placa que estou usando tem dois controladores SATA / SAS integrados, cada um com capacidade para quatro unidades. Preciso apenas conectar um deles ao PRI-J3 do backplane?

Na minha rede, há um servidor Windows 2008 R2 com nome de rede Dax. Nesse servidor, tenho (entre outros, claro):

• uma unidade de disco rígido, montada comoE:\
• uma pastaE:\odo
• um compartilhamento SMB \\Dax\odoque fornece a pasta E:\odopara a rede
• uma conta de usuárioDax\Backup

O usuário Dax\Backupé membro do Dax\Backup Operatorsgrupo e, além disso, tem permissões totais no compartilhamento \\Dax\odoe na pasta E:\odo.

Também tenho alguns PCs clientes executando o Windows 10 x64 Enterprise (versão 1809). Cada PC cliente tem

• várias contas de usuário que são diferentes das contas de usuário no servidor (ou seja, não há AD, os PCs clientes não estão associados a um domínio)
• uma pasta de dados complexa e profundamente aninhada com permissões cuidadosamente elaboradas, ou seja, cada usuário em um cliente tem acesso a diferentes partes (subpastas) da pasta de dados
• uma conta de usuário Client\Backupque tenha a mesma senha da conta do servidor Dax\Backupe que também seja membro do respectivo grupo de clientes Client\Backup Operators.

Nos PCs clientes, tenho um software capaz de copiar toda a pasta de dados mencionada acima, incluindo todas as permissões, informações do proprietário, fluxos alternativos, junções e assim por diante no compartilhamento \\Dax\odo. Eu deixo este software rodar sob a conta do usuário Client\Backuppara que ele possa ler a pasta de dados independentemente das ACLs que estão em vigor lá.

De fato, pastas, arquivos, junções e assim por diante (ou seja, o conteúdo real da pasta de dados) são copiados sem nenhum problema, mas o ajuste dos metadados (por exemplo, ACLs, propriedade) no destino falha.

Gostaria de entender o porquê e, claro, o que posso fazer a respeito.

Meus pensamentos e testes até agora são:

• Meu software cliente está copiando esses arquivos e pastas no compartilhamento do servidor enquanto executa como user Backup. Como esse usuário (no servidor) está no Backup Operatorsgrupo, não deve haver problema em alterar os metadados durante a cópia ou mesmo após ter copiado um arquivo ou pasta, pois é exatamente para isso que o Backup Operatorsgrupo deve servir.

• Se (no servidor) eu tornar o usuário Backupmembro do Administratorsgrupo, o problema persiste.

• Se (no servidor) eu der ao usuário Dax\Administratorpermissão total para o compartilhamento \\Dax\odo, bem como para a respectiva pasta E:\odo, e se eu executar meu software cliente sob a conta Client\Administrator(essa conta também tem a mesma senha nos clientes e no servidor), o o problema não persiste e o processo funciona conforme o esperado .

Além disso, rastreei o que acredito ser a causa do problema no servidor: Usando o monitor de processos da Sysinternals, vi que obviamente o usuário Backupno servidor, ou mais precisamente, sua representação pelo serviço de rede / processo do sistema, não tem privilégios suficientes. Pelo menos, isso é o que eu faria com as propriedades do evento mostradas abaixo:

High Resolution Date & Time:    04.05.2019 09:27:37,2077520
Event Class:    File System
Operation:  IRP_MJ_CREATE
Result: PRIVILEGE NOT HELD
Path:   E:\Odo\d-LSE\d\temp\test - 2019-05-04 09-27-40\bla.txt
TID:    2812
Duration:   0.0000581
Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Access System Security
Disposition:    OpenIf
Options:    Complete If Oplocked
Attributes: n/a
ShareMode:  Read
AllocationSize: 0
Impersonating:  DAX\Backup

Nos últimos dias, também aprendi que para membros de determinados grupos (entre eles Administratore Backup Operators) existem dois tokens: um normal e um elevado, onde apenas o último habilita os privilégios especiais de tais grupos.

Então (observe que isso é apenas uma suposição ingênua e que não sou especialista neste campo): O serviço de rede / processo do sistema no servidor pode representar a versão não elevada da conta de usuário Backupao lidar com o tráfego de rede em nome de esse usuário, e isso poderia ser o motivo do problema? Eu poderia resolver o problema fazendo com que o serviço de rede/processo do sistema personifique a versão elevadaBackup da conta de usuário ao lidar com o tráfego de rede em nome desse usuário? Se sim, como?

PS Se minha teoria acima for boba, o título deste post será enganoso, então sinta-se à vontade para corrigi-lo ...

Isenção de responsabilidade: eu li algumas das perguntas e artigos aqui e em outros lugares que lidam com a reescrita de cabeçalhos do Sendmail. Não encontrei uma resposta para a pergunta abaixo porque a outra pergunta está relacionada principalmente à reescrita de cabeçalhos (em vez de adicioná-los) e quase todas estão relacionadas a mensagens de saída e ao remetente do envelope (em vez do destinatário do envelope).

Tendo dito isto:

Estou executando um servidor de email, usando o Sendmail 8.14.4 no Debian jessie.

Existem alguns endereços de destinatários de e-mail que são mapeados para a mesma conta de usuário do sistema operacional. Quando o respectivo usuário do sistema operacional lê as mensagens, ele não pode determinar para qual endereço de e-mail as mensagens foram enviadas originalmente.

Portanto, gostaria que o Sendmail adicionasse um cabeçalho personalizado contendo os destinatários do envelope a todas as mensagens de e-mail de entrada.

Acho que poderia explicar melhor meu problema por exemplo:

Suponha que eu tenha dois endereços de e-mail [email protected]e [email protected]. Ambos são mapeados para a conta de usuário O/S offers. Isso funciona até agora: O usuário O/S offers, ao buscar seu e-mail, recebe todas as mensagens enviadas para [email protected]e [email protected].

O problema agora é que ele não consegue determinar para qual endereço de e-mail cada mensagem foi enviada originalmente. Isso significa que: embora ele esteja vendo todas as mensagens que foram enviadas para ambos os endereços de e-mail, ele não pode dizer se uma determinada mensagem foi enviada originalmente para [email protected]ou para [email protected].

Portanto, gostaria de adicionar um cabeçalho personalizado a cada mensagem de entrada, talvez algo assim: X-Envelope-Recipient: <Original envelope recipient>.

Qual seria a maneira mais fácil de fazer isso?

Era uma vez, escrevi algumas regras personalizadas simples para o Sendmail. Mas quase 15 anos se passaram desde então, então eu gostaria de evitar isso e, portanto, espero que haja uma solução fácil ou que alguém possa me apontar na direção certa. Para ser honesto, escrever um milter para resolver meu problema atualmente me parece mais fácil do que reaprender a sintaxe de regras do Sendmail...

EDIÇÃO 1

Conforme solicitado por @AnFi, aqui está a definição do mailer local de sendmail.cf:

Mlocal,         P=/usr/lib/sm.bin/mail.local, F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
                T=DNS/RFC822/SMTP,
                A=mail.local -l -h inbox

Tenho um site servido pelo Apache 2.4 que deve servir todo o conteúdo via HTTPS. Já tenho redirecionamentos apropriados que funcionam corretamente, mas não detectam nenhum caso patológico. Eu queria melhorar essa situação e, ao fazer minha lição de casa, encontrei o seguinte exemplo neste documento :

<If "%{SERVER_PROTOCOL} != 'HTTPS'">
    Redirect "/admin/" "https://www.example.com/admin/"
</If>

Eu modifiquei um pouco isso para refletir minha situação:

<If "%{SERVER_PROTOCOL} != 'HTTPS'">
    Redirect "/" "https://www.example.com/"
</If>

Agora, ao tentar visualizar qualquer URL do meu site, o navegador entra em um loop de redirecionamento infinito.

Estou suspeitando que o exemplo realmente está errado. SERVER_PROTOCOLnão parece conter o valor HTTPSem nenhuma circunstância. Em vez disso, de acordo com o que li em outros artigos, ele contém coisas como HTTP/1.1(como o nome poderia esperar).

Portanto, minha pergunta é: o que exatamente SERVER_PROTOCOLcontém em que circunstâncias / em que contexto? E qual poderia ser a razão pela qual o site de documentação oficial do Apache é o único que encontrei durante várias horas de pesquisa que lista HTTPScomo um valor possível de SERVER_PROTOCOL?

Existe um lugar onde eu possa baixar o máximo possível de e-mails de spam, enviados do maior número possível de locais diferentes em todo o mundo?

Para esclarecer: não estou atrás de bancos de dados que contenham hashes de e-mails de spam ou que contenham endereços IP de remetentes / redes que enviaram spam. Estou apenas interessado em obter o máximo possível de e-mails de spam reais de forma inalterada.

Por exemplo, pode ser um arquivo mbox gigante contendo milhares ou milhões desses e-mails em seu estado original. Existem algumas organizações ou empresas anti-spam que fornecem acesso a esses dados?

ATUALIZAR:

Não sendo um falante nativo de inglês, eu simplesmente não sabia as palavras-chave certas. Basta procurar por "spam corpus" ou "spam corpora" no Google. Esperando que isso ajude outras pessoas com o mesmo problema e esperando que agora não haja mais razão para votar negativamente ...