Anexos de email não estão sendo enviados via nó SMTP no n8n 2.3.0 (auto-hospedado)

Perguntas
1

Descreva o problema/erro/pergunta

Oi,
Estou tentando enviar e-mails com anexos do gatilho IMAP para o nó SMTP na minha configuração n8n 2.3.0 auto-hospedada.
Configuração:

  • Gatilho de E-mail (IMAP) com formato “Simple” ativado
  • N8N_DEFAULT_BINARY_DATA_MODE=default
  • Nó Enviar E-mail (SMTP) com servidor de e-mail Plesk
    O Problema:
    Os e-mails são enviados com sucesso, mas os anexos NÃO estão incluídos. Quando faço debug, vejo que os anexos existem como dados binários, mas não aparecem no e-mail recebido.
    Tentei:
    :white_check_mark: Alterar N8N_DEFAULT_BINARY_DATA_MODE para “memory” e “default”
    :white_check_mark: Reiniciar com docker compose down -v
    :white_check_mark: Usar o nó “Extract from File” para converter em Base64
    :white_check_mark: Definir Binary Properties como “attachment_0,attachment_1,attachment_2”
    Nada funcionou. O e-mail chega, mas os anexos sempre estão faltando.
    Perguntas:
  1. Isso é um bug conhecido com SMTP + dados binários na 2.3.0?
  2. Há alguma solução alternativa além de usar a Gmail API?
  3. Devo fazer downgrade para n8n 1.x?
    Qualquer ajuda será apreciada!

Qual é a mensagem de erro (se houver)?

Por favor compartilhe seu workflow

Compartilhe o resultado retornado pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n: 2.3.0
  • Banco de dados (padrão: SQLite): postgres
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo de desktop): docker
  • Sistema operacional: ubuntu
2

Você pode postar uma captura de tela de como a parte Attachments do nó SMTP está configurada? O campo Binary Property precisa corresponder exatamente ao nome da propriedade, separado por vírgula, sem espaços. Algo como attachment_0,attachment_1 funciona bem, mas se houver um espaço após a vírgula, pode quebrar silenciosamente.

3

Essa configuração de modo de dados binários é o que mais me chama atenção. Quando está em “padrão”, ela salva o anexo em disco e o recupera mais tarde quando chega a hora de enviar o e-mail. Se sua configuração tem mais de um contêiner envolvido em qualquer lugar, o nó SMTP pode simplesmente não conseguir encontrar esse arquivo na hora de anexá-lo e não vai lançar um erro, vai apenas pular silenciosamente. O que combina exatamente com o que você está vendo. Além disso, esse docker compose down -v que você executou, o -v limpa volumes. Se seu armazenamento binário estava em um desses, esse comando pode ter deletado logo ali.

4

Oi, obrigado pela sua ajuda

image
image1005×568 38.6 KB

5

Oi @Anthony_P Bem-vindo!
Nenhum binário chega a Send email. formatInfoMail retorna um objeto json simples sem chave binária, e Message a model substitui o item novamente depois dele, portanto as propriedades que sua expressão Attachments nomeia não existem mais no item no momento em que o nó é executado.
Coloque o binário de volta com um nó Code entre si humain e Send email:

return [{
  json: $input.first().json,
  binary: $('Email Trigger (IMAP)').first().binary,
}];

Em seguida, defina Attachments como {{ Object.keys($binary).join(',') }}.

Fazer downgrade não vai ajudar, apontar esse campo diretamente para o binário de outro nó é um problema em aberto relatado pela última vez na versão 1.115.3:

6

altere o join para não adicionar um espaço

{{ Object.keys($('Email Trigger (IMAP)').item.binary).join(',') }}
7

Obrigado pela explicação! Mas preciso esclarecer algo: Quando adiciono este debug no corpo do email: {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} consigo ver o conteúdo completo em Base64 dos anexos. Isso prova que os dados binários ainda existem e são acessíveis a partir do nó Email Trigger. Se os binários realmente desaparecessem como você mencionou, eu não veria nada na saída de debug. Mas estou vendo os dados completos do arquivo (codificados em Base64). Então o problema NÃO é que os binários desapareçam - eles estão claramente lá. O problema parece ser que o campo “Binary Properties” do nó Send email não consegue acessá-los diretamente do nó Email Trigger.

8

Já testei isso muitas vezes - tanto com a expressão completa do caminho do nó quanto apenas colocando attachment_0,attachment_1 diretamente - mas nada funciona. O estranho é: quando faço debug adicionando {{ JSON.stringify($(‘Email Trigger (IMAP)’).item.binary, null, 2) }} no corpo do email, consigo ver o conteúdo completo do objeto binário com todos os dados Base64. Isso prova que os anexos existem e são acessíveis. Mas o nó Send email não os anexa.

image
image2131×327 56.3 KB

9

Analisamos isso e parece que pode ter sido corrigido em um lançamento recente. Atualize e veja se você ainda está enfrentando o mesmo problema.

10

Esse resultado de depuração é uma expressão que lê os dados do nó IMAP diretamente, o que funciona de qualquer lugar do fluxo de trabalho e não coloca nada no item. Attachments não é uma expressão que busca dados, é uma lista de nomes de propriedades que o nó procura por conta própria no seu item de entrada, e sua captura de tela mostra que ele resolve exatamente para os três nomes corretos. O nó então procura por attachment_0 no item passado por si humain, não encontra nada e envia sem ele.
Ambos os seus testes alteraram essa string. Nenhum valor nesse campo funcionará até que algo coloque o binário no item, o que é o que o nó Code faz. Uma atualização também não mudará isso.

12

Obrigado, funcionou. Porém, ainda estou lutando para entender por que tenho que reconstruir o objeto antes de enviar o e-mail.
É quase certo que, entre o momento em que recupero os anexos e o momento em que o e-mail é enviado, há blocos intermediários — e os dados binários do primeiro bloco não são passados automaticamente de um bloco para o próximo. Nos tutoriais on-line que vi, o anexo é definido no bloco anterior.

13

Binary não é herdado, cada nó constrói seu próprio item de saída e decide se o transmite adiante. formatInfoMail retorna um objeto simples, então o binary desapareceu um nó após o trigger, e Message a model constrói um item novo do seu próprio. Os dois nós IF passam o item direto, então o número de nós entre eles nunca foi a questão.
É também por isso que os tutoriais não precisam de reconstrução, o attachment fica na saída do nó imediatamente antes de Send email. Nós que reformatam dados e conseguem mantê-los expõem a escolha em suas opções, Edit Fields e Split Out têm uma configuração para se o binary passa para sua saída.