Likes Likes:  0
Resultaten 1 tot 2 van de 2
  1. #1
    Vreemde Google DMARC reports
    geregistreerd gebruiker
    1.626 Berichten
    Ingeschreven
    18/06/04

    Locatie
    Maastricht

    Post Thanks / Like
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    KvK nummer: 14101842

    Thread Starter

    Vreemde Google DMARC reports

    We hebben enkele servers hetzelfde ingeregeld, met in de /etc/aliases de root verwijzen naar een bedrijfs email van mij.

    Alleen op een Centos 8 VPS heb ik af en toe het volgende.
    Eerst had ik dat ip nog niet in SPF van mij domein gezet (wat op en andere server staat), dus dacht ik dat dit het probleem was.
    Dus ip van die server toegevoegd in SPF maar ik krijg nog af en toe van deze rapporten.

    Zoals ik het lees is er mail verstuurd vanaf dat ip met mijn domeinnaam naar Gmail, anders krijg ik geen Google rapport, toch?
    Alleen kan ik in /var/log/exim geen mail vinden die "from" mijn email adres afkomstig is.
    Verder is er niets aanwezig op de server van mijn domeinnaam. Enige wat er gebeurt zijn emails van CSF en van root naar mijn email adres.
    En root wordt verstuurd als root@server.serverdomain.com en niet als mijn@bedrijfsemail.nl.
    Verder staat het op de Centos 7 servers ook zo, dus zou ik daar ook het euvel moeten ondervinden en dat is niet het geval.

    Ik heb op dat adres ook een forwards naar gmail staan.

    Dus ik begrijp niet:
    a.) Waarom ik een rapport van gmail krijg als ik daar niets naar toe stuur?
    b.) Waarom er een SPF fail komt terwijl ik het server ip als ip4: heb opgenomen in mijn SPF record?

    Iemand een idee wat hier aan de hand kan zijn?

    Code:
    <?xml version="1.0" encoding="UTF-8" ?>
    
    <feedback>
      <report_metadata>
        <org_name>google.com</org_name>
        <email>noreply-dmarc-support@google.com</email>
        <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
        <report_id>4173566153660xxxxx</report_id>
        <date_range>
          <begin>1591315200</begin>
          <end>1591401599</end>
        </date_range>
      </report_metadata>
      <policy_published>
        <domain>mycompany.com</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>none</p>
        <sp>none</sp>
        <pct>100</pct>
      </policy_published>
      <record>
        <row>
          <source_ip>144.xxx.xxx.xxx</source_ip>
          <count>1</count>
          <policy_evaluated>
            <disposition>none</disposition>
            <dkim>fail</dkim>
            <spf>fail</spf>
          </policy_evaluated>
        </row>
        <identifiers>
          <header_from>mycompany.com</header_from>
        </identifiers>
        <auth_results>
          <spf>
            <domain>server.serverdomain.com</domain>
            <result>none</result>
          </spf>
        </auth_results>
      </record>
    </feedback>

  2. #2
    Vreemde Google DMARC reports
    geregistreerd gebruiker
    1.626 Berichten
    Ingeschreven
    18/06/04

    Locatie
    Maastricht

    Post Thanks / Like
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    26 Berichten zijn liked


    KvK nummer: 14101842

    Thread Starter
    Heb het waarschijnlijk gevonden. Op deze ene server stond in Softaculous het "from" veld niet specifiek ingevuld.
    Vermoedelijk stuurt hij dan vanuit de gewone admin naam, moet het nog checken als het weer gebeurt.

    Blijft echter raar dat er dan een fail komt terwijl ip4:144.xxx.xxx.xxx gewoon in mijn SPF regel staat als toegestaan.



Labels voor dit Bericht

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2021 Webhostingtalk.nl.
Web Statistics