Spam enviado por mx.google.com apesar do SPF falhar

Question

Alguns remetentes de spam usam nosso endereço de e-mail como remetente em e-mails falsos. Agora recebemos milhares de mensagens devolvidas de e-mails inexistentes.

Nós configuramos os registros SPF e DKIM, mas isso não para.

procrastination.com TXT v=DMARC1;p=reject;sp=reject;pct=100;aspf=r;fo=0;ri=86400;rua=mailto:[email protected]    IN  3600

procrastination.com TXT v=spf1 ip4:77.240.191.234 ip4:83.167.254.20 ip4:83.167.254.21 ip4:83.167.254.22 ip4:81.95.97.117 ip4:81.95.97.100 a -all

Os cabeçalhos de e-mail de formulários parecem que o spammer usa o mx.google.com do Google SMTP em seu e-mail, embora o resultado do SPF falhe.

Exemplo de cabeçalhos segue:

    Delivery to the following recipient failed permanently:

     [email protected]

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the server for the recipient domain webmail.flcgil.it by webmail.flcgil.it. [109.168.127.232].

The error that the other server returned was:
550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table


----- Original message -----

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-original-authentication-results:x-gm-message-state:message-id
         :reply-to:from:subject:date:mime-version:content-type
         :content-transfer-encoding:delivered-to;
        bh=DWSqotpOUM1r96KR6EV4WUBt9g/4xHl2j4TzsRWmYtM=;
        b=Z/uEm+/nMjD5ynw2bKuAtnqTFvpJ6QbUnJbXtPyYU1xONdOI+630z8WGZPfCkEjrR8
         +iIrp9EH7y+3xOpEL2N5JoKtkMpcbgUuyC8N6dH5Mx1aZZXAylg1mXc6uMne2NhQAZVW
         XGVmikat0wxCsgSYt+T8nHXULU/OY5LlAbGiKD0EQ96nvRB0fyquVyHFvQfKLi7gORlD
         939MMe1QiEw/4aH4oEigEOgMoAZe+1SxoiyJfj/M80iHtsh97bhHCukB4Yni9aX9LJEc
         edS2ZS9c5IBnTmTmLbQwlZXx65u9Z3FIUSU82GQSWOF6Upp2ZzHwt7Az3hbfn+Or5Sy/
         lGvg==
X-Original-Authentication-Results: mx.google.com;       spf=fail (google.com: domain of [email protected] does not designate 66.84.38.179 as permitted sender) [email protected]
X-Received: by 10.42.50.81 with SMTP id z17mr14637142icf.57.1430488267890;
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
X-Gm-Message-State: ALoCoQkCSb7aXwRPbIiUnV3a6JAZsPok55aOGUIsgkMbXM4B9QOW7RY14KvVmumEXab7Rh5k2YlELm1N9oWNNCvASrmS2cavQKBK4Kp7sNFkm6YKqjisbzTMuq6cso3vvh4X/KsH8bgCx7+Yg5E7IVbLsSgjr+rRlicTI1tXLVq88gyQdAE/3bE=
X-Received: by 10.42.50.81 with SMTP id z17mr14637132icf.57.1430488267815;
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
Return-Path: <[email protected]>
Received: from procrastination.net (s179.n38.n84.n66.static.myhostcenter.com. [66.84.38.179])
        by mx.google.com with ESMTPS id z2si3656962icq.16.2015.05.01.06.51.07
        for <[email protected]>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Fri, 01 May 2015 06:51:07 -0700 (PDT)
Received-SPF: fail (google.com: domain of [email protected] does not designate 66.84.38.179 as permitted sender) client-ip=66.84.38.179;
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of [email protected] does not designate 66.84.38.179 as permitted sender) [email protected]
Received: from User ([154.118.4.5])
    (authenticated bits=0)
    by procrastination.net (8.13.1/8.13.1) with ESMTP id t41DosSm007397;
    Fri, 1 May 2015 09:50:59 -0400
Message-Id: <[email protected]>
X-Orig: [154.118.4.5]
X-Authentication-Warning: procrastination.net: procrast owned process doing -bs
Reply-To: <[email protected]>
From: "INTERNATIONAL MONETARY FUND"<[email protected]>
Subject: Attn: Your Long Over due payment claim/change of account?
Date: Fri, 1 May 2015 14:51:05 +0100
MIME-Version: 1.0
Content-Type: text/plain;
    charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Antivirus: avast! (VPS 150501-0, 05/01/2015), Outbound message
X-Antivirus-Status: Clean
Delivered-To: [email protected]

Alguma idéia de como nós fazemos essa parada? Por que o SPF não ajudou?

    

Answer 1

Você não pode obrigar outras pessoas a filtrar seus e-mails recebidos com base no SPF e no DKIM, ou mesmo em qualquer outro critério. Se o google escolher ignorar o SPF, que assim seja; você já fez a sua parte, tudo que você pode fazer agora é sentar e ignorar as reclamações de pessoas que não filtram o SPF.

Dito isso, ter um registro SPF válido tende a reduzir o backscatter, porque um spammer racional preferirá forjar e-mails de um domínio que não tenha um registro SPF válido que termine em -all , como o seu. Você pode descobrir que depois que essa onda atual de backscatter passou, as coisas realmente melhoram.

    

Answer 2

Seu registro DMARC deve estar abaixo de _dmarc.procrastination.com . Esta é uma nova especificação e não é amplamente suportada. Se você quiser relatórios, também precisará de um registro TXT contendo v=DMARC1 at *._report._dmarc.procrastination.com ou procrastination.com._report_dmarc.procrastination.com . Você saberá que isso está funcionando quando você começar a receber relatórios. O Google e o Yahoo provavelmente enviarão relatórios para você.

O SPF tende a ser eficaz na redução da quantidade de emails falsificados (spam) usando seu domínio. No entanto, muitos sites não usam o SPF para bloquear emails, pois muitos sites configuraram registros incorretamente. Descobri que eu preciso colocar na lista de permissões determinados domínios para garantir que eu não devolva e-mails legítimos.

Você pode querer implementar BATV (confirmação da etiqueta de endereço de devolução) no e-mail de saída para rejeitar as notificações de spam de retroespalhamento. No entanto, você deve permitir que uma semana ou duas depois de configurar o BATV antes de bloquear as mensagens de devolução recebidas.

Implementar DKIM (Domain Keys Identified Mail) e adicioná-lo à sua política DMARC pode ajudar a reduzir a entrega de mensagens falsificadas.

Existem alguns sites de notícias que permitem o envio de notificações por e-mail para amigos que usam incorretamente o endereço de e-mail da pessoa como o envelope e os endereços. Estes podem ser bloqueados por uma interpretação estrita de SPF .