DMARC: échec SPF, DKIM Pass, IP source: pas le mien!

8

C'est étrange:

<record>    
    <row>   
      <source_ip>65.20.0.12</source_ip> 
      <count>2</count>  
      <policy_evaluated>    
        <disposition>none</disposition> 
        <dkim>pass</dkim>   
        <spf>fail</spf> 
      </policy_evaluated>   
    </row>  
    <identifiers>   
      <header_from>mydomain.co.uk</header_from> 
    </identifiers>  
    <auth_results>  
      <dkim>    
        <domain>mydomain.co.uk</domain> 
        <result>pass</result>   
      </dkim>   
      <spf> 
        <domain>mydomain.co.uk</domain> 
        <result>fail</result>   
      </spf>    
    </auth_results> 
  </record>

J'utilise une combinaison de mes propres serveurs et google pour envoyer du courrier. L'IP source n'est pas la mienne ou celle de Google - comment diable peut-il passer DKIM?

Les rapports proviennent de Yahoo. L'IP semble être un serveur de messagerie pour btinternet.com géré par cpcloud.co.uk (Critical Path Inc.) - je sais qu'il y avait quelque chose d'étrange entre eux dans le passé avec SPF etc. - pourrait-il y avoir quelque chose à voir avec cela ?

L'IP est uniquement dans les rapports Yahoo DMARC. Les dates auxquelles je reçois les rapports ont un jour d'avance sur les e-mails envoyés aux utilisateurs de btinternet.

Est-ce aussi simple que d'envoyer un e-mail à un compte bt, il est transféré / redirigé / renvoyé à Yahoo et cela signale l'échec?

yahoo spf dkim

— nedge2k
source

1

N'oubliez pas que BT Internet a externalisé sa fourniture de courrier électronique à Yahoo. Cela peut expliquer le comportement.

— Andrew Leach

Je vois également ce même problème sur certains de mes domaines et je ne sais pas pourquoi cpcloud.co.uk devrait apparaître comme source. Je me demandais si peut-être ils procuraient du trafic SMTP non chiffré à des utilisateurs derrière des connexions haut débit à domicile BT. Malheureusement, la majorité des fournisseurs de services d'hébergement de messagerie électronique autorisent à la fois l'accès crypté et non crypté à leurs clients, laissant la détection automatique de l'appareil / logiciel de l'utilisateur final ou des paramètres par défaut optant souvent pour la configuration non cryptée.

— richhallstoke

6

Désolé, j'ai oublié de poster la résolution!

Donc, c'était une chose de transfert comme suspect, mais mes règles SPF dans DNS étaient trop strictes et ne permettaient pas le transfert - par conséquent, SPF a échoué. Le passage de -all à ~ tout l'a trié.

— nedge2k
source

J'ai l'enregistrement SPF TXT réglé sur ~ all, mais j'obtiens toujours la même erreur dmarc de yahoo. "v = spf1 comprend: _spf.google.com ~ all"

— Swatantra Kumar

5

Deux choses à considérer:

Le transfert d'e-mails a lieu sur Internet. Cela pourrait être le cas de quelqu'un qui exécute son propre serveur @ example.org mais qui transfère ensuite tous les e-mails à Yahoo (éventuellement atterrissant dans une boîte aux lettres @ yahoo.com). Les gens le font tout le temps parce qu'ils aiment mieux l'interface utilisateur de la destination finale ou c'est plus facile à gérer.
DKIM peut survivre au transfert si le contenu du message reste intact. Il n'est pas inhabituel de voir des messages transmis par DKIM sortir de lieux étranges sur Internet avant d'être signalés par le DMARC.

Dans votre exemple, la présence d'une signature passant par DKIM provenant d'une source IP inconnue est un signal très fort que cette ligne de données représente un e-mail transféré.

— Tim Draegen
source

0

Je l'ai aussi avec un de mes clients. J'ai le contrôle du serveur de messagerie du domaine (Exchange) (avec DKIM ajouté par dkim-exchange) et des hôtes intelligents (Postfix) et nous recevons un ou deux e-mails par jour toujours via le serveur 65.20.0.12. J'ai vérifié les règles et les journaux et personne en interne ne transfère ses messages vers n'importe où, donc la seule chose à laquelle je peux penser est qu'il s'agit d'un e-mail sortant à un client / fournisseur qui renvoie ensuite les messages de leur compte BT à leur Yahoo compte, peut-être sans le savoir. Quoi qu'il en soit, je laisse le SPF pour le domaine tel qu'il est et laisse Yahoo rebondir sur les e-mails, car peut-être que de cette façon, quelqu'un finira par le remarquer et me le demandera.

— Marco
source