Re: [mailop] Gmail change DMARC Policy?

2018-08-03 Thread Carl Byington
-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?

2018-08-02 Thread Brandon Long via mailop
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?

2018-08-02 Thread Bill Cole

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?

2018-08-02 Thread Brandon Long via mailop
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?

2018-08-02 Thread Bill Cole

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?

2018-08-02 Thread Stefano Bagnara
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?

2018-08-02 Thread Bill Cole

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?

2018-08-02 Thread Stefano Bagnara
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
>>  wrote:
>> > I have a problem w

Re: [mailop] Gmail change DMARC Policy?

2018-08-01 Thread Bill Cole

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?

2018-08-01 Thread Laura Atkins
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?

2018-08-01 Thread Emanuel Gonzalez
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?

2018-08-01 Thread Emanuel Gonzalez
8b20f446618ea65d6dcmc 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=9d9971d636=77c14f64f9=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 permitted sender) 
smtp.mailfrom=&

Re: [mailop] Gmail change DMARC Policy?

2018-08-01 Thread Ken O'Driscoll via mailop
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