no more subject prefix for xetex mailing list

[Julian Bradfield]

On 2019-03-05, Zdenek Wagner <zdenek.wagner at gmail.com> wrote:

[ Please don't top-post. ]

> Now assume that somebody at nodkim.org sned a mail to the list.
> @nodkim.org has neither DKIM nor DMARC. The mail is distributed to the
> subscribers. SPF passes, @nodkim.org does not provide DKIM and there
> are no headers. There is thus nothing to verify and the recipient just
> reports that SPF passes, there is nothing else what can be done.
> Rewritingt From does no harm but it is of no use.

Correct.

> Now assume that user at example.com does the same but @example.com
> defines DKIM and DMARC. The message is signed, the list of signed
> headers is defined by @example.com. This mail is then distributed to
> subscribers and some headers are added and/or modified. The
> subscribers first verify SPF which passes. Further it finds the DKIM
> headers. They contain the identifier of the key. The ley id and the
> domain name define the URI of the TXT record containing the public key
> and the list of the headers that are signed by the original sender. It
> is possible to signed an empty (missing) header which means that the
> mailing list is not allowed to add such a header because it
> invalidates the signature.
>
> * If the mailing list adds/modifies headers that were not signed by
> the original sender, the signature remains valid and DKIM passes.
> * If the signed contents is modified, the signature is no longer valid
> and DKIM fails

DKIM verification of that signature fails, yes.

> 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.

If you don't also sign the modified message with a TUG key, DKIM
fails; but for DMARC purposes, since the signature is not from the
From: domain, it's the same as a missing signature.

> 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

No it can't. DMARC passes if at least one of the Authenticated
Identifiers passes. There is no mechanism to require both SPF and DKIM
to pass (though you can request reports of failed signatures even for
messages that pass DMARC).
Your own mail server may internally choose to reject messages that
fail DKIM, but that's not part of DMARC.

> If the From header is rewritten to something at tug.org and DMARC at
> tug.org is set to the former option, the result will be SPF PASS, DKIM
> FAIL, DMARC PASS and the recipients will thus silently accept mails
> with invalid signatures. This overcomes the problem with DKIM but IMHO
> allowing to accept messages with invalid signatures is not the right
> way. The mailing list must remove existing DKIM signature, change the
>>From header and then either provide its own DKIM + DMARC and sign the
> mail or do not provide them at all and rely on SPF only.

This is what I said - it is a good idea to clean out any invalid
signatures. But failing a signature from example.com will not affect
the DMARC checking for tug.org, and in real life, quite a few messages
arrive with some broken signatures, because of mailing lists,
forwarding, character-encoding changes, and so on.

> And the last thing, setting of DMARC at tug.org is wrong, the DNS
> query returns the SPF record, not the DMARC record.

No, it isn't wrong - there is no setting for DMARC.
A dns query for _dmarc.tug.org TXT records returns two records:

_dmarc.tug.org.         8555    IN      CNAME   tug.org.
tug.org.                8555    IN      TXT     "v=spf1 a a:freefriends.org mx:freefriends.org a:fencepost.gnu.org include:_spf.google.com ~all"

tug.org has a wildcard CNAME *.tug.org -> tug.org (which strikes me as
bad practice, but not wrong).

DMARC does not specify whether CNAMEs should be followed, but even if
they are, DMARC only looks at valid DMARC records.