Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf wrote: > On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote: > > Viktor wrote: > > > > That's because DMARC (which I don't use or recommed) > > > > Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL* > > mail sent to you in your inbox spam or not? Other than SPF records and DMARC > > what other tools exist to verify if mail came from the domain they purport > > to? Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) I suppose that means that lots of list members have DMARC checking set up. But seriously, I'd also appreciate a critique of DMARC. It seems like a reasonable attempt to solve some of the flaws with SPF and DKIM. If it fails to do that, or it has flaws of its own, I'd be interested in hearing about it. For what it's worth, anyone on these lists with SPF might want to add these to their SPF record: ip4:168.100.1.3 ip4:168.100.1.4 ip4:168.100.1.7 ip6:2604:8d00:0:1::3 ip6:2604:8d00:0:1::4 ip6:2604:8d00:0:1::7 It would be good if mailing lists published spf records that members could include: in their spf records. But I suppose most people wouldn't be able to benefit from them. cheers, raf
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote: > Here's a (silly) thing that wrong with DMARC: :-) > I've sent two messages to this mailing list so far, and > I've received 52 DMARC forensic/failure report emails > as a result! :-) Your mails are not DKIM signed, so of course they will fail. > But seriously, I'd also appreciate a critique of DMARC. > It seems like a reasonable attempt to solve some of the > flaws with SPF and DKIM. If it fails to do that, or it > has flaws of its own, I'd be interested in hearing > about it. DMARC is documented in a informational RFC, so it never got a proper standard review and you can clearly see it in every corner. On of the largest problems is the use of SPF. Bastian -- Either one of us, by himself, is expendable. Both of us are not. -- Kirk, "The Devil in the Dark", stardate 3196.1
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote: Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) On 14.07.21 09:51, Bastian Blank wrote: Your mails are not DKIM signed, so of course they will fail. which means, if you use DMARC and not DKIM, don't post to mailing lists. btw, DKIM defined very shitty canonicalication, which makes it very easy to break messages by using some common formating techniques. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese.
Re: Conditional milter_header_checks?
On 14/07/2021 08:43, raf wrote: On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf wrote: On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote: Viktor wrote: That's because DMARC (which I don't use or recommed) Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL* mail sent to you in your inbox spam or not? Other than SPF records and DMARC what other tools exist to verify if mail came from the domain they purport to? Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) I suppose that means that lots of list members have DMARC checking set up. But seriously, I'd also appreciate a critique of DMARC. It seems like a reasonable attempt to solve some of the flaws with SPF and DKIM. If it fails to do that, or it has flaws of its own, I'd be interested in hearing about it. For what it's worth, anyone on these lists with SPF might want to add these to their SPF record: ip4:168.100.1.3 ip4:168.100.1.4 ip4:168.100.1.7 ip6:2604:8d00:0:1::3 ip6:2604:8d00:0:1::4 ip6:2604:8d00:0:1::7 It would be good if mailing lists published spf records that members could include: in their spf records. But I suppose most people wouldn't be able to benefit from them. We use DMARC for our main business domains (via opendmarc and opendkim) and I am a fan. The main problems with DMARC are that it has to be set up and tested carefully before setting p=reject, and that it is broken by many mailing lists (though not, I thought, this one). ARC, a development from DMARC, is meant to provide a way round the second problem - I have not tried it. This is a mailing list so naturally many subscribers don't like DMARC! A commonly-held view is that DMARC is only worthwhile for transactional emails - for instance it is now used by most responsible financial institutions. But, even though we are not such, I hate the idea that anyone can easily send emails that perfectly fake our identity. DMARC addresses this - maybe DANE does too?
Re: Conditional milter_header_checks?
On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000) raf is rumored to have said: Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) There are 2 different and contradictory DMARC records in DNS for raf.org. That guarantees breakage. Also, publishing DMARC records at all without DNSSEC is silly. For what it's worth, anyone on these lists with SPF might want to add these to their SPF record: ip4:168.100.1.3 ip4:168.100.1.4 ip4:168.100.1.7 ip6:2604:8d00:0:1::3 ip6:2604:8d00:0:1::4 ip6:2604:8d00:0:1::7 It would be good if mailing lists published spf records that members could include: in their spf records. But I suppose most people wouldn't be able to benefit from That is not scalable, won't actually work, and would be a misuse of SPF. SPF is intended to be used with the envelope sender address and (secondarily) the HELO/EHLO hostname argument. If those do not 'align' with the header From address, DMARC will not use SPF. DMARC is designed to break the traditional practices of both simple transparent forwarding and discussion mailing lists. To do so, it allows the use of SPF in a manner it was never intended to be used, to "align" with the header From address. Since mailing lists properly use their own domain in the envelope, SPF for a mailing list delivery will never align with the author's From header. If you want to post to discussion mailing lists, you should either use a From address in a domain without any DMARC record or publish one with a p=none policy and sign your messages with DKIM, even though they are likely to be broken by the mailing list. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Bypass postscreen
Doug Hardie: > > > On 12 July 2021, at 18:27, Wietse Venema wrote: > > > > Doug Hardie: > >> I have a postfix server that uses postscreen. However, occasionally > >> a needed mail is blocked by one of the spam services. Is there a > >> way to bypass postscreen for just one or more specific addresses > >> for a short time? > > > > http://www.postfix.org/postconf.5.html#postscreen_access_list > > http://www.postfix.org/POSTSCREEN_README.html#quick > > > > I went through those earlier. I have configured: > > postscreen_access_list = permit_mynetworks, > cidr:/usr/local/etc/postfix/access.cidr You also need to set postscreen_denylist_action (or postscreen_blacklist_action). Wietse
Re: Conditional milter_header_checks?
There are 2 different and contradictory DMARC records in DNS for raf.org. That guarantees breakage. Interesting, according to [1] they shouldn't receive reports at all. [1] https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.3 point 5
Re: Conditional milter_header_checks?
It is a really bad idea to reject messages whose DKIM signature is invalid. DO NOT DO THIS. Why exactly is it a really bad idea :) ? Could you give us some more practical details/examples? The point is that absent DMARC policy that promises DKIM signatures aligned with the RFC2822.From domain, there is no sane threat model in which rejecting invalid DKIM signatures yields any security benefit. An attacker (spammer if you like), can always sign the mail with some throw-away domain, or not sign it at all. So a failed DKIM signature conveys nothing other than perhaps an operator error on the legitimate sending system, or an unexpected message transformation in transit. No spammer wastes bandwidth sending messages with broken DKIM signatures, they either sign correctly, or don't sign at all. In my opinion if a signature is present is should be valid. Always. Otherwise it loses it's whole purpose. You can certainly take a pedantic view, that's contrary to the DKIM RFCs and common sense, there's no Internet police to stop you. Just keep in mind that rejecting failed DKIM signatures has no security benefit. Hm, there is always the possibility that I misunderstood the specifications. Corrections are always welcome :). I do think, however, that my view is actually in line with the DKIM specs, although I wouldn't call it quite pedantic :) . Here is how I see it: Section 6.3 "Interpret Results/Apply Local Policy" states: "It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not." From this, one can conclude that the DKIM specification actually makes no formal recommendations on whether to reject or accept a message. The choice is up to the receiving system. Whatever the decision might be, it will still be in line with the specs and with common sense. Next, it does give some general guidelines: "In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an *unverifiable signature*; such rejection would cause severe interoperability problems." Now, *unverifiable signature* is not the same as "signature present but not valid". A signature can be unverifiable for multiple reasons, such as the temporary inability to access the key server. The "sender domain" is free to choose not to sign its messages and to not publish a DKIM record. But *if it does* sign them, *the signature should be valid*. It is common sense. "If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code." Publishing a DKIM record by the "sender domain" does in fact constitute an "implicit prior agreement" that the "sender domain" sends signed messages. So, *if present*, the signature should be valid. While this: "If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. See Section 8.15 for additional discussion." might seem like a recommendation for non-rejection to always occur when an email can not be verified, Section 8.15 shows that they are cases when delivery can be refused: "It is up to the Identity Assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the Signer), warning the recipient, *or even refusing delivery*." Again, I believe that mail handling software, such as mailing lists or intermediate relays, should fix their issues and be standard compliant instead of putting the burden on the end recipient system. Spammers are often early adopters of various email security standards. On some receiving systems there's a positive correlation between a message having a valid DKIM signature and the message being spam! I wold even go so far as to require DKIM signatures from everybody. But unfortunately that is not quite possible since there are still many who, for various reasons, can't provide a DKIM signature at all :) . Your network, your rules. I am just trying to give rational advice. On a more practical note: Indeed, our organization does handle quite a large amount of messages and transactions are very closely monitored for this kind of issues. So far, the only DKIM related issues we ever had were with a couple of poorly configured or outdated mailing list software and spammers. Lots and lots of spammers. However, depending on their configuration, the situation might be different for o
Re: Conditional milter_header_checks?
Kevin N.: > So, *if present*, the signature should be valid. A system that treats 'no signature' different from 'bad signature' or 'unverifiable signature' is broken from a security point of view. It gives an adversary more opportunties than it deserves. Wietse
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 07:08:07PM +0300, Kevin N. wrote: > > You can certainly take a pedantic view, that's contrary to the DKIM > > RFCs and common sense, there's no Internet police to stop you. Just > > keep in mind that rejecting failed DKIM signatures has no security > > benefit. > > Hm, there is always the possibility that I misunderstood the > specifications. Corrections are always welcome :). > > I do think, however, that my view is actually in line with the DKIM > specs, although I wouldn't call it quite pedantic :) . A DKIM signature conveys the origin domain in a DKIM-Signature header that most users don't see, and that (DMARC aside) need not bear any relationship to either the envelope sender address or the RFC2822.From address. * Apart from conveying potentially positive reputation information, What security benefit do you see in such a signature? * If a bad actor can choose between not signing (neutral outcome) or signing with a key that fails to verify (negative outcome), what would you expect the bad actor to do? * Given the above, what is the value of rejecting signatures that fail to verify? What class of attacks are you stopping? > "It is beyond the scope of this specification to describe what > actions an Identity Assessor can make, but mail carrying a > validated SDID presents an opportunity to an Identity Assessor > that unauthenticated email does not." > > From this, one can conclude that the DKIM specification actually makes > no formal recommendations on whether to reject or accept a message. Well, it clearly (top of page 51) suggests that DKIM validation failure SHOULD NOT it itself cause a message to be rejected. > "In general, modules that consume DKIM verification output > SHOULD NOT determine message acceptability based solely on a > lack of any signature or on an *unverifiable signature*; such > rejection would cause severe interoperability problems." > > Now, *unverifiable signature* is not the same as "signature present but > not valid". Actually, it is in this case. > The "sender domain" is free to choose not to sign its messages and to > not publish a DKIM record. There isn't "a DKIM record", there's one per selector, and until you see a signed message with a particular selector, there's no mechanism for locating any or all of a domain's DKIM signing public keys. > But *if it does* sign them, *the signature should be valid*. It is > common sense. It is a common mistake. Some of a domain's mail (some transactional or opted-in marketing) traffic may be signed under various selectors, and the rest might not. The RFC2822.From of signed messages may differ from the DKIM "d=" domain. Absent DMARC, a DKIM signature just tells which domain potentially takes *responsibility* for sending the message. When the signatuer check fails, you can't make that connection. That's all. The message may be transformed in some manner in transit that invalidates the signature, sometimes right from the start if the sending domain has software that first signs, and then does 8-bit to 7-bit downgrade, or adds a footer, ... Sure they should not do that, but this is not a good reason to seek to "punish" them for this. > Publishing a DKIM record by the "sender domain" does in fact constitute > an "implicit prior agreement" that the "sender domain" sends signed > messages. So, *if present*, the signature should be valid. Actually, no. It just makes it possible to take responsibility for *some* messages. They might for example not choose to take responsibility for bounces (whose returned body they did not author). > "If the email cannot be verified, then it SHOULD be treated the > same as all unverified email, regardless of whether or not it > looks like it was signed. > > See Section 8.15 for additional discussion." > > might seem like a recommendation for non-rejection to always occur when > an email can not be verified, Section 8.15 shows that they are cases > when delivery can be refused: That's the only sensible, non-pedantic, policy. > "It is up to the Identity Assessor or some other > subsequent agent to act on such messages as needed, such as > degrading the trust of the message (or, indeed, of the Signer), > warning the recipient, *or even refusing delivery*." > > Again, I believe that mail handling software, such as mailing lists or > intermediate relays, should fix their issues and be standard compliant > instead of putting the burden on the end recipient system. You can do what you want, but (DMARC or other sender-domain-specific policy context aside) there's no threat model in which refusing the message makes sense. > > Your network, your rules. I am just trying to give rational advice. > > On a more practical note: Indeed, our organization does handle quite a > large amount of messages and transactions are very closely monitored for > this k
Re: Conditional milter_header_checks?
You can certainly take a pedantic view, that's contrary to the DKIM RFCs and common sense, there's no Internet police to stop you. Just keep in mind that rejecting failed DKIM signatures has no security benefit. Hm, there is always the possibility that I misunderstood the specifications. Corrections are always welcome :). I do think, however, that my view is actually in line with the DKIM specs, although I wouldn't call it quite pedantic :) . A DKIM signature conveys the origin domain in a DKIM-Signature header that most users don't see, and that (DMARC aside) need not bear any relationship to either the envelope sender address or the RFC2822.From address. Yes, you are correct. Nowhere have I stated otherwise. * Apart from conveying potentially positive reputation information, What security benefit do you see in such a signature? * If a bad actor can choose between not signing (neutral outcome) or signing with a key that fails to verify (negative outcome), what would you expect the bad actor to do? * Given the above, what is the value of rejecting signatures that fail to verify? What class of attacks are you stopping? "It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not." From this, one can conclude that the DKIM specification actually makes no formal recommendations on whether to reject or accept a message. Even if there is no additional security benefit, there is no reason why such messages should pollute the receiving systems. Well, it clearly (top of page 51) suggests that DKIM validation failure SHOULD NOT it itself cause a message to be rejected. "In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an *unverifiable signature*; such rejection would cause severe interoperability problems." Now, *unverifiable signature* is not the same as "signature present but not valid". Actually, it is in this case. No, it is not. Meaning of words does matter. The "sender domain" is free to choose not to sign its messages and to not publish a DKIM record. There isn't "a DKIM record", there's one per selector, and until you see a signed message with a particular selector, there's no mechanism for locating any or all of a domain's DKIM signing public keys. You are correct again. And again, nowhere have I stated that such a locator mechanism is available. You can nitpick at the unfortunately chosen "a DKIM record" expression if you want but the idea still stands. Also, loosely speaking, "one per selector" is still "a DKIM record". But *if it does* sign them, *the signature should be valid*. It is common sense. It is a common mistake. Some of a domain's mail (some transactional or opted-in marketing) traffic may be signed under various selectors, and the rest might not. The RFC2822.From of signed messages may differ from the DKIM "d=" domain. Absent DMARC, a DKIM signature just tells which domain potentially takes *responsibility* for sending the message. When the signatuer check fails, you can't make that connection. That's all. The message may be transformed in some manner in transit that invalidates the signature, sometimes right from the start if the sending domain has software that first signs, and then does 8-bit to 7-bit downgrade, or adds a footer, ... Sure they should not do that, but this is not a good reason to seek to "punish" them for this. Publishing a DKIM record by the "sender domain" does in fact constitute an "implicit prior agreement" that the "sender domain" sends signed messages. So, *if present*, the signature should be valid. Actually, no. It just makes it possible to take responsibility for *some* messages. They might for example not choose to take responsibility for bounces (whose returned body they did not author). "If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. See Section 8.15 for additional discussion." might seem like a recommendation for non-rejection to always occur when an email can not be verified, Section 8.15 shows that they are cases when delivery can be refused: That's the only sensible, non-pedantic, policy. "It is up to the Identity Assessor or some other subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the Signer), warning the recipient, *or even refusing delivery*." Again, I believe that mail handling software, such as mailing lists or intermediate relays, should fix their issues and be standard compliant instead of putting the burden on the
Re: Stopping backscatter spam to a specific domain
On Jul 13, 2021, at 2:15 AM, Matus UHLAR - fantomas wrote: >> On Jul 11, 2021, at 1:06 PM, Claus R. Wickinghoff >> wrote: >>> I think this can be achieved with reject_unverified_recipient to query >>> dovecot via lmtp but I've no practical experience with this. Probably >>> you've to do some googling... > > On 12.07.21 10:19, Ron Garret wrote: >> That turned out to be the Right Answer. I simply added >> reject_unverified_recipient to smtpd_recipient_restrictions and that fixed >> the problem. >> >> The chain of events that led to this problem is kind of interesting. What >> happened was that I migrated my email server from one machine, where it >> had been running with no problem for many years, to a new machine at a new >> provider. I had simply copied the main.cf file from the old machine to >> the new one, but changed the delivery mechanism from direct delivery (i.e. >> postfix as LDA) to LMTP (i.e. dovecot as LDA). So what was happening >> before (I think) is that postfix was looking up users in the user DB, not >> because of smtpd_recipient_restrictions (because I didn’t have that set) >> but because it had to in order to deliver local messages. When I switched >> to LMTP that was no longer the case. Postfix now thought it was possible >> to deliver to non-existent users, and that’s what resulted in the >> backscatter. > > it MAY still be possible to set up postfix to read local recipients from > database dovecot uses. > Look at local_recipient_maps directive if it's possible, depends on your > dovecot setup. > > reject_unverified_recipient requires verifying each recipient and keep track > of them (deliverable or not) which is useful for cases where you can not use > local_recipient_maps Yes, it is certainly possible to set up postfix to read local recipients from the same DB that dovecot uses. And in fact that is how I had it set up on my previous server. However, on my previous server I was using MySQL and when I switched to the new server I decided to try switching to SQLite3. That turned out to be a very fateful decision because of how SQLite handles simultaneous access from multiple processes to the same DB. It’s a long story, but the upshot is that setting up Postfix and Dovecot to use the same DB causes intermittent errors which in turn cause Postfix to lose mail, which is Bad. That was the problem that originally caused me to move to LMTP in the first place. See this thread: http://postfix.1071664.n5.nabble.com/What-is-the-right-way-to-update-a-postfix-sqlite-database-td109636.html If you want the gory details. rg
Re: Bypass postscreen
> On 14 July 2021, at 06:12, Wietse Venema wrote: > > Doug Hardie: >> >>> On 12 July 2021, at 18:27, Wietse Venema wrote: >>> >>> Doug Hardie: I have a postfix server that uses postscreen. However, occasionally a needed mail is blocked by one of the spam services. Is there a way to bypass postscreen for just one or more specific addresses for a short time? >>> >>> http://www.postfix.org/postconf.5.html#postscreen_access_list >>> http://www.postfix.org/POSTSCREEN_README.html#quick >>> >> >> I went through those earlier. I have configured: >> >> postscreen_access_list = permit_mynetworks, >>cidr:/usr/local/etc/postfix/access.cidr > > You also need to set postscreen_denylist_action (or > postscreen_blacklist_action). > > Wietse Perhaps I am a bit confused. The web page says: To use the postscreen(8) service to block mail, edit main.cf and specify one or more of: • "postscreen_dnsbl_action = enforce", to reject clients that are on DNS blocklists, and to log the helo/sender/recipient information. With good DNSBLs this reduces the amount of load on Postfix SMTP servers dramatically. • "postscreen_greet_action = enforce", to reject clients that talk before their turn, and to log the helo/sender/recipient information. This stops over half of all known-to-be illegitimate connections to Wietse's mail server. It is backup protection for zombies that haven't yet been denylisted. I have both of those set to enforce. Here is the complete postscreen section of main.cf: # postscreen spam filtering postscreen_greet_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org b.barracudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # That seems to work as I see numerous spam being blocked by those dnsbl sites. Am I missing something? -- Doug
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 09:51:25AM +0200, Bastian Blank wrote: > On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote: > > Here's a (silly) thing that wrong with DMARC: :-) > > I've sent two messages to this mailing list so far, and > > I've received 52 DMARC forensic/failure report emails > > as a result! :-) > > Your mails are not DKIM signed, so of course they will fail. My DMARC policy deliberately only reports on SPF failures for that very reason. If the absence of a DKIM signature constitutes a DMARC+DKIM failure and hence a DMARC failure, even though the "reporting policy" is to only report on SPF failures, then that's a pity. My intention was to state clearly that I only use SPF and not DKIM. Perhaps it's not possible to do that. When reading up on it all ages ago, I was lead to believe that that's how DMARC worked. Also, that fact that adding SPF-only DMARC at work did fix a problem with a client's third-party mail provider that was treating our emails as spam before we added it, but started accepting them afterwards. Their (admittedly dodgy) implementation seemed to agree with my interpretation of what I'd read. > > But seriously, I'd also appreciate a critique of DMARC. > > It seems like a reasonable attempt to solve some of the > > flaws with SPF and DKIM. If it fails to do that, or it > > has flaws of its own, I'd be interested in hearing > > about it. > > DMARC is documented in a informational RFC, so it never got a proper > standard review and you can clearly see it in every corner. On of the > largest problems is the use of SPF. Clearly, I really need to read the RFC. :-) Other explanations online don't seem to do a good enough job of explaining it. Thanks. > Bastian cheers, raf
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 10:03:00AM +0200, Matus UHLAR - fantomas wrote: > > On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote: > > > Here's a (silly) thing that wrong with DMARC: :-) > > > I've sent two messages to this mailing list so far, and > > > I've received 52 DMARC forensic/failure report emails > > > as a result! :-) > > On 14.07.21 09:51, Bastian Blank wrote: > > Your mails are not DKIM signed, so of course they will fail. > > which means, if you use DMARC and not DKIM, don't post to mailing lists. It depends on the list. I guess most of the lists I post to must replace the From: address with the list address. > btw, DKIM defined very shitty canonicalication, which makes it very easy to > break messages by using some common formating techniques. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > The early bird may get the worm, but the second mouse gets the cheese.
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole wrote: > On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000) > raf > is rumored to have said: > > > Here's a (silly) thing that wrong with DMARC: :-) > > I've sent two messages to this mailing list so far, and > > I've received 52 DMARC forensic/failure report emails > > as a result! :-) > > There are 2 different and contradictory DMARC records in DNS for raf.org. > That guarantees breakage. I think it's in the process of propagating. I don't know what's taking it so long. > Also, publishing DMARC records at all without DNSSEC is silly. > > > For what it's worth, anyone on these lists with SPF > > might want to add these to their SPF record: > > ip4:168.100.1.3 > > ip4:168.100.1.4 > > ip4:168.100.1.7 > > ip6:2604:8d00:0:1::3 > > ip6:2604:8d00:0:1::4 > > ip6:2604:8d00:0:1::7 > > > > It would be good if mailing lists published spf records > > that members could include: in their spf records. But I > > suppose most people wouldn't be able to benefit from > > That is not scalable, won't actually work, and would be a misuse of SPF. Yes, I was being silly. > SPF is intended to be used with the envelope sender address and > (secondarily) the HELO/EHLO hostname argument. If those do not 'align' > with the header From address, DMARC will not use SPF. When you say "DMARC will not use SPF", does that mean that a difference between the envelope address and the From: address constitutes a DMARC+SPF failure? And specifically, a failure relating to the From: domain? Is it a DMARC+SPF failure relating to the envelope domain as well? i.e. could failure reports be sent to both domains if both "reporting policies" requested it? > DMARC is designed to break the traditional practices of both simple > transparent forwarding and discussion mailing lists. To do so, it allows the > use of SPF in a manner it was never intended to be used, to "align" with the > header From address. Since mailing lists properly use their own domain in > the envelope, SPF for a mailing list delivery will never align with the > author's From header. > > If you want to post to discussion mailing lists, you should either use a > From address in a domain without any DMARC record or publish one with a > p=none policy and sign your messages with DKIM, even though they are likely > to be broken by the mailing list. My policy is p=none. Hopefully, that'll be sufficient to limit any damage. Thanks. > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire cheers, raf
Re: Conditional milter_header_checks?
Please keep replies on-list only. Duplicates of anything sent to the list are just a nuisance. On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000) raf is rumored to have said: On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole wrote: On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000) raf is rumored to have said: Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) There are 2 different and contradictory DMARC records in DNS for raf.org. That guarantees breakage. I think it's in the process of propagating. I don't know what's taking it so long. Your primary nameserver is returning 2 TXT records for _dmarc.raf.org, so this is not a propagation issue. [...] SPF is intended to be used with the envelope sender address and (secondarily) the HELO/EHLO hostname argument. If those do not 'align' with the header From address, DMARC will not use SPF. When you say "DMARC will not use SPF", does that mean that a difference between the envelope address and the From: address constitutes a DMARC+SPF failure? Yes. Best explanation I've seen: https://mxtoolbox.com/dmarc/spf/spf-alignment And specifically, a failure relating to the From: domain? DMARC is always relating to the From header address. If the envelope sender (often: Return-Path) is verified by SPF and aligns with the From header address, DMARC passes. If there is a valid DKIM signature for a domain which aligns with the From header address, DMARC passes. Is it a DMARC+SPF failure relating to the envelope domain as well? i.e. could failure reports be sent to both domains if both "reporting policies" requested it? Have you considered reading the RFC for yourself? https://datatracker.ietf.org/doc/html/rfc7489 DMARC is designed to break the traditional practices of both simple transparent forwarding and discussion mailing lists. To do so, it allows the use of SPF in a manner it was never intended to be used, to "align" with the header From address. Since mailing lists properly use their own domain in the envelope, SPF for a mailing list delivery will never align with the author's From header. If you want to post to discussion mailing lists, you should either use a From address in a domain without any DMARC record or publish one with a p=none policy and sign your messages with DKIM, even though they are likely to be broken by the mailing list. My policy is p=none. Hopefully, that'll be sufficient to limit any damage. Based on other traffic here in a collateral subthread in the past day, it is not. At least one person running a mail server and discussing their choices in public is convinced that if your message is reformatted in transit in any way or if mailing list software adds anything to the body or Subject, your now-broken signature is a sound reason to reject your message arriving via a mailing list, because "there is no reason why such messages should pollute the receiving systems." The resulting damage should be isolated to his system. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Conditional milter_header_checks?
Please keep replies on-list only. Duplicates of anything sent to the list are just a nuisance. On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000) raf is rumored to have said: On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole wrote: On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000) raf is rumored to have said: Here's a (silly) thing that wrong with DMARC: :-) I've sent two messages to this mailing list so far, and I've received 52 DMARC forensic/failure report emails as a result! :-) There are 2 different and contradictory DMARC records in DNS for raf.org. That guarantees breakage. I think it's in the process of propagating. I don't know what's taking it so long. Your primary nameserver is returning 2 TXT records for _dmarc.raf.org, so this is not a propagation issue. [...] SPF is intended to be used with the envelope sender address and (secondarily) the HELO/EHLO hostname argument. If those do not 'align' with the header From address, DMARC will not use SPF. When you say "DMARC will not use SPF", does that mean that a difference between the envelope address and the From: address constitutes a DMARC+SPF failure? Yes. Best explanation I've seen: https://mxtoolbox.com/dmarc/spf/spf-alignment And specifically, a failure relating to the From: domain? DMARC is always relating to the From header address. If the envelope sender (often: Return-Path) is verified by SPF and aligns with the From header address, DMARC passes. If there is a valid DKIM signature for a domain which aligns with the From header address, DMARC passes. Is it a DMARC+SPF failure relating to the envelope domain as well? i.e. could failure reports be sent to both domains if both "reporting policies" requested it? Have you considered reading the RFC for yourself? https://datatracker.ietf.org/doc/html/rfc7489 DMARC is designed to break the traditional practices of both simple transparent forwarding and discussion mailing lists. To do so, it allows the use of SPF in a manner it was never intended to be used, to "align" with the header From address. Since mailing lists properly use their own domain in the envelope, SPF for a mailing list delivery will never align with the author's From header. If you want to post to discussion mailing lists, you should either use a From address in a domain without any DMARC record or publish one with a p=none policy and sign your messages with DKIM, even though they are likely to be broken by the mailing list. My policy is p=none. Hopefully, that'll be sufficient to limit any damage. Based on other traffic here in a collateral subthread in the past day, it is not. At least one person running a mail server and discussing their choices in public is convinced that if your message is reformatted in transit in any way or if mailing list software adds anything to the body or Subject, your now-broken signature is a sound reason to reject your message arriving via a mailing list, because "there is no reason why such messages should pollute the receiving systems." The resulting damage should be isolated to his system. You obviously misunderstood the sub-thread you mention. Cheers, K.
Re: Conditional milter_header_checks?
On Wed, Jul 14, 2021 at 09:34:22PM -0400, Bill Cole wrote: > Please keep replies on-list only. Duplicates of anything sent to the list > are just a nuisance. Will do. That's my preference too, but different lists have different opinions about that. > On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000) > raf > is rumored to have said: > > > On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole > > wrote: > > > > > On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000) > > > raf > > > is rumored to have said: > > > > > > > Here's a (silly) thing that wrong with DMARC: :-) > > > > I've sent two messages to this mailing list so far, and > > > > I've received 52 DMARC forensic/failure report emails > > > > as a result! :-) > > > > > > There are 2 different and contradictory DMARC records in DNS for > > > raf.org. > > > That guarantees breakage. > > > > I think it's in the process of propagating. > > I don't know what's taking it so long. > > Your primary nameserver is returning 2 TXT records for _dmarc.raf.org, so > this is not a propagation issue. Thanks. It's fixed now (and the propagation issue as well). > [...] > > > SPF is intended to be used with the envelope sender address and > > > (secondarily) the HELO/EHLO hostname argument. If those do not > > > 'align' > > > with the header From address, DMARC will not use SPF. > > > > When you say "DMARC will not use SPF", does that mean > > that a difference between the envelope address and the > > From: address constitutes a DMARC+SPF failure? > > Yes. Best explanation I've seen: > https://mxtoolbox.com/dmarc/spf/spf-alignment > > > And > > specifically, a failure relating to the From: domain? > > DMARC is always relating to the From header address. > > If the envelope sender (often: Return-Path) is verified by SPF and aligns > with the From header address, DMARC passes. > > If there is a valid DKIM signature for a domain which aligns with the From > header address, DMARC passes. > > > Is it a DMARC+SPF failure relating to the envelope > > domain as well? i.e. could failure reports be sent to > > both domains if both "reporting policies" requested it? > > Have you considered reading the RFC for yourself? > https://datatracker.ietf.org/doc/html/rfc7489 Yes. Will do. Thanks for being as generous with your time as you have been. I'll stop now. :-) > > > DMARC is designed to break the traditional practices of both simple > > > transparent forwarding and discussion mailing lists. To do so, it > > > allows the > > > use of SPF in a manner it was never intended to be used, to "align" > > > with the > > > header From address. Since mailing lists properly use their own > > > domain in > > > the envelope, SPF for a mailing list delivery will never align with > > > the > > > author's From header. > > > > > > If you want to post to discussion mailing lists, you should either > > > use a > > > From address in a domain without any DMARC record or publish one > > > with a > > > p=none policy and sign your messages with DKIM, even though they are > > > likely > > > to be broken by the mailing list. > > > > My policy is p=none. Hopefully, that'll be sufficient to limit any > > damage. > > Based on other traffic here in a collateral subthread in the past day, it is > not. At least one person running a mail server and discussing their choices > in public is convinced that if your message is reformatted in transit in any > way or if mailing list software adds anything to the body or Subject, your > now-broken signature is a sound reason to reject your message arriving via a > mailing list, because "there is no reason why such messages should pollute > the receiving systems." The resulting damage should be isolated to his > system. I meant it in the context of a continued absence of DKIM signatures. > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire cheers, raf
