Daniel, again, thank you for your efforts to collect diagnostic data for
the Devuan Project, and for your care and precision.

I respect the reasons you're making DMARC work for your domain, and
certainly have no argument with you doing so (though I do not come to
the same conclusion for my own domain). A few comments that come
to mind:


Quoting Daniel Abrecht (dng@???)

> The SPF checks from the report have currently the result None, which
> usually indicates that domain does not have an SPF record. I did add
> ?mx:lists.dyne.org to my SPF record, which should have resulted in an
> SPF result of Neutral, so either the mailing list needs an SPF record,
> or google & co. are wrongly reporting a None result instead of a
> Neutral one.

Let's be careful about what we're speaking about, here. By definition,
a posting that transits a mailing list goes through two phases, where
to the best of my understanding a different SPF RR is relevant for each.

In the first phase, mail arrives at (say) the lists.dyne.org MTA
purporting to be from your domain. If the receiving MTA is checking SPF
on arriving mail, then it seeks to validate the envelope header of
arrived mail against the published SPF RR of the claimed sender domain
as reflected in the envelope. A forged mail at this point would have an
envelope claiming it's from danielabrecht.ch, but the IP would fail
vetting against your A and MX records (declared as authorised senders in
your domain's SPF RR). If it's genuine, otherwise.

The accepted posting gets handed by the receiving MTA to the MLM
software. The MLM software now remails, or to put it another way,
creates fresh mails (thus, second phase), with an entirely different
SMTP envelope reflecting the MLM's host identity. The internal 'From: '
header is (ideally) left intact, the internal 'To: ' header is
customised for each subscriber, and some number of other additions and
changes get made by the MLM software prior to handing it off to the
outbound MTA.

If subscribers' receiving MTAs now attempt, during this second phase, to
validate the SMTP envelope, they will do so based on the MLM host's
domain, not the original sender's.


> When a mail is sent, there are the envelope-to and the envelope-from
> (which aren't mail headers), but also To and From headers.[...]

Yes, I'm extremely well aware of this. The latter 'From header' is
traditionally called the internal 'From:' header to distinguish it from
the envelope 'From ' header.

I was on NANAE during the incident in which envelope forgery was
invented and demonstrated in the famous revenge-spam attack against Joe
Doll of Joe's Cyberpost.

> Normally when an SPF check is made, the envelope from address is used.
> If the mail server doesn't have an SPF header, the SPF result is None
> and the receiving mail server should accept the mail.

To my knowledge, there is no such thing as an 'SPF header' (except see
below). No extra headers get used to implement SPF. It's just a DNS RR
that declares what authorised sending MTA hosts exist, and gets used by
supporting (receiving) MTAs to vet the envelope sender. (There's also
an optional 'Authentication-Results' header that's similar, except for
recording border MTAs' results.)

My understanding is that some MTAs add a Received-SPF header to
all emails arriving via SMTP that test to any result other than 'fail'.
This is added _after_ SPF evaluation to record the results of that
check. It's advisory, and merely a place to record the result.


> There is no point in getting notified if nothing happens or everything
> works as expected, but if something didn't work or someone tried to
> send a mail in my name and failed, I certainly want to know about
> that.

Certainly your prerogative, but I personally don't care to get notified
when someone tries to forge my domain and fails, because that amounts to
getting spam about spam.

There's a reason why I've finely tuned logcheck to stop notifying me of
pointless and futile attempts to use generic username/password pairs on
my sshd, and a thousand other bits of basically meaningless noise that's
just part of the routine of having a 24x7 Internet server.


> >> 3) The recipient can check if the message content was changed
> >
> > gpg signing alone can do that.
>
> gpg and DKIM have a bit different scope.

Yes, but both can authenticate and attest to the integrity of whatever
dataset was signed. And that thus matches 'can check if the message
content was changed'. Just crypto-sign the message contents. Anything
extraneous inserted into the signed bloc will cause validation failure.
Anything outside it will be obviously _not_ attested to, and recipients
should accordingly understand that.

You might have more reasonably made the objection 'Ordinary folks won't
check PGP attestation.' Maybe not. Personally, I regard this as Not My
Problem. If I say something where text integrity really matters, like
the body of a CVE, I will PGP-sign it. Readers who care about text
integrity will check it, others won't.