Re: [mailop] Gmail change DMARC Policy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2018-08-02 at 14:49 -0400, Bill Cole wrote: > The 'd=' domains don't use DNSSEC. This means that the immediate > validity of the signature at delivery time is dependent on trusting a > key which may be spoofed. The DKIM TXT record has a TTL of one day, so > it is hard to be certain whether the signer today is the same entity > as the signer tomorrow. If you only trust DKIM signatures from DNSSEC domains, then you can only enforce DMARC p=reject for a trivially small number of domains. The largest providers that I have seen with DMARC p=reject are aol.* and yahoo.*, none of which use DNSSEC. We reject a lot of spam based on their p=reject setting. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAltkqSsACgkQL6j7milTFsHOsgCeJP2N2pgoVZOvVVZXsmt7wkrb rRYAoIKj8n+pmpetUtiVS2qwV4YHlekt =kajG -END PGP SIGNATURE- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
Ah, yes. I'm not sure of the likelihood of spoofing DKIM TXT records to do something useful, but that may also be a Google scale thing (ie, the number and scale of the spoofing you'd have to do to catch all our nameservers over the time of the ttl, or what you'd accomplish at that point (it would look similar to DKIM replay or any old hijack). Brandon On Thu, Aug 2, 2018 at 11:55 AM Bill Cole < mailop-20160...@billmail.scconsult.com> wrote: > On 2 Aug 2018, at 14:29, Brandon Long via mailop wrote: > > > On Thu, Aug 2, 2018 at 7:44 AM Bill Cole < > > mailop-20160...@billmail.scconsult.com> wrote: > > > >> On 2 Aug 2018, at 9:23, Stefano Bagnara wrote: > >> > >>> In our case our main DKIM-signature for any email sent by our > >>> servers > >>> always matches the return-path domain, the HELO and the FCrDNS. It > >>> often doesn't match the MIME From, so it doesn't align. > >>> When we can do it we add a second signature aligned to the From, but > >>> we can't do that for every email. > >> > >> Right, but what YOU do isn't what either ESP in the OP's case is > >> doing. > >> > >> They are signing with 3-level domains that shares nothing except its > >> top > >> 2 levels with any other name used in sending the mail. The signing > >> domains have no connection to the messages except the signature. It > >> is > >> solely an authentication that some party capable of manipulating > >> intrinsically ephemeral unrelated unsigned DNS records acted as a > >> transport for the mail. > >> > >> I guess at Google-scale it could be worth creating a mechanism for > >> maintaining reputation for that essentially meaningless attribute of > >> mail (an unreliable authentication of an entity with no defined > >> relationship to the mail,) but I am surprised by this. > >> > > > > How is it unreliable? > > The 'd=' domains don't use DNSSEC. This means that the immediate > validity of the signature at delivery time is dependent on trusting a > key which may be spoofed. The DKIM TXT record has a TTL of one day, so > it is hard to be certain whether the signer today is the same entity as > the signer tomorrow. > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On 2 Aug 2018, at 14:29, Brandon Long via mailop wrote: On Thu, Aug 2, 2018 at 7:44 AM Bill Cole < mailop-20160...@billmail.scconsult.com> wrote: On 2 Aug 2018, at 9:23, Stefano Bagnara wrote: In our case our main DKIM-signature for any email sent by our servers always matches the return-path domain, the HELO and the FCrDNS. It often doesn't match the MIME From, so it doesn't align. When we can do it we add a second signature aligned to the From, but we can't do that for every email. Right, but what YOU do isn't what either ESP in the OP's case is doing. They are signing with 3-level domains that shares nothing except its top 2 levels with any other name used in sending the mail. The signing domains have no connection to the messages except the signature. It is solely an authentication that some party capable of manipulating intrinsically ephemeral unrelated unsigned DNS records acted as a transport for the mail. I guess at Google-scale it could be worth creating a mechanism for maintaining reputation for that essentially meaningless attribute of mail (an unreliable authentication of an entity with no defined relationship to the mail,) but I am surprised by this. How is it unreliable? The 'd=' domains don't use DNSSEC. This means that the immediate validity of the signature at delivery time is dependent on trusting a key which may be spoofed. The DKIM TXT record has a TTL of one day, so it is hard to be certain whether the signer today is the same entity as the signer tomorrow. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On Thu, Aug 2, 2018 at 7:44 AM Bill Cole < mailop-20160...@billmail.scconsult.com> wrote: > On 2 Aug 2018, at 9:23, Stefano Bagnara wrote: > > > In our case our main DKIM-signature for any email sent by our servers > > always matches the return-path domain, the HELO and the FCrDNS. It > > often doesn't match the MIME From, so it doesn't align. > > When we can do it we add a second signature aligned to the From, but > > we can't do that for every email. > > Right, but what YOU do isn't what either ESP in the OP's case is doing. > > They are signing with 3-level domains that shares nothing except its top > 2 levels with any other name used in sending the mail. The signing > domains have no connection to the messages except the signature. It is > solely an authentication that some party capable of manipulating > intrinsically ephemeral unrelated unsigned DNS records acted as a > transport for the mail. > > I guess at Google-scale it could be worth creating a mechanism for > maintaining reputation for that essentially meaningless attribute of > mail (an unreliable authentication of an entity with no defined > relationship to the mail,) but I am surprised by this. > How is it unreliable? And that relationship to the mail is the message itself, to be DKIM signed, it had to come from them. At that level, they are taking "ownership" of the message, or even some level of "responsibility". Yes, it is true, that that only really helps if you have some scale to see enough messages from senders to build knowledge of them. I don't think Google's level of scale is required for that, and even relatively small receivers may be using third party data sources or anti-spam software which does aggregate between receivers. It also allows receivers to grant the senders information about what happened to their mail, with FBLs and things like our feedback loop. The DKIM replay attacks were probably the most effective attacks on this particular usage, trying to piggyback off of higher reputation systems. One of the reasons with ARC that we couldn't re-use DKIM signatures and had to create a separate similar signature, is that an ARC signature doesn't take responsibility for the message, it's only supposed to take responsibility for maintaining the chain and the data in the AAR header. There are places where "unrelated" DKIM signatures are kind of on the border of the "responsibility" thing, such as relays like mailing lists. In some respects, that is better handled by ARC, though we're a long way from that. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On 2 Aug 2018, at 9:23, Stefano Bagnara wrote: In our case our main DKIM-signature for any email sent by our servers always matches the return-path domain, the HELO and the FCrDNS. It often doesn't match the MIME From, so it doesn't align. When we can do it we add a second signature aligned to the From, but we can't do that for every email. Right, but what YOU do isn't what either ESP in the OP's case is doing. They are signing with 3-level domains that shares nothing except its top 2 levels with any other name used in sending the mail. The signing domains have no connection to the messages except the signature. It is solely an authentication that some party capable of manipulating intrinsically ephemeral unrelated unsigned DNS records acted as a transport for the mail. I guess at Google-scale it could be worth creating a mechanism for maintaining reputation for that essentially meaningless attribute of mail (an unreliable authentication of an entity with no defined relationship to the mail,) but I am surprised by this. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On Thu, 2 Aug 2018 at 14:54, Bill Cole wrote: > What I actually do not understand is why anyone (like BOTH of these > senders) is bothering to DKIM-sign mail in ways that CANNOT align for > DMARC and don't even match any domain in any header other than a > signature. e.g.: Providers are actively monitoring/building domain reputation based on DKIM signatures, even if there is no alignment (alignment is a concept that doesn't even exists in DKIM.. it is a DMARC stuff). Some provider sends you FBL only if you DKIM sign emails (and they don't care about alignment, because it is not a DKIM stuff). So, one may care about DKIM even if they don't care about DMARC. Alignment is a DMARC stuff. DMARC is newer than DKIM and DKIM didn't require alignment for a reason. If you want GPT or Yahoo FBLs for an email flow sent by SMTP servers under your control but where you can't control the thousands of different "From:" used, then you DKIM sign using your own domain and happily get access to GPT and Yahoo FBLs: isn't this a good reason to do that? (you are not in the position to refuse sending those emails, you can only choose to add a signature or not). In our case our main DKIM-signature for any email sent by our servers always matches the return-path domain, the HELO and the FCrDNS. It often doesn't match the MIME From, so it doesn't align. When we can do it we add a second signature aligned to the From, but we can't do that for every email. Domain owner today can use DMARC to enforce alignment, but it is their option. Receivers can ignore non-aligned DKIM signatures (no one force them to read them). If you ignore DMARC there is not so much difference in "transparency" or "inscrutability" between a Sender: "ME" From: "ME" DKIM: d=yourdomain Compared to From: "ME" Reply-to: "ME" DKIM: d=yourdomain The first is not aligned, the second one is aligned.. when DMARC is enforced people moves from the first to the second.. but there is not so much difference in the way most users will read the 2 emails. So I don't think there's a big "logical reason" they should be handled so differently with regard to spamminess. In both case you may want to assign a reputation to the sender IP and to the signing domain and use them in your spam-scoring. Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On 2 Aug 2018, at 3:15 (-0400), Stefano Bagnara wrote: Hi Bill, you misunderstood the question. No, I was trying to directly kill the theory that is expressed in the Subject of the discussion. Unfortunately, I omitted a critical word to transmit that point (see below.) This isn't a DMARC policy question. Both messages (the first one and the one from Mailchimp) fails DMARC as both are sending with a gmail.com in the From and of course they both fail DMARC. BUT, the one from Mailchimp is not classified as dangerous, while the first one is classified dangerous. We (a small italian ESP) sends email for "gmail.com" senders and, like Mailchimp, we have no problem reaching inbox (or Promotions) with DMARC failing and we see not "dangerous" warning on our "dmarc failing" email. Yes, and where your mail lands is unrelated to any GMail DMARC policy, Like Brandon wrote in another comment, it probably change the behaviour depending on reputations (dkim domain reputation/ip reputation). Once Gmail.com will move to quarantine or reject then Mailchimp (and others) will start altering the From and only use the gmail.com address in the Reply-to, like they (and we) are already doing for yahoo.com (and other) senders. What I actually do not understand is why anyone (like BOTH of these senders) is bothering to DKIM-sign mail in ways that CANNOT align for DMARC and don't even match any domain in any header other than a signature. e.g.: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; d=gmail.mcsv.net; And in the other message: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; d=gmail.tstes.net; fW5vfwK5VPX9ib6jJy Why bother? But here's the typo that obscured my point: [...] If you want DMARC to work for your mail, use a From header for which you (or your ESP) can legitimately create a DKIM signature. If you want undefined and inscrutably random behavior by receivers based on your DKIM signatures, make sure they don't align to your From header and so cannot pass DMARC. The second sentence SHOULD be: If you want undefined and inscrutably random behavior by receivers NOT based on your DKIM signatures, make sure they don't align to your From header and so cannot pass DMARC. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On Thu, 2 Aug 2018 at 00:45, Laura Atkins wrote: > [...] > I’ve reached the point with Gmail that the filters are reasonably predictable > and can be managed. Even if it doesn’t make sense specifically, I’m pretty > sure the filters are acting “correctly” and that any deviation from what we > expect in delivery is a problem for the sender. It’s a black box but it’s a > consistent black box. > Microsoft is now the industry black box that everyone is struggling with. > Those filters don’t seem to be acting consistently at the moment, so it’s > really tough to figure out what the problem is. This is my "comparison" between the 2 :-) 1) Gmail: if the ESP signs every email with its own domain then its own reputation is the "key".. if this is good then even spammers sending from that ESP will get to inbox, if it is bad, even good senders will go to spam (mostly). 2) Microsoft: IP reputation have a good weight, but when recipients engaged with a previous email from a given sender they will keep receiving that sender's emails in inbox. The "per recipient" filter have much higher priority than the "reputation" filter. 1) In Gmail a good open rate will help a lot. 2) In Hotmail a low abuse report will help a lot. A good open rate may kill you, if you get it by dropping inactive subscribers, because this action will increase your "abuse ratio" (as inactive users don't report abuse). 1) Gmail will react much faster to reputation changes (few days/weeks may change a lot). 2) Hotmail is an elephant and bad reputation will be remembered for months (or even years). 1) Gmail Postmaster Tools reports bad FBL "tokens" only over a given amount: it is too high if you are monitoring small senders. 2) Hotmail FBL gives you single abuse reports but looks like they report only part of them. 1) GPT "color" seems related to the inboxing. 2) SNDS "color" sounds completely unrelated to inboxing. 1) Hotmail is hard when you have a lot of "new" recipients 2) Gmail is hard when you have a lot of "old" recipients (with low engagement due to obsolescence). The strategy that fixes Gmail will break Microsoft and viceversa... so you would need 2 different strategies. IMHO, Stefano > > laura > > > On Aug 1, 2018, at 10:22 AM, Brandon Long via mailop > wrote: > > I'd say it's unlikely that we have some list, usually we try to solve these > things based on the automatic stats we're already keeping, ie volume and > reputation and probably any number of other features of the message. > > So, it could be caused by changes in the reputation of your esp. It could > also be due to more attacks against gmail.com leading to stricter handling. > > The team still has a goal for going to quarantine and reject for gmail.com in > the long term, so tightening rules about when we consider these forgeries as > forgeries is in line with that. Not harming these types of small businesses > using esps is our largest blocker. > > Which is another way of saying that just because we're at p=none doesn't mean > forgery is a good idea, and sometimes we'll mark it as such. > > Brandon > > On Wed, Aug 1, 2018, 9:54 AM Laura Atkins wrote: >> >> I’m not actually seeing a problem here or understanding what your issue is. >> >> In terms of the forgery message. I expect that Gmail is special casing some >> ESPs (like mailchimp, and I expect there are others). So they’re allowing >> customers of those ESPs to use @gmail.com addresses in the From: line and >> are not treating that as a forgery. It makes sense, as Mailchimp (like other >> ESPs), actually confirms address ownership before allowing it to be used as >> a From: address. Because the ESPs act responsibly, Gmail doesn’t need to >> warn that the mail might be a forgery. It’s not, the ESP has assured that. >> >> If you’re sending from a different place, one with unknown policies, then >> Gmail doesn’t know anything about that, so it offers the warning. >> >> All in all, quite a sensible implementation from Gmail. >> >> What’s the problem you’re trying to solve? >> >> laura >> >> >> On Aug 1, 2018, at 8:52 AM, Emanuel Gonzalez >> wrote: >> >> Hello, thanks for the help and reply. >> >> The problem not solved. >> >> any ideas? >> >> Regards. >> >> De: Stefano Bagnara >> Enviado: miércoles, 1 de agosto de 2018 12:18:41 >> Para: mailop >> Cc: emanuel_gonza...@live.com.ar >> Asunto: Re: [mailop] Gmail change DMARC Policy? >> >> On Wed, 1 Aug 2018 at 15:26, Emanuel Gonzalez >> wro
Re: [mailop] Gmail change DMARC Policy?
Hi Bill, you misunderstood the question. Both messages (the first one and the one from Mailchimp) fails DMARC as both are sending with a gmail.com in the From and of course they both fail DMARC. BUT, the one from Mailchimp is not classified as dangerous, while the first one is classified dangerous. We (a small italian ESP) sends email for "gmail.com" senders and, like Mailchimp, we have no problem reaching inbox (or Promotions) with DMARC failing and we see not "dangerous" warning on our "dmarc failing" email. Like Brandon wrote in another comment, it probably change the behaviour depending on reputations (dkim domain reputation/ip reputation). Once Gmail.com will move to quarantine or reject then Mailchimp (and others) will start altering the From and only use the gmail.com address in the Reply-to, like they (and we) are already doing for yahoo.com (and other) senders. Stefano On Thu, 2 Aug 2018 at 00:26, Bill Cole wrote: > > On 1 Aug 2018, at 10:34 (-0400), Emanuel Gonzalez wrote: > > > Hello, thanks for the reply. I never had problems until today. > > > > > > Here the mailchimp header: > > [...] > > ARC-Authentication-Results: i=1; mx.google.com; > >dkim=pass header.i=@mail213.atl171.mcdlv.net header.s=k1 > > header.b=eLWpUpKv; > >dkim=pass header.i=@gmail.mcsv.net header.s=k1 > > header.b=Tv6+avr7; > >spf=pass (google.com: domain of > > bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net > > designates 198.2.138.213 as permitted sender) > > smtp.mailfrom="bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net"; > >dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) > > header.from=gmail.com > > That's a DMARC fail because your "From:" is not aligned to any DKIM > signature. > > [...] > > Authentication-Results: mx.google.com; > >dkim=pass header.i=@mail213.atl171.mcdlv.net header.s=k1 > > header.b=eLWpUpKv; > >dkim=pass header.i=@gmail.mcsv.net header.s=k1 > > header.b=Tv6+avr7; > >spf=pass (google.com: domain of > > bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net > > designates 198.2.138.213 as permitted sender) > > smtp.mailfrom="bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net"; > >dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) > > header.from=gmail.com > > That's a DMARC fail because your "From:" is not aligned to any DKIM > signature. > > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; > > d=mail213.atl171.mcdlv.net; > [...] > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; > > d=gmail.mcsv.net; > [...] > > Those signatures (both done by MailChimp) will only align to a From > header address in one of those 'd=' domains. > > [...] > > From: Emanuel > > That does not align to any signature, so DMARC fails. > > > But wait! There's MORE! > > > Sender: Emanuel > > If that address had been in the From header, the message might have > passed DMARC, because it aligns with a signature. > > If you want DMARC to work for your mail, use a From header for which you > (or your ESP) can legitimately create a DKIM signature. > If you want undefined and inscrutably random behavior by receivers based > on your DKIM signatures, make sure they don't align to your From header > and so cannot pass DMARC. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Currently Seeking Steadier Work: https://linkedin.com/in/billcole > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
On 1 Aug 2018, at 10:34 (-0400), Emanuel Gonzalez wrote: Hello, thanks for the reply. I never had problems until today. Here the mailchimp header: [...] ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mail213.atl171.mcdlv.net header.s=k1 header.b=eLWpUpKv; dkim=pass header.i=@gmail.mcsv.net header.s=k1 header.b=Tv6+avr7; spf=pass (google.com: domain of bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net designates 198.2.138.213 as permitted sender) smtp.mailfrom="bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net"; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com That's a DMARC fail because your "From:" is not aligned to any DKIM signature. [...] Authentication-Results: mx.google.com; dkim=pass header.i=@mail213.atl171.mcdlv.net header.s=k1 header.b=eLWpUpKv; dkim=pass header.i=@gmail.mcsv.net header.s=k1 header.b=Tv6+avr7; spf=pass (google.com: domain of bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net designates 198.2.138.213 as permitted sender) smtp.mailfrom="bounce-mc.us15_75091638.537013-emawata=gmail@mail213.atl171.mcdlv.net"; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com That's a DMARC fail because your "From:" is not aligned to any DKIM signature. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; d=mail213.atl171.mcdlv.net; [...] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=k1; d=gmail.mcsv.net; [...] Those signatures (both done by MailChimp) will only align to a From header address in one of those 'd=' domains. [...] From: Emanuel That does not align to any signature, so DMARC fails. But wait! There's MORE! Sender: Emanuel If that address had been in the From header, the message might have passed DMARC, because it aligns with a signature. If you want DMARC to work for your mail, use a From header for which you (or your ESP) can legitimately create a DKIM signature. If you want undefined and inscrutably random behavior by receivers based on your DKIM signatures, make sure they don't align to your From header and so cannot pass DMARC. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
I’m not actually seeing a problem here or understanding what your issue is. In terms of the forgery message. I expect that Gmail is special casing some ESPs (like mailchimp, and I expect there are others). So they’re allowing customers of those ESPs to use @gmail.com addresses in the From: line and are not treating that as a forgery. It makes sense, as Mailchimp (like other ESPs), actually confirms address ownership before allowing it to be used as a From: address. Because the ESPs act responsibly, Gmail doesn’t need to warn that the mail might be a forgery. It’s not, the ESP has assured that. If you’re sending from a different place, one with unknown policies, then Gmail doesn’t know anything about that, so it offers the warning. All in all, quite a sensible implementation from Gmail. What’s the problem you’re trying to solve? laura > On Aug 1, 2018, at 8:52 AM, Emanuel Gonzalez > wrote: > > Hello, thanks for the help and reply. > > The problem not solved. > > any ideas? > > Regards. > De: Stefano Bagnara mailto:mai...@bago.org>> > Enviado: miércoles, 1 de agosto de 2018 12:18:41 > Para: mailop > Cc: emanuel_gonza...@live.com.ar > Asunto: Re: [mailop] Gmail change DMARC Policy? > > On Wed, 1 Aug 2018 at 15:26, Emanuel Gonzalez > wrote: > > I have a problem with Gmail, i see a change in the dmarc header: > > [...] > > the emails sent arrive to the promotions folder but with a forgery alert > > (fake identity), when I send mails from mailchimp it does not return any > > warning haha because? > > > > header from my email marketing provider: > > > > Delivered-To: emaw...@gmail.com > > [...] > > From: GmailEnviando > > Reply-To: GmailEnviando > > > > any ideas? > > That's because sender and recipient are the same address. Try sending > to another gmail address and let us know if you see the same alert. > > -- > Stefano Bagnara > Apache James/jDKIM/jSPF > VOXmail/Mosaico.io/VoidLabs > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
Hello, thanks for the help and reply. The problem not solved. any ideas? Regards. De: Stefano Bagnara Enviado: miércoles, 1 de agosto de 2018 12:18:41 Para: mailop Cc: emanuel_gonza...@live.com.ar Asunto: Re: [mailop] Gmail change DMARC Policy? On Wed, 1 Aug 2018 at 15:26, Emanuel Gonzalez wrote: > I have a problem with Gmail, i see a change in the dmarc header: > [...] > the emails sent arrive to the promotions folder but with a forgery alert > (fake identity), when I send mails from mailchimp it does not return any > warning haha because? > > header from my email marketing provider: > > Delivered-To: emaw...@gmail.com > [...] > From: GmailEnviando > Reply-To: GmailEnviando > > any ideas? That's because sender and recipient are the same address. Try sending to another gmail address and let us know if you see the same alert. -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail change DMARC Policy?
: 40c8ed8b20f446618ea65d6dcmc list <40c8ed8b20f446618ea65d6dc.118353.list-id.mcsv.net> X-Accounttype: ff X-Original-Sender: emaw...@gmail.com List-Unsubscribe: <https://cam.us15.list-manage.com/unsubscribe?u=40c8ed8b20f446618ea65d6dc&id=9d9971d636&e=77c14f64f9&c=8e09cee022>, <mailto:unsubscribe-mc.us15_40c8ed8b20f446618ea65d6dc.8e09cee022-77c14f6...@mailin.mcsv.net?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click Sender: Emanuel x-mcda: FALSE Content-Type: multipart/alternative; boundary="_--=_MCPart_1008977730" MIME-Version: 1.0 ### Any ideas? De: Vladimir Dubrovin Enviado: miércoles, 1 de agosto de 2018 11:32:19 Para: mailop@mailop.org; Emanuel Gonzalez Asunto: Re: [mailop] Gmail change DMARC Policy? DMARC works as expected, you have authentication for 94983.senders.tstes.net, 94983.returnpath.tstes.net, gmail.tstes.net but from is emaw...@gmail.com<mailto:emaw...@gmail.com>, so DMARC fails, because neither of authentications is aligned with gmail.com. In situation like this (message has unauthenticated From address for well known domain), GMail either shows ESP information message was sent from, e.g. "via example.com" with DKIM domain (example.com in this example) for some trusted senders DKIMs or forgery warning, if message does not have DKIM from trusted sender. This behaviour is not directly DMARC-related, though it uses same technologies for authentication. In short: never use gmail.com (or any public mailbox address) to send messages via any non-GMail server, because it breaks sender (From: address) authentication. Use your own domain and configure SPF/DKIM/DMARC. 01.08.2018 16:23, Emanuel Gonzalez пишет: Hello.!!! I have a problem with Gmail, i see a change in the dmarc header: ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@94983.senders.tstes.net<mailto:header.i=@94983.senders.tstes.net> header.s=esdkim header.b=IplGe1Oe; dkim=pass header.i=@gmail.tstes.net<mailto:header.i=@gmail.tstes.net> header.s=dkim header.b=FQWgkG0I; spf=pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net<mailto:bounces-emawata=gmail@94983.returnpath.tstes.net> designates 200.58.118.64 as permitted sender) smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"<mailto:bounces-emawata=gmail@94983.returnpath.tstes.net>; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com the emails sent arrive to the promotions folder but with a forgery alert (fake identity), when I send mails from mailchimp it does not return any warning haha because? header from my email marketing provider: Delivered-To: emaw...@gmail.com<mailto:emaw...@gmail.com> Received: by 2002:a1c:e046:0:0:0:0:0 with SMTP id x67-v6csp629260wmg; Wed, 1 Aug 2018 03:56:10 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfyYYSrzx+kZi+JHyKNMIHdqm4zPxgTli5PCbvj9x9fdvZ0IPrxHrw6eOGmb/KpOyxl2/MO X-Received: by 2002:a37:69c3:: with SMTP id e186-v6mr24336280qkc.396.1533120970612; Wed, 01 Aug 2018 03:56:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533120970; cv=none; d=google.com; s=arc-20160816; b=xHS7fgzrUf9jtBZJY4Ac5SAgtJCss6O5ZPFPt9Xvu7z8sBojSmt5PpEiFPZ9+8ljhu 2P7MkvvzTou9Q8ozZOl4u5QCPYQypLZ6UOqqYE8eoWNW0InjAskFI/G9icpfxb7SYgsa BZHJP/yIVuefsl1d0PQ8peJIGjkQJIAMCXwlbzze1syem8ROJLyBmki2I2H4owW0j3/1 Gao8PyoGEVVqKCmCixJGoRWLRrE2AIRFs8nyFmvzJfdEjYpYbTnHW1iucGohCqeF3HSl z26+BtfawxmboqW4vqpKG4hidWV9+o0sm61hXMfLMNsVYmFWTUKTiBOV2paSK6qEYCY/ mUNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:to:mime-version:subject:list-unsubscribe :feedback-id:list-id:sender:reply-to:from:precedence:dkim-signature :dkim-signature:arc-authentication-results; bh=WlV74hnf502NFLfJVcfDuTEraxlb+UX5FtcE7aN1Ljk=; b=WDqnbFLtjwOitNwOIuyCEgCY5HjvbUyqbR1FcH1lTL/LyUcIMuKS1QnkpmwF0utsu8 +mYp2/9BnK0M8h5soOBAgjh6mzZW6hdxLiu/hIB6iVC1fJTNv3q08Og0CGHau2rMyFuC P3xXS/K6uQWuepYdI46KH4zOvAYG7NomnbDkxNqtr681OtI0wCAyu1YbXtzTg8/h3hfU fPU/crrsDmsKK0blcKmsqLNuuzb+ykbpMtnma89OTALqBEB189VVdtTEmegNXe3ML0qA Fs6pzbT1tLUqTMbtyf12OJwWw5gNUAortE4fiMx5cGC1rXFRKkohPA8sgD8f3lSa0M7D Ab5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@94983.senders.tstes.net<mailto:header.i=@94983.senders.tstes.net> header.s=esdkim header.b=IplGe1Oe; dkim=pass header.i=@gmail.tstes.net<mailto:header.i=@gmail.tstes.net> header.s=dkim header.b=FQWgkG0I; spf=pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net<mailto:bounces-emawata=gmail@94983.returnpath.tstes.net> designates 200.58.118.64 as
Re: [mailop] Gmail change DMARC Policy?
DMARC works as expected, you have authentication for 94983.senders.tstes.net, 94983.returnpath.tstes.net, gmail.tstes.net but from is emaw...@gmail.com, so DMARC fails, because neither of authentications is aligned with gmail.com. In situation like this (message has unauthenticated From address for well known domain), GMail either shows ESP information message was sent from, e.g. "via example.com" with DKIM domain (example.com in this example) for some trusted senders DKIMs or forgery warning, if message does not have DKIM from trusted sender. This behaviour is not directly DMARC-related, though it uses same technologies for authentication. In short: never use gmail.com (or any public mailbox address) to send messages via any non-GMail server, because it breaks sender (From: address) authentication. Use your own domain and configure SPF/DKIM/DMARC. 01.08.2018 16:23, Emanuel Gonzalez пишет: > > Hello.!!! > > > I have a problem with Gmail, i see a change in the dmarc header: > > ARC-Authentication-Results: i=1; mx.google.com; > dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim > header.b=IplGe1Oe; > dkim=pass header.i=@gmail.tstes.net header.s=dkim > header.b=FQWgkG0I; > spf=pass (google.com: domain of > bounces-emawata=gmail@94983.returnpath.tstes.net designates > 200.58.118.64 as permitted sender) > smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; > dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com > > the emails sent arrive to the promotions folder but with a forgery > alert (fake identity), when I send mails from mailchimp it does not > return any warning haha because? > > header from my email marketing provider: > > Delivered-To: emaw...@gmail.com > Received: by 2002:a1c:e046:0:0:0:0:0 with SMTP id x67-v6csp629260wmg; > Wed, 1 Aug 2018 03:56:10 -0700 (PDT) > X-Google-Smtp-Source: > AAOMgpfyYYSrzx+kZi+JHyKNMIHdqm4zPxgTli5PCbvj9x9fdvZ0IPrxHrw6eOGmb/KpOyxl2/MO > X-Received: by 2002:a37:69c3:: with SMTP id > e186-v6mr24336280qkc.396.1533120970612; > Wed, 01 Aug 2018 03:56:10 -0700 (PDT) > ARC-Seal: i=1; a=rsa-sha256; t=1533120970; cv=none; > d=google.com; s=arc-20160816; > > b=xHS7fgzrUf9jtBZJY4Ac5SAgtJCss6O5ZPFPt9Xvu7z8sBojSmt5PpEiFPZ9+8ljhu > > 2P7MkvvzTou9Q8ozZOl4u5QCPYQypLZ6UOqqYE8eoWNW0InjAskFI/G9icpfxb7SYgsa > > BZHJP/yIVuefsl1d0PQ8peJIGjkQJIAMCXwlbzze1syem8ROJLyBmki2I2H4owW0j3/1 > > Gao8PyoGEVVqKCmCixJGoRWLRrE2AIRFs8nyFmvzJfdEjYpYbTnHW1iucGohCqeF3HSl > > z26+BtfawxmboqW4vqpKG4hidWV9+o0sm61hXMfLMNsVYmFWTUKTiBOV2paSK6qEYCY/ > mUNQ== > ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; > d=google.com; s=arc-20160816; > h=message-id:date:to:mime-version:subject:list-unsubscribe > > :feedback-id:list-id:sender:reply-to:from:precedence:dkim-signature > :dkim-signature:arc-authentication-results; > bh=WlV74hnf502NFLfJVcfDuTEraxlb+UX5FtcE7aN1Ljk=; > > b=WDqnbFLtjwOitNwOIuyCEgCY5HjvbUyqbR1FcH1lTL/LyUcIMuKS1QnkpmwF0utsu8 > > +mYp2/9BnK0M8h5soOBAgjh6mzZW6hdxLiu/hIB6iVC1fJTNv3q08Og0CGHau2rMyFuC > > P3xXS/K6uQWuepYdI46KH4zOvAYG7NomnbDkxNqtr681OtI0wCAyu1YbXtzTg8/h3hfU > > fPU/crrsDmsKK0blcKmsqLNuuzb+ykbpMtnma89OTALqBEB189VVdtTEmegNXe3ML0qA > > Fs6pzbT1tLUqTMbtyf12OJwWw5gNUAortE4fiMx5cGC1rXFRKkohPA8sgD8f3lSa0M7D > Ab5g== > ARC-Authentication-Results: i=1; mx.google.com; > dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim > header.b=IplGe1Oe; > dkim=pass header.i=@gmail.tstes.net header.s=dkim > header.b=FQWgkG0I; > spf=pass (google.com: domain of > bounces-emawata=gmail@94983.returnpath.tstes.net designates > 200.58.118.64 as permitted sender) > smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; > dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com > Return-Path: > Received: from mta118.64.tstes.net (mta118.64.tstes.net. [200.58.118.64]) > by mx.google.com with ESMTPS id > x52-v6si334753qvh.260.2018.08.01.03.56.08 > for > (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); > Wed, 01 Aug 2018 03:56:10 -0700 (PDT) > Received-SPF: pass (google.com: domain of > bounces-emawata=gmail@94983.returnpath.tstes.net designates > 200.58.118.64 as permitted sender) client-ip=200.58.118.64; > Authentication-Results: mx.google.com; > dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim > header.b=IplGe1Oe; > dkim=pass header.i=@gmail.tstes.net header.s=dkim > header.b=FQWgkG0I; > spf=pass (google.com: domain of > bounces-emawata=gmail@94983.returnpath.tstes.net designates > 200.58.118.64 as permitted sender) > smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; > dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=esdkim;
Re: [mailop] Gmail change DMARC Policy?
On Wed, 2018-08-01 at 13:23 +, Emanuel Gonzalez wrote: > header.from=gmail.com DMARC fails in both cases because you are spoofing the From address as being from gmail.com when it is not. They haven't changed their DMARC policy (it's still p=none) but that does not affect the fact that message fails a DMARC test. As to why one forged message is classified differently to another, that's likely down to many data points, DMARC just being one of them. Sending newsletters / bulk emails from a forged gmail.com (or other freemail address) is going to cause problems in general. Ken. -- Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com Need to understand deliverability? Now there's a book: www.wemonitoremail.com/book ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Gmail change DMARC Policy?
Hello.!!! I have a problem with Gmail, i see a change in the dmarc header: ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim header.b=IplGe1Oe; dkim=pass header.i=@gmail.tstes.net header.s=dkim header.b=FQWgkG0I; spf=pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net designates 200.58.118.64 as permitted sender) smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com the emails sent arrive to the promotions folder but with a forgery alert (fake identity), when I send mails from mailchimp it does not return any warning haha because? header from my email marketing provider: Delivered-To: emaw...@gmail.com Received: by 2002:a1c:e046:0:0:0:0:0 with SMTP id x67-v6csp629260wmg; Wed, 1 Aug 2018 03:56:10 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfyYYSrzx+kZi+JHyKNMIHdqm4zPxgTli5PCbvj9x9fdvZ0IPrxHrw6eOGmb/KpOyxl2/MO X-Received: by 2002:a37:69c3:: with SMTP id e186-v6mr24336280qkc.396.1533120970612; Wed, 01 Aug 2018 03:56:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533120970; cv=none; d=google.com; s=arc-20160816; b=xHS7fgzrUf9jtBZJY4Ac5SAgtJCss6O5ZPFPt9Xvu7z8sBojSmt5PpEiFPZ9+8ljhu 2P7MkvvzTou9Q8ozZOl4u5QCPYQypLZ6UOqqYE8eoWNW0InjAskFI/G9icpfxb7SYgsa BZHJP/yIVuefsl1d0PQ8peJIGjkQJIAMCXwlbzze1syem8ROJLyBmki2I2H4owW0j3/1 Gao8PyoGEVVqKCmCixJGoRWLRrE2AIRFs8nyFmvzJfdEjYpYbTnHW1iucGohCqeF3HSl z26+BtfawxmboqW4vqpKG4hidWV9+o0sm61hXMfLMNsVYmFWTUKTiBOV2paSK6qEYCY/ mUNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:to:mime-version:subject:list-unsubscribe :feedback-id:list-id:sender:reply-to:from:precedence:dkim-signature :dkim-signature:arc-authentication-results; bh=WlV74hnf502NFLfJVcfDuTEraxlb+UX5FtcE7aN1Ljk=; b=WDqnbFLtjwOitNwOIuyCEgCY5HjvbUyqbR1FcH1lTL/LyUcIMuKS1QnkpmwF0utsu8 +mYp2/9BnK0M8h5soOBAgjh6mzZW6hdxLiu/hIB6iVC1fJTNv3q08Og0CGHau2rMyFuC P3xXS/K6uQWuepYdI46KH4zOvAYG7NomnbDkxNqtr681OtI0wCAyu1YbXtzTg8/h3hfU fPU/crrsDmsKK0blcKmsqLNuuzb+ykbpMtnma89OTALqBEB189VVdtTEmegNXe3ML0qA Fs6pzbT1tLUqTMbtyf12OJwWw5gNUAortE4fiMx5cGC1rXFRKkohPA8sgD8f3lSa0M7D Ab5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim header.b=IplGe1Oe; dkim=pass header.i=@gmail.tstes.net header.s=dkim header.b=FQWgkG0I; spf=pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net designates 200.58.118.64 as permitted sender) smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from mta118.64.tstes.net (mta118.64.tstes.net. [200.58.118.64]) by mx.google.com with ESMTPS id x52-v6si334753qvh.260.2018.08.01.03.56.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 03:56:10 -0700 (PDT) Received-SPF: pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net designates 200.58.118.64 as permitted sender) client-ip=200.58.118.64; Authentication-Results: mx.google.com; dkim=pass header.i=@94983.senders.tstes.net header.s=esdkim header.b=IplGe1Oe; dkim=pass header.i=@gmail.tstes.net header.s=dkim header.b=FQWgkG0I; spf=pass (google.com: domain of bounces-emawata=gmail@94983.returnpath.tstes.net designates 200.58.118.64 as permitted sender) smtp.mailfrom="bounces-emawata=gmail@94983.returnpath.tstes.net"; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=esdkim; d=94983.senders.tstes.net; h=From:Reply-To:Sender:List-ID:List-Unsubscribe:Subject:Content-Type:MIME-Version:To:Date:Message-ID; i=emawata=3dgmail@94983.senders.tstes.net; bh=WlV74hnf502NFLfJVcfDuTEraxlb+UX5FtcE7aN1Ljk=; b=IplGe1OeZMF4tC2eASRGff4gJB19X6JKtli/k1qk9I5APSELeOHHYM7tGPU1CJnyRS18iN7C2PkO v5QCCSK5arr8FNXHkBhPQ7aGkDsaJXZywC0LIXZPYMYyTHMSsRLI85k7WYg9SQJkiu/KdqiBO3Az 0ypBojLX6LrpI6yaOAI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=dkim; d=gmail.tstes.net; h=From:Reply-To:Sender:List-ID:Feedback-ID:List-Unsubscribe:Subject:Content-Type:MIME-Version:To:Date:Message-ID; bh=WlV74hnf502NFLfJVcfDuTEraxlb+UX5FtcE7aN1Ljk=; b=FQWgkG0IX0gh6SVi+1qBmOZ0gr0UchSmj+pXt4Z5VXLJCZtqEQMcG7jDp+fW5vfwK5VPX9ib6jJy FWIdddcBqphjGhC7c0evBIUGxsNZ2+Ku3q05An9Dr4M41H42nWntHCkaVIYZmtIK4Kr7D9FPr+pC JafGanE/68nqkQYWLqc= Precedence: bulk X-DM-SENDER: MAILTX From: GmailEnviando Reply-To: GmailEnviando X-DM-Tracking-Domain: 1 X-DM-Priority: 10 X-Report-Abuse: Please report abuse for this campaign here: http://envialosimple.com/abuse/ S