Craig Watson's questions

Depois de migrar provedores de hospedagem no ano passado, acabei recebendo muitos e-mails que aparecem com uma "Data" da migração, em vez da data de entrega da mensagem, veja a captura de tela:

Esta data aparece nos meus clientes locais (Mail.app no ​​OS X 10.11.6 e iOS 10 beta) e também no webmail (Roundcube).

O servidor de correio de back-end é Dovecot e todas as mensagens no diretório Maildir têm os Delivery-datecabeçalhos corretos.

Existe alguma maneira de corrigir isso ou fazer com que o Dovecot releia ou recompile seus bancos de dados de mensagens?

Atualmente, tenho dois servidores Apache em execução aqui e aqui , ambos usam certificados SSL assinados por StartSSL. Configuração Apache SSL abaixo:

  ## SSL directives
  SSLEngine on
  SSLCertificateFile      "/etc/certificates/thor.vikingserv.net/certificate.crt"
  SSLCertificateKeyFile   "/etc/certificates/thor.vikingserv.net/private.key"
  SSLCertificateChainFile "/etc/certificates/intermediate/startssl-class-1.crt"

Tanto o certificado do servidor quanto o certificado intermediário são SHA-256, mas o certificado CA é SHA-256 em minha estação de trabalho Linux, mas SHA-1 em meu MacBook.

Eu poderia usar a SSLCACertificatePathdiretiva no Apache para forçar o certificado CA SHA-256, mas isso substituiria o certificado raiz distribuído com o sistema operacional?

Temos um certificado curinga GoDaddy que instalamos no Exchange 2010 e é usado com sucesso em conexões IIS para OWA.

Atribuímos este certificado ao serviço SMTP, bem como ao IIS, mas isso não parece ter cancelado a atribuição do certificado autoassinado padrão.

O certificado autoassinado já está atribuído a SMTP, IMAP e POP (não podemos usar o certificado curinga para IMAP e POP por ser um curinga). É possível cancelar a atribuição de um certificado autoassinado apenas do serviço SMTP?

A única documentação que encontrei está relacionada à remoção completa de um certificado.

Acabamos de receber um novo chassi JBOD, com 14 unidades NL-SAS de 2 TB - 2 já foram reservadas para peças sobressalentes, portanto, temos 12 unidades disponíveis.

Eu tenho várias opções para configurar o array RAID10 (infelizmente a unidade principal não permite spans de numeração ímpar):

• 6 x spans de 2 discos (12 TB brutos)
• 3 x spans de 4 discos (6 TB brutos)
• 2 x spans de 6 discos (4 TB brutos)

Eu gostaria de obter o espaço mais utilizável para que 6x2 pareça favorável e 2x6 não forneça espaço suficiente, mas estou me perguntando se há algum desempenho ou risco ao usar 6x2 em vez de 3x4.

Eu acho que 6x2 é mais arriscado porque cada span pode perder apenas uma unidade - mas os dois hot-spares são suficientes para mitigar isso?

Alguém pode verificar minha sanidade mental ou me dar alguma indicação?

A unidade principal é um FC Infortrend ES-DS 3024 SAN e a carga de trabalho será o armazenamento de backup da Veeam, se isso fizer alguma diferença.

Eu executo um MTA que consiste nas verificações padrão Postfix, SpamAssassin, ClamAV, SPF/DKIM, etc.

Estou ciente de que alguns serviços de e-mail estão começando a tentar conexões TLS antes do texto sem formatação ao tentar entregar e-mail ao meu servidor.

Percebo que nem todos os serviços oferecem suporte ao TLS, mas estou me perguntando o quão bem adotado ele é para que eu possa satisfazer o lado de segurança do TOC do meu cérebro (sim, eu sei que o SSL não é tão seguro quanto pensávamos que era ... ).

A documentação do Postfixsmtpd_tls_security_level afirma que o RFC 2487 decreta que todos os servidores de correio referenciados publicamente (ou seja, MX) não forçam o TLS:

De acordo com o RFC 2487, isso NÃO DEVE ser aplicado no caso de um servidor SMTP referenciado publicamente. Esta opção, portanto, está desativada por padrão.

Portanto: quão aplicável/relevante é a documentação (ou o RFC de 15 anos), e posso forçar o TLS com segurança em todas as conexões SMTP de entrada sem bloquear metade dos ISPs do mundo?

Por favor, desculpe o despejo de cérebro - tentando resolver um problema que estava correndo em círculos por um dia inteiro!

TL;DR - Clientes em duas redes separadas por um switch L3 podem ver e fazer ping um ao outro, mas apenas a VLAN 99 pode acessar a Internet, apesar de um gateway padrão ser definido (e roteável) no switch. Os pacotes acabam chegando ao gateway e não vão mais longe, comprovado por traceroutes.

VLANs:

• 192.168.50.0/24 (Legado - VLAN 99 )
• 10.50.1.0/24 (Novo - VLAN 1 )

Kit:

• SonicWALL NSA220 com uma interface LAN em 192.168.50.1 e um endereço WAN. O SonicWALL está configurado para NAT todos os endereços LAN para a WAN.
• Switch HP 2920 Layer 3, com interfaces em 192.168.50.254 e 10.50.1.254 e gateway padrão definido como 192.168.50.1 .

Gateways padrão:

• VLAN 99: 192.168.50.1 (SonicWALL)
• VLAN 1: 10.50.1.254 (HP)

Detalhes da implementação:

• Eu enviei uma rota estática via DHCP para 10.50.1.0/24 com o gateway 192.168.50.254 para evitar redirecionamentos de ICMP do SonicWALL para 2920.
• Eu tenho 10.50.1.0/24 roteado estaticamente para 192.168.1.254 e zoneado como uma rede LAN no SonicWALL.

Tabela de roteamento no 2920:

core-switch-01# show ip route

IP Route Entries

Destination        Gateway         VLAN Type      Sub-Type   Metric     Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0          192.168.50.1    99   static               1          1    
10.50.1.0/24       MGMT            1    connected            1          0    
127.0.0.0/8        reject               static               0          0    
127.0.0.1/32       lo0                  connected            1          0    
192.168.50.0/24    OLD_NET         99   connected            1          0    

Por favor, comente se alguém precisar de mais detalhes.