Milters and policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Milters and policy

Simon Wilson-7
Quick question please:

Which does Postfix run first - a milter specified in smtpd_milters or  
a check_policy_service in smtpd_recipient_restrictions?

I.e.:
#OpenDKIM
smtpd_milters           = inet:127.0.0.1:8891
...

smtpd_recipient_restrictions =
...
# python-policyd-spf
         check_policy_service unix:private/policyd-spf
         permit

Thanks.

--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Benny Pedersen-2
On 2021-04-01 01:43, Simon Wilson wrote:
> Quick question please:
>
> Which does Postfix run first - a milter specified in smtpd_milters or
> a check_policy_service in smtpd_recipient_restrictions?

milters is run after check policy service, to keep performance at top

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Simon Wilson-7
----- Message from Benny Pedersen <[hidden email]> ---------
    Date: Thu, 01 Apr 2021 01:50:15 +0200
    From: Benny Pedersen <[hidden email]>
Subject: Re: Milters and policy
      To: [hidden email]


> On 2021-04-01 01:43, Simon Wilson wrote:
>> Quick question please:
>>
>> Which does Postfix run first - a milter specified in smtpd_milters or
>> a check_policy_service in smtpd_recipient_restrictions?
>
> milters is run after check policy service, to keep performance at top

Thank you sir...

I just found this too which helped:  
https://groups.google.com/g/mailing.postfix.users/c/3vGc-RMYV94/m/W3xYtyiovQcJ

"...The Milter comes after smtpd/cleanup. Wietse"

So in my config above, the SPF policy is run before OpenDKIM milter is called.

Simon.

--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Simon Wilson-7
>>> Quick question please:
>>>
>>> Which does Postfix run first - a milter specified in smtpd_milters or
>>> a check_policy_service in smtpd_recipient_restrictions?
>>
>> milters is run after check policy service, to keep performance at top
>
> Thank you sir...
>
> I just found this too which helped:  
> https://groups.google.com/g/mailing.postfix.users/c/3vGc-RMYV94/m/W3xYtyiovQcJ
>
> "...The Milter comes after smtpd/cleanup. Wietse"
>
> So in my config above, the SPF policy is run before OpenDKIM milter  
> is called.
>
> Simon.

...if multiple milters are called are they run in order specified?

smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893

I.e. in the example above if OpenDMARC is to see and trust an  
already-run OpenDKIM Authentication-Results header is the order of  
specifying the milters important?

Simon

--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Benny Pedersen-2
On 2021-04-01 02:29, Simon Wilson wrote:

> ...if multiple milters are called are they run in order specified?
>
> smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893

yes

> I.e. in the example above if OpenDMARC is to see and trust an
> already-run OpenDKIM Authentication-Results header is the order of
> specifying the milters important?

yes opendkim need to run before opendmarc, and if you have openarc place
that before opendkim, it can be messy if opendmarc checks openarc
results, remeber it also need to trust AR headers to be considered good
info

but i do not use milters self, only do all i need with fuglu
Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Simon Wilson-7
>> ...if multiple milters are called are they run in order specified?
>>
>> smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893
>
> yes
>
>> I.e. in the example above if OpenDMARC is to see and trust an
>> already-run OpenDKIM Authentication-Results header is the order of
>> specifying the milters important?
>
> yes opendkim need to run before opendmarc, and if you have openarc  
> place that before opendkim, it can be messy if opendmarc checks  
> openarc results, remeber it also need to trust AR headers to be  
> considered good info
>
> but i do not use milters self, only do all i need with fuglu

Thanks again Benny. I have policyd-spf set to insert an AR header, and  
OpenDMARC set to trust the Authserv-Id added in Authentication-Results  
headers by policyd-spf and OpenDKIM. All working nicely and good to  
understand the sequence.

Simon.

--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Dan Mahoney (Gushi)


> On Mar 31, 2021, at 18:23, Simon Wilson <[hidden email]> wrote:
>
> 
>>
>>> ...if multiple milters are called are they run in order specified?
>>>
>>> smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893
>>
>> yes
>>
>>> I.e. in the example above if OpenDMARC is to see and trust an
>>> already-run OpenDKIM Authentication-Results header is the order of
>>> specifying the milters important?
>>
>> yes opendkim need to run before opendmarc, and if you have openarc place that before opendkim, it can be messy if opendmarc checks openarc results, remeber it also need to trust AR headers to be considered good info
>>
>> but i do not use milters self, only do all i need with fuglu
>
> Thanks again Benny. I have policyd-spf set to insert an AR header, and OpenDMARC set to trust the Authserv-Id added in Authentication-Results headers by policyd-spf and OpenDKIM. All working nicely and good to understand the sequence.

Please read CVE-2019-20790, and tell me you’ve found a way to tell PyPolicyd not to trust the SMTP HELO to generate a passing AR header.

-Dan


>
> Simon.
>
> --
> Simon Wilson
> M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Simon Wilson-7
----- Message from Dan Mahoney <[hidden email]> ---------
    Date: Thu, 1 Apr 2021 16:19:05 -0700
    From: Dan Mahoney <[hidden email]>
Subject: Re: Milters and policy
      To: [hidden email]
      Cc: [hidden email]


>> On Mar 31, 2021, at 18:23, Simon Wilson <[hidden email]> wrote:
>>
>> 
>>>
>>>> ...if multiple milters are called are they run in order specified?
>>>>
>>>> smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893
>>>
>>> yes
>>>
>>>> I.e. in the example above if OpenDMARC is to see and trust an
>>>> already-run OpenDKIM Authentication-Results header is the order of
>>>> specifying the milters important?
>>>
>>> yes opendkim need to run before opendmarc, and if you have openarc  
>>> place that before opendkim, it can be messy if opendmarc checks  
>>> openarc results, remeber it also need to trust AR headers to be  
>>> considered good info
>>>
>>> but i do not use milters self, only do all i need with fuglu
>>
>> Thanks again Benny. I have policyd-spf set to insert an AR header,  
>> and OpenDMARC set to trust the Authserv-Id added in  
>> Authentication-Results headers by policyd-spf and OpenDKIM. All  
>> working nicely and good to understand the sequence.
>
> Please read CVE-2019-20790, and tell me you’ve found a way to tell  
> PyPolicyd not to trust the SMTP HELO to generate a passing AR header.
>
> -Dan
>

In the interests of open disclosure of your interests, I assume  
[hidden email] = https://github.com/thegushi = OpenDMARC  
developer?

This is possibly off-topic for the Postfix list... maybe not.

Re the risk from the CVE to my setup...

I run policyd-spf as a postfix check_policy with reject on fail (on  
both HELO and MAILFROM), and assuming a mail gets past that (99% do),  
I then use that Pass along with OpenDKIM and OpenDMARC to contribute  
to Spamassassin scoring. My DMARC Spamassassin rules do not apply a  
-ve on a pass, only a +ve on a fail.

The impact of a false pass from DMARC (particularly as our Webmail  
system - Horde - does not show any added trust for a dmarc pass) would  
be failure to apply a negative Spamassassin score from a the missed  
DMARC fail. With my mail setup and users the impact of that is  
probably manageable... but agreed it is not ideal.

What concerns me as much as anything is that each of the apps' devs in  
question (pypolicyd-spf and opendmarc) are each pointing at each other  
:-/

https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/4:
"my belief that the issue here is a DMARC processor failing to do  
alignment validation correctly"

https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-802242666
"Honestly, this CVE seems more to belong to py-policyd than OpenDMARC."

What would be nice would be if the two of you worked together on  
coming up with a fix...

Anyways...

I see two possible workarounds (not fixes).

1. Setting pypolicyd to HELO_Reject = No_Check. RFC7208 indicates that  
MAILFROM and HELO are both equally valid for an SPF result, *BUT* the  
vast majority of my SPF checks trigger pass or fail on MAILFROM (I've  
had 3 spf HELO passes in 10 days on HELO, thousands on MAILFROM).  
Testing pypolicyd-spf with HELO_reject = No_Check results in spf=none  
for those. Removing the HELO check means that OpenDMARC can assume any  
spf result it is given is based on MAILFROM.

2. Tell OpenDMARC to *NOT* trust any existing spf result and do its  
own. I.e. SPFIgnoreResults true. This obviously doubles SPF processing  
time, and relegates pypolicyd-spf to purely an inbound policy reject  
check. If one is not using pypolicyd to reject then this would be  
pointless, and it could be removed from the stack.

Thoughts?

>
>>
>> Simon.
>>
>> --
>> Simon Wilson
>> M: 0400 12 11 16


----- End message from Dan Mahoney <[hidden email]> -----



--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Dan Mahoney (Gushi)
Replied inline and snipped.  Apologies if my mail.app gets this wrong.

> On Apr 1, 2021, at 7:49 PM, Simon Wilson <[hidden email]> wrote:
>
> ----- Message from Dan Mahoney <[hidden email]> ---------
>   Date: Thu, 1 Apr 2021 16:19:05 -0700
>   From: Dan Mahoney <[hidden email]>
> Subject: Re: Milters and policy
>     To: [hidden email]
>     Cc: [hidden email]
>
>
>>> On Mar 31, 2021, at 18:23, Simon Wilson <[hidden email]> wrote:
>>>
>>> 
>>>>
>>>>> ...if multiple milters are called are they run in order specified?
>>>>>
>>>>> smtpd_milters           = inet:127.0.0.1:8891,inet:127.0.0.1:8893
>>>>
>>>> yes
>>>>
>>>>> I.e. in the example above if OpenDMARC is to see and trust an
>>>>> already-run OpenDKIM Authentication-Results header is the order of
>>>>> specifying the milters important?
>>>>
>>>> yes opendkim need to run before opendmarc, and if you have openarc place that before opendkim, it can be messy if opendmarc checks openarc results, remeber it also need to trust AR headers to be considered good info
>>>>
>>>> but i do not use milters self, only do all i need with fuglu
>>>
>>> Thanks again Benny. I have policyd-spf set to insert an AR header, and OpenDMARC set to trust the Authserv-Id added in Authentication-Results headers by policyd-spf and OpenDKIM. All working nicely and good to understand the sequence.
>>
>> Please read CVE-2019-20790, and tell me you’ve found a way to tell PyPolicyd not to trust the SMTP HELO to generate a passing AR header.
>>
>> -Dan
>>
>
> In the interests of open disclosure of your interests, I assume [hidden email] = https://github.com/thegushi = OpenDMARC developer?

Calling me a developer is a bit strong.  I’m a fairly new member of the team, mostly trying to do issue wrangling and patch management, and maybe get our mailing lists converted to something that isn’t dependent on an EOL python, but I don’t/didn’t write most of the code.  I’m mainly a sysadmin and network operator.  I am also (coincidentally) the maintainer for the FreeBSD opendmarc port, which might explain this journey.

> This is possibly off-topic for the Postfix list... maybe not.

…with tongue in cheek, I’ll take all the discussion about mail filtering over any about political correctness that’s happened this year.  That said, if people feel this is off topic, nudge me privately and I’ll take a hint.

> Re the risk from the CVE to my setup...
>
> I run policyd-spf as a postfix check_policy with reject on fail (on both HELO and MAILFROM), and assuming a mail gets past that (99% do), I then use that Pass along with OpenDKIM and OpenDMARC to contribute to Spamassassin scoring. My DMARC Spamassassin rules do not apply a -ve on a pass, only a +ve on a fail.
>
> The impact of a false pass from DMARC (particularly as our Webmail system - Horde - does not show any added trust for a dmarc pass) would be failure to apply a negative Spamassassin score from a the missed DMARC fail. With my mail setup and users the impact of that is probably manageable... but agreed it is not ideal.
>
> What concerns me as much as anything is that each of the apps' devs in question (pypolicyd-spf and opendmarc) are each pointing at each other :-/
>
> https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/4:
> "my belief that the issue here is a DMARC processor failing to do alignment validation correctly"
>
> https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-802242666
> "Honestly, this CVE seems more to belong to py-policyd than OpenDMARC."
>
> What would be nice would be if the two of you worked together on coming up with a fix...

The upcoming 1.4.1 will have a more detailed explanation of the CVE in question as we go over the decisions that we made in taking action on this.

My logic in writing up the CVE summary was: OpenDMARC is following the protocols as designed.  If an earlier milter in the chain says SPF passed, it doesn’t feel right to pick that apart and say “but did it really?”

The CVE was not “All SPF milters in all configurations allow failed authentication with opendmarc" — py-policyd was one called out specifically.  That says something to me.

> Anyways...
>
> I see two possible workarounds (not fixes).
>
> 1. Setting pypolicyd to HELO_Reject = No_Check. RFC7208 indicates that MAILFROM and HELO are both equally valid for an SPF result, *BUT* the vast majority of my SPF checks trigger pass or fail on MAILFROM (I've had 3 spf HELO passes in 10 days on HELO, thousands on MAILFROM). Testing pypolicyd-spf with HELO_reject = No_Check results in spf=none for those. Removing the HELO check means that OpenDMARC can assume any spf result it is given is based on MAILFROM.

RFC7489 Section 4.1:  "DMARC uses the result of SPF authentication of the MAIL FROM identity.”

If we’re processing SPF ourselves, this is true.  (The SPF RFC calls HELO checking optional).  If we’re parsing an earlier added header (perhaps added by a border MX), we prioritize spf=pass over other decisions.  (Perhaps this is wrong to do).

With regard to OpenDMARC, we *could* add a check on an earlier SPF header that checks *ONLY* the mail-from identity in a received-spf header.  This might be a better response to the CVE for future code, but at the very least right now a workaround and a statement is warranted.

In turn, that could lead users to point at an SPF=pass in a previous A/R or received-spf header, and complain that we’re still rejecting.  It could also lead OpenDMARC to add its own SPF A/R header with a different result than a previous one, which could greater complicate things down the chain.  Which header does a downstream filter (say, Spamd) believe?

> 2. Tell OpenDMARC to *NOT* trust any existing spf result and do its own. I.e. SPFIgnoreResults true. This obviously doubles SPF processing time, and relegates pypolicyd-spf to purely an inbound policy reject check. If one is not using pypolicyd to reject then this would be pointless, and it could be removed from the stack.

Rejecting based on an SPF policy such as -all is carefully cautioned when used with DMARC (RFC7489 10.1).  Since SPF is broken by pretty much every mailing list, and mailing lists are not SPF aware (but some ARE dmarc aware), using py-policyd to reject is probably not a great idea anyway, since as far as I know py-policyd doesn’t know how to check if a _dmarc record also exists.

Our advice to the administrators is to carefully evaluate the behavior of this software — be aware that this is a failure mode, and act accordingly.

I don’t use py-policyd, so I don’t know what else it can be used to do (for example, if it’s a general purpose wrapper like Amavis is).  I don’t feel that we should be writing documentation or suggesting specific configuration knobs for software we didn’t put out.

The CVE response is visible in the SECURITY folder in our github on the “develop” branch.  This specific callout will probably also be in the RELEASE NOTES, which we’re still writing.

Stay safe out there,

-Dan

>
> Thoughts?
>
>>
>>>
>>> Simon.
>>>
>>> --
>>> Simon Wilson
>>> M: 0400 12 11 16
>
>
> ----- End message from Dan Mahoney <[hidden email]> -----
>
>
>
> --
> Simon Wilson
> M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Simon Wilson-7
>>> Please read CVE-2019-20790, and tell me you’ve found a way to tell  
>>> PyPolicyd not to trust the SMTP HELO to generate a passing AR  
>>> header.
>
>> This is possibly off-topic for the Postfix list... maybe not.
>
> …with tongue in cheek, I’ll take all the discussion about mail  
> filtering over any about political correctness that’s happened this  
> year.  That said, if people feel this is off topic, nudge me  
> privately and I’ll take a hint.

Ditto - perhaps some of these comments are better placed at  
https://github.com/trusteddomainproject/OpenDMARC/issues/49

>> Re the risk from the CVE to my setup...
>>
>> I run policyd-spf as a postfix check_policy with reject on fail (on  
>> both HELO and MAILFROM), and assuming a mail gets past that (99%  
>> do), I then use that Pass along with OpenDKIM and OpenDMARC to  
>> contribute to Spamassassin scoring. My DMARC Spamassassin rules do  
>> not apply a -ve on a pass, only a +ve on a fail.
>>
>> The impact of a false pass from DMARC (particularly as our Webmail  
>> system - Horde - does not show any added trust for a dmarc pass)  
>> would be failure to apply a negative Spamassassin score from a the  
>> missed DMARC fail. With my mail setup and users the impact of that  
>> is probably manageable... but agreed it is not ideal.
>>
>> What concerns me as much as anything is that each of the apps' devs  
>> in question (pypolicyd-spf and opendmarc) are each pointing at each  
>> other :-/
>>
>> https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/4:
>> "my belief that the issue here is a DMARC processor failing to do  
>> alignment validation correctly"
>>
>> https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-802242666
>> "Honestly, this CVE seems more to belong to py-policyd than OpenDMARC."
>>
>> What would be nice would be if the two of you worked together on  
>> coming up with a fix...
>
> The upcoming 1.4.1 will have a more detailed explanation of the CVE  
> in question as we go over the decisions that we made in taking  
> action on this.
>
> My logic in writing up the CVE summary was: OpenDMARC is following  
> the protocols as designed.  If an earlier milter in the chain says  
> SPF passed, it doesn’t feel right to pick that apart and say “but  
> did it really?”

This is (IMO) flawed reasoning. Hear me out... :)

The *sole* scope of pypolicyd-spf is *SPF* validation at the SMTP  
transaction point. RFC7208 recommends that SPF verifiers check both  
HELO and MAIL FROM (2.3), and pypolicyd-spf provides users with the  
ability to choose whether to do MAIL FROM only or also HELO. Out of  
the box it aligns with RFC 7208's recommended approach, checking both.  
There is nothing in the SPF RFC which says *for the purposes of SPF*  
that either HELO or MAIL FROM validation is more or less valid than  
the other. As defined in SPF, both are valid. We know SPF is not  
perfect, which is why it has been extended and added to by things like  
DMARC... but remember this is at the moment *solely in context of an  
SPF policy agent*.

Pypolicyd-spf then tags what has driven the result for later use:
E.g.
Apr  3 11:19:23 emp87 policyd-spf[1336326]: prepend  
Authentication-Results: mail.simonandkate.net; spf=pass (mailfrom)
Apr  2 12:32:51 emp87 policyd-spf[1255235]: prepend  
Authentication-Results: mail.simonandkate.net; spf=pass (helo)

Whether or not MTAs upstream have enforced matches of hostname to  
EHLO, Pypolicyd-spf is meeting its defined brief. Whether or not you  
think "trusting HELO is insane" it is clearly a valid interpretation  
of the SPF RFC for an SPY policy agent to assign a pass based on HELO.  
It is *not* "a bad authentication results header" if pypolicyd-spf  
tags as such (quotes from  
https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-803634646,  
https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-800047724).

>> 1. Setting pypolicyd to HELO_Reject = No_Check. RFC7208 indicates  
>> that MAILFROM and HELO are both equally valid for an SPF result,  
>> *BUT* the vast majority of my SPF checks trigger pass or fail on  
>> MAILFROM (I've had 3 spf HELO passes in 10 days on HELO, thousands  
>> on MAILFROM). Testing pypolicyd-spf with HELO_reject = No_Check  
>> results in spf=none for those. Removing the HELO check means that  
>> OpenDMARC can assume any spf result it is given is based on MAILFROM.
>
> RFC7489 Section 4.1:  "DMARC uses the result of SPF authentication  
> of the MAIL FROM identity.”
>
> If we’re processing SPF ourselves, this is true.  (The SPF RFC calls  
> HELO checking optional).  If we’re parsing an earlier added header  
> (perhaps added by a border MX), we prioritize spf=pass over other  
> decisions.  (Perhaps this is wrong to do).
>
> With regard to OpenDMARC, we *could* add a check on an earlier SPF  
> header that checks *ONLY* the mail-from identity in a received-spf  
> header.  This might be a better response to the CVE for future code,  
> but at the very least right now a workaround and a statement is  
> warranted.

So now we come to DMARC.

The DMARC RFC7489 says at 3.1 about SPF:
"while [SPF] can authenticate either the domain that appears in the
    RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
    HELO domain, or both"

...acknowledging that a valid SPF pass can be based on HELO.

It then says (4.1) that DMARC *must only use SPF MAIL FROM* authentication:
  "DMARC uses the result of SPF authentication of the MAIL FROM identity"

pypolicyd-spf is giving OpenDMARC the necessary information to check  
whether this is achievable. Look at my example log entries as noted  
above with the prepend headers:
  spf=pass (mailfrom)
  spf=pass (helo)

OpenDMARC has the information needed to make an informed decision on  
whether the SPF pass which has been made earlier can actually be used  
in alignment with the DMARC RFC (i.e. based on MAIL FROM) or should be  
ignored (i.e. based on HELO). If OpenDMARC stops parsing at "spf=pass"  
how is that an issue with anything other than OpenDMARC? The DMARC RFC  
*explicitly* says that DMARC must only use an SPF authentication of  
MAIL FROM - It does not say that DMARC should trust an spf=pass.

Your comment: "we *could* add a check on an earlier SPF header that  
checks *ONLY* the mail-from identity in a received-spf header" strikes  
me as being the sensible fix. In fact, if OpenDMARC is *NOT* checking  
against only an SPF MAILFROM pass, perhaps you can enlighten me on how  
it is compliant with RFC7489 4.1?

> In turn, that could lead users to point at an SPF=pass in a previous  
> A/R or received-spf header, and complain that we’re still  
> rejecting.  It could also lead OpenDMARC to add its own SPF A/R  
> header with a different result than a previous one, which could  
> greater complicate things down the chain.  Which header does a  
> downstream filter (say, Spamd) believe?

Again - spf=pass is not the issue.

> Rejecting based on an SPF policy such as -all is carefully cautioned  
> when used with DMARC (RFC7489 10.1).  Since SPF is broken by pretty  
> much every mailing list, and mailing lists are not SPF aware (but  
> some ARE dmarc aware), using py-policyd to reject is probably not a  
> great idea anyway, since as far as I know py-policyd doesn’t know  
> how to check if a _dmarc record also exists.

Not true.

I currently reject SPF on fail, am on dozens of mailing lists without  
issue (I should say without *SPF* issues... ignoring issues like the  
OpenDMARC mailing list's use of deprecated TLS protocols). I usually  
get spf=none from those. I currently have only 1 dumb domain in my SPF  
skip-check whitelist (I've contacted them, no change). On my small  
server this results in (after extensive postscreen activity dropping  
about 90% of connection attempts) typically 2 or 3 SPF rejects a day  
(out of 300 to 500 emails. Of those, maybe 1 every three or four weeks  
is a false positive. Yes I could accept and pass further down the line  
for evaluation and e.g. DMARC tagging - I choose not to.

Your interpretation of RFC7489 10.1 is also flawed (again IMO)...

"Some receiver architectures might implement SPF in advance of any
    DMARC operations.  This means that a "-" prefix on a sender's SPF
    mechanism, such as "-all", could cause that rejection to go into
    effect early in handling, causing message rejection before any DMARC
    processing takes place.  Operators choosing to use "-all" should be
    aware of this."

That places the onus on domain owners, not receivers. It acknowledges  
that some receivers do SPF before DMARC and that may result in  
rejection before DMARC - it then cautions Operators to be aware of  
that risk. It is entirely valid under the SPF RFC for a receiver to  
reject messages based on an SPF Fail (RFC7208 G.2)... and I choose to  
do so before I get to DMARC.

> Our advice to the administrators is to carefully evaluate the  
> behavior of this software — be aware that this is a failure mode,  
> and act accordingly.
>
> I don’t use py-policyd, so I don’t know what else it can be used to  
> do (for example, if it’s a general purpose wrapper like Amavis is).   
> I don’t feel that we should be writing documentation or suggesting  
> specific configuration knobs for software we didn’t put out.
>
> The CVE response is visible in the SECURITY folder in our github on  
> the “develop” branch.  This specific callout will probably also be  
> in the RELEASE NOTES, which we’re still writing.
>

Fundamentally I agree with Scott Kitterman here  
(https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/3):

"If you look at https://tools.ietf.org/html/rfc7208#section-4.1 you can see
that both HELO and Mail From are treated as first class inputs to  
check_host().

 From a specification perspective, the result needs to consider what  
identity it
relates to, which is why I think ***a DMARC processor that assumes any  
reported
SPF result relates to the Mail From of the message is buggy***.

Scott K" (***emphasis added***)

Simon


--
Simon Wilson
M: 0400 12 11 16

Reply | Threaded
Open this post in threaded view
|

Re: Milters and policy

Dan Mahoney (Gushi)
On Sat, 3 Apr 2021, Simon Wilson wrote:

>>>> Please read CVE-2019-20790, and tell me you’ve found a way to tell
>>>> PyPolicyd not to trust the SMTP HELO to generate a passing AR header.
>>
>>> This is possibly off-topic for the Postfix list... maybe not.
>>
>> …with tongue in cheek, I’ll take all the discussion about mail filtering
>> over any about political correctness that’s happened this year.  That said,
>> if people feel this is off topic, nudge me privately and I’ll take a hint.
>
> Ditto - perhaps some of these comments are better placed at
> https://github.com/trusteddomainproject/OpenDMARC/issues/49
For the rest of the list, Simon and I are working quietly to the side, but
I really would like to make OpenDMARC do the fully correct thing.  My
current reading of the various specs is that there's no hard requirement
that the requisite filters *actually put enough info into the headers* to
do such a thing.

Apologies for the noise here.  It may not fully be over, but it's my hope
that the net result is good software for the internet at large.

-Dan

--

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---------------------------