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 (d...@danielabrecht.ch) > 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng