Logwatch / Bugs / #106 postfix script doesn't recognize SPF fail

Bjorn - 2023-05-21

This does not appear to be a Logwatch issue. Rather, it is signalling a configuration error that needs to be fixed in the email server. My concern about processing it in Logwatch is that it would essentially bury this error.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Antonio Querubin - 2023-05-28
  
  On Sun, 21 May 2023, Bjorn wrote:
  
  This does not appear to be a Logwatch issue. Rather, it is signalling a
  configuration error that needs to be fixed in the email server. My
  concern about processing it in Logwatch is that it would essentially
  bury this error.
  
  'not authorized' means retrieved SPF records for the sender's domain
  indicate the mail should be rejected. If SPF record retrieval is failing,
  that's a different type of error message altogether.
  
  If SPF indicates reject but the mail really is legitimate, whose
  responsibility is it to fix? The receiving mail server's operator has no
  control over the sender's SPF DNS records. That corrective feedback to
  the sender's mail server (and possibly DNS) operator is best handled by
  DMARC reporting.
  
  Suppose the mail isn't legitimate, eg. a massive SPAMbot DDOS? Then SPF
  rejection is doing it's job but why would you want to explicitly list each
  reject instance in a logwatch report? Better to capture that as a
  statistic in logwatch.
  
  Antonio Querubin
  e-mail: tony@lavanauts.org
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Querubin - 2023-05-28

'not authorized' means retrieved SPF records for the sender's domain indicate the mail should be rejected. If SPF record retrieval is failing, that's a different type of error message altogether.

If SPF indicates reject but the mail really is legitimate, whose responsibility is it to fix? The receiving mail server's operator has no control over the sender's SPF DNS records. That corrective feedback to the sender's mail server (and possibly DNS) operator is best handled by DMARC reporting.

Suppose the mail isn't legitimate, eg. a massive SPAMbot DDOS? Then SPF rejection is doing it's job but why would you want to explicitly list each reject instance in a logwatch report? Better to capture that as a statistic in logwatch.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bjorn - 2023-05-28

Got it - I thought those error messages were as an originating email sender, not as a receiving email server.

The postfix script does process some SPF log statements, but apparently not the ones you posted. Looking through the postfix script code, it appears to not expect the "5.7.23" enhance code. Is that a customization?

I don't use Postfix, so don't know what the standard behavior is, nor can I test it. But it seems that the attached patch might fix it. But let us know how the "5.7.23" got added,. and if the patch worked.

postfix.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bjorn - 2023-07-22

status: open --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bjorn - 2023-07-22

Patch incorporated in 7.9, allowing enhanced codes for those log statements.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

postfix script doesn't recognize SPF fail - not authorized

Group

Searches

Help

#106 postfix script doesn't recognize SPF fail - not authorized

Discussion