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

Reply via email to