Estou tentando configurar uma assinatura de e-mail DKIM para um servidor SMTP postfix.
Este servidor deve ser usado por diferentes serviços na rede local.
Eu gerou o par de chaves DKIM, adicionei-o ao meu domínio e consegui enviar e-mails com êxito do próprio servidor, como visto aqui:
me@server:~$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 server.lan ESMTP Postfix (Ubuntu)
HELO example.com
250 server.lan
MAIL FROM: [email protected]
250 2.1.0 Ok
RCPT TO: [email protected]
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
To:[email protected]
Subject:Testing from server
hello
.
250 2.0.0 Ok: queued as AAD604EA1CC2
Essa mensagem é recebida com a assinatura DKIM correta.
Mas, se eu fizer exatamente a mesma coisa (somente com telnet server.lan 25 ) em outra máquina na rede local, a assinatura DKIM não será incluída e o destinatário não saberá quem enviou o e-mail.
Descobri que essa entrada em /var/log/mail.log é relevante para ela:
Jul 30 04:28:16 server opendkim[25664]: AAD604EA1CC2: can't determine message sender; accepting
Então, imaginei que o postfix não esteja definindo o endereço FROM corretamente. Então, por que não está fazendo isso e como posso consertar isso?
Obrigado antecipadamente ...
O log inteiro durante a transação da estação de trabalho é o seguinte:
Jul 30 15:56:29 server postfix/smtpd[6795]: warning: database /etc/aliases.db is older than source file /etc/aliases
Jul 30 15:56:29 server postfix/smtpd[6795]: connect from workstation.lan[192.168.1.63]
Jul 30 15:57:24 server postfix/smtpd[6795]: 2C35E4EA1DD1: client=workstation.lan[192.168.1.63]
Jul 30 15:58:18 server postfix/cleanup[6799]: 2C35E4EA1DD1: message-id=<>
Jul 30 15:58:18 server opendkim[25664]: 2C35E4EA1DD1: can't determine message sender; accepting
Jul 30 15:58:18 server postfix/qmgr[25810]: 2C35E4EA1DD1: from=<[email protected]>, size=272, nrcpt=1 (queue active)
Jul 30 15:58:19 server postfix/smtp[6802]: 2C35E4EA1DD1: to=<[email protected]>, relay=ASPMX.L.GOOGLE.COM[173.194.70.26]:25, delay=67, delays=66/0.02/0.26/1.1, dsn=2.0.0, status=sent (250 2.0.0 OK 1343656739 a59si1127667wel.70)
Jul 30 15:58:19 server postfix/qmgr[25810]: 2C35E4EA1DD1: removed
O MTA nunca é responsável por definir cabeçalhos de mensagens; isso é um problema com seu cliente de e-mail ou com o MUA.
Dito isto, se o postfix detectar uma mensagem sem ANY de: headers, adiciona o endereço do remetente MAIL FROM como um cabeçalho From:; isso está muito bem documentado.
Você tem o smtpd_milters e o non_smtpd_milters em seu main.cf?
Eu tentei um dkim milter com apenas smtpd_milters apontando para ele e ele não funcionaria, apesar de eu ter telnetado para o smtpd, mas quando adicionei a configuração para o non_smtpd_milters ele começou a funcionar. Algo muito maluco lá, mas foi isso que fez isso acontecer.
Acabei de me deparar com este problema e resolvi-o. Eles chave aqui é a linha do maillog: "não pode determinar o remetente da mensagem; aceitando". A questão é que o e-mail que chega é mal formado e está faltando alguns cabeçalhos requeridos pelo RFC que o opendkim precisa para fazer o DKIM.
Por padrão, o opendkim é configurado para permitir o envio dessas mensagens, já que é incapaz de fazer qualquer coisa com as informações disponíveis e não pode confirmar nem negar que a mensagem passa no DKIM, e erra ao tomar a decisão de não eliminar mensagens, a menos que explicitamente configurado para.
Por que isso está sendo acionado quando você envia e-mails usando o telnet é porque você não digitou todos os cabeçalhos exigidos pelo RFC que o opendkim estava esperando. Se você os adicionou (especificamente, o opendkim só parece verificar os cabeçalhos De e Data, e parece não se importar com o que o cabeçalho de Data realmente contém)
Se você está certo em descartar todos os e-mails que violam os RFCs e está faltando os cabeçalhos De ou Data, você pode entrar no seu opendkim.conf e alterar ou adicionar a linha "RequiredHeaders yes". Provavelmente, é bastante seguro fazer isso, pois mesmo a maioria dos spams faz tudo certo, mas há sempre um risco ao descartar mensagens que alguns emails legítimos também podem perder.