no more subject prefix for xetex mailing list
zdenek.wagner at gmail.com
Tue Mar 5 03:13:11 CET 2019
your description is exact but I do not agree that there is not a huge
problem. Gmail accepts majority of such mails. Only if I display the
original message, I can see DKIM FAIL and DMARC FAIL. However, I had
problems with forwarded messages and important invoices were not
delivered and I was penalized for not paying on time because the mail
with the invoice was rejected by gmail. I have a mailserver for
math-gnostics.eu at seznam.cz which has a very strict policy. If the
result for an incoming mail is DKIM FAIL + DMARC FAIL, the mail is
rejected and I am not informed that a mail was rejected
út 5. 3. 2019 v 2:36 odesílatel <mskala at ansuz.sooke.bc.ca> napsal:
> On Tue, 5 Mar 2019, Zdenek Wagner wrote:
> > DMARC can be set as one of the following ways:
> > * The mail is valid if at least one of SPF and DKIM passes
> > * If the mail is signed, it is valid if both SPF and DKIM pass
> > Let's assume that we have the latter case and we try to "solve" it by
> > changing the From header to something at tug.org. Now the mail is sent
> > from @tug.org but is signed by a key from @example.com, hence DKIM
> > fails.
> As described in RFC 7489 section 6.6.3, the RFC5322.From domain is queried
> for the DMARC policy to apply. If that returns nothing, there is a
> fallback to the "Organizational Domain" of the RFC5322.From but it still
> has to come from the RFC5322.From domain. That means that if there's a
> policy on "tug.org" but not on "foo.bar.tug.org," then a message From: an
> @foo.bar.tug.org address is required by DMARC to be handled under the
> policy of tug.org. But that's the only way in which a policy other than
> that of the exact domain in the From: header can ever be applied by a
> compliant implementation.
> [From RFC 7489:]
> 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the
> DNS domain matching the one found in the RFC5322.From domain in
> the message. A possibly empty set of records is returned.
> 2. Records that do not start with a "v=" tag that identifies the
> current version of DMARC are discarded.
> 3. If the set is now empty, the Mail Receiver MUST query the DNS for
> a DMARC TXT record at the DNS domain matching the Organizational
> Domain in place of the RFC5322.From domain in the message (if
> different). This record can contain policy to be asserted for
> subdomains of the Organizational Domain. A possibly empty set of
> records is returned.
> 4. Records that do not start with a "v=" tag that identifies the
> current version of DMARC are discarded.
> 5. If the remaining set contains multiple records or no records,
> policy discovery terminates and DMARC processing is not applied
> to this message.
> If a user from example.com, which domain signs with DKIM and sets a
> restrictive policy, sends mail to the list and the list rewrites the From:
> header to an @tug.org address, then the RFC5322.From domain will be
> "tug.org" and only the DMARC policy published by tug.org will be used to
> determine handling by an RFC 7489 compliant recipient. DKIM does not pass
> if tug.org didn't sign, passes if tug.org did sign, but either way it is
> tug.org's policy (or lack thereof) that determines handling. The policy
> of example.com is out of the picture entirely, and DKIM signatures from
> example.com still attached to the message cannot be used to determine
> handling by a compliant recipient.
> Of course there can be non-compliant recipients out there, and there could
> be other behaviour with recipients that implement SPF or DKIM without
> DMARC, and for the benefit of such recipients it might be a good idea to
> strip off incoming DKIM signatures. But I don't think that's terribly
> important. Random extra DKIM signatures from unaligned domains are not
> rare in the wild and they don't seem to be causing huge problems; at the
> very least, just rewriting From: without stripping incoming signatures
> would be a big improvement over the current situation of the XeTeX list.
> Matthew Skala
> mskala at ansuz.sooke.bc.ca People before tribes.
More information about the XeTeX