-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
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
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
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
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
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
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
at, 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
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;
anuel_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 b
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
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<m
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
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;
14 matches
Mail list logo
