Anthony Geoghegan's questions

Nos últimos tempos, tenho aprendido o PowerShell para administrar nossa locação do Office 365 em vez de usar a interface da Web.

Depois de adicionar um novo domínio e confirmar a propriedade do nome de domínio (tudo feito por meio do PowerShell), queria saber se existe um cmdlet que possa ser usado para obter os registros de zona que devem ser configurados para um domínio que deve ser gerenciado pelo Office 365 .

Reunir as informações necessárias para criar registros DNS do Office 365 explica como obter essas informações usando a interface da Web, mas prefiro fazer o máximo possível usando o PowerShell.

No momento, posso usar o Get-DkimSigningConfigpara determinar o registro CNAME correto para habilitar o DKIM, por exemplo,

Get-DkimSigningConfig -Identity contoso.com | fl Selector?CNAME

Isso geralmente deve ser no formato, selector1-contoso-com._domainkey.contoso.onmicrosoft.commas descobri que para um de nossos domínios gerenciados, o DKIM CNAME precisava ser definido como selector1-contoso-com0i._domainkey.contoso.onmicrosoft.com(um 0i).

Para o registro MX, eu esperava que fosse, contoso-com.mail.protection.outlook.commas gostaria de ter certeza, então estou querendo saber se há um cmdlet do PowerShell ou objeto do Azure que lista os registros DNS que devem ser configurados para um domínio gerenciado (em particular o que usar para o registro MX).

Passei muito tempo pesquisando na web e na própria documentação da Microsoft, mas só encontrei referências de como determinar essas informações usando a interface da web.

Estou tentando entender exatamente como um e-mail é processado pelo Postfix – e alguns dos detalhes mais sutis das transações de e-mail SMTP. Meu objetivo de curto prazo é depurar um cliente SMTP proprietário (código binário, fechado), mas primeiro pensei em examinar o que acontece em uma transação SMTP bem-sucedida.

Pretendo bloquear o SMTP de saída (porta 25) em nosso firewall LAN, então configurei o Postfix como um servidor de correio interno para aceitar e-mails de software cliente local (primitivo) que só pode enviar e-mail via SMTP não autenticado (pela porta 25).

Ativei a depuração do smtpdprocesso do Postfix anexando o -vsinalizador detalhado master.cfconforme descrito em Solução de problemas com logs do Postfix . Em seguida, enviei um e-mail de minha própria estação de trabalho usando Cygwin Mutt com sSMTP (uma implementação mínima de sendmail).

Os logs do Postfix mostram que depois que a RCPT TO:linha foi processada com sucesso e o endereço do destinatário foi aceitável, o Postfix smtpdatribuiu à transação um ID de fila e respondeu ao cliente SMTP (sSMTP) com um arquivo 250 OK.

No entanto, em vez de emitir um DATAcomando, o cliente SMTP emitiu um RSETpara redefinir/interromper a transação de correio atual e o Postfix respondeu com um 250 OK.

Eu fiz algumas pesquisas sobre o que esse comando faz e, sem surpresa, o Simple Mail Transfer Protocol, RFC 2821 forneceu as informações mais abrangentes:

Este comando especifica que a transação de correio atual será abortada. Qualquer remetente, destinatário e dados de correio armazenados DEVEM ser descartados e todos os buffers e tabelas de estado limpos. O receptor DEVE enviar uma resposta "250 OK" a um comando RSET sem argumentos. Um comando de reinicialização pode ser emitido pelo cliente a qualquer momento. É efetivamente equivalente a um NOOP (ou seja, se não tem efeito) se emitido imediatamente após EHLO, antes de EHLO ser emitido na sessão, após um indicador de fim de dados ter sido enviado e confirmado ou imediatamente antes de um QUIT. Um servidor SMTP NÃO DEVE fechar a conexão como resultado do recebimento de um RSET; essa ação é reservada para QUIT (consulte a seção 4.1.1.10).

Como o EHLO implica algum processamento e resposta adicionais por parte do servidor, o RSET normalmente será mais eficiente do que reemitir esse comando, mesmo que a semântica formal seja a mesma.

Há circunstâncias, contrárias ao objetivo desta especificação, nas quais um servidor SMTP pode receber uma indicação de que a conexão TCP subjacente foi fechada ou redefinida. Para preservar a robustez do sistema de correio, os servidores SMTP DEVEM estar preparados para essa condição e DEVEM tratá-la como se um QUIT tivesse sido recebido antes que a conexão desaparecesse.

Tudo o que foi dito acima aconteceu no espaço de um segundo, então não deve haver problemas com tempos limite.

No segundo seguinte, o cliente enviou outro, RSETmas o cliente esperou 10s inteiros antes de reiniciar com MAIL FROM:, RCPT TO:mas desta vez ele segue e emite o DATAcomando e a transação é concluída (tudo no mesmo segundo de acordo com os logs).

Essencialmente, estou me perguntando por que um cliente SMTP interromperia sua própria transação emitindo RSETcomandos em vez de um DATAcomando.

Notas:

1. Posso editar a pergunta para incluir a extração do arquivo de log de email, mas com a -vdepuração, eles são muito detalhados e não quero sobrecarregar as pessoas com uma mangueira de dados irrelevantes.

2. Pesquisei o código-fonte sSMTP, mas não encontrei nenhuma menção a RSET.