Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Slavko via mailop 
Dňa 6. októbra 2023 13:29:36 UTC používateľ Bernardo Reino via mailop 
 napísal:

>This is unrelated, but yes, I believe DMARC considers that when deciding 
>when/whom to send the reports.

You can omit the believe, rspamd does that checks. i have
mentioned gmx.* domains in noReportSend list due that
(beside others)...

It has other bug with opposite efect. If one send emails from
subdomain, and that subdomain has own DMARC record
(what is good practice IMO), rspamd will try to use base
domain's record to send reports. Thus reports can be not
send, eg. if base domain has not DMARC record at all. But
it was addressed recently and i hope that will be fixed in
next version...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Bernardo Reino via mailop 

On Fri, 6 Oct 2023, Gellner, Oliver via mailop wrote:


On 06.10.2023 at 20:19 Bernardo Reino via mailop wrote:


On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote:

I trust that you are applying RFC 7489 section 7.1. where appropriate.
If the domain for dmarc reports is not the same as the requesting
domain, you must check that the report domain is willing to accept these 
reports.



[..]

[*] for an example of a big server not doing this (i.e. not publishing 
the proper records) see gmx.net, where e.g. gmx.net says that reports should 
go to dmarcrep...@gmx.net, but the corresponding _report._dmarc TXT record is 
nowhere to be found.


Agreed, except that gmx.net does publish _report records. Not for gmx.net 
itself, but this is not an external domain, so no _report record is necessary.


Oops, you're absolutely right. Thank you!

I had in memory that this wasn't the case (I think I even wrote here some time 
ago about gmx.ch not having a corresponding gmx.ch._report._dmarc.gmx.net TXT 
record), but apparently this is not the case anymore (kudos to gmx!)


Other than that broken DMARC setups seem somewhat common among SMB. Outright 
rejections as in the case of github.com are at least simple to handle. Worse 
are receivers who stuff the DMARC reports into ticketing systems or whatever 
and then come after you with multiple emails about ticket creation, survey 
requests and reminders.


+1
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Gellner, Oliver via mailop 
On 06.10.2023 at 20:19 Bernardo Reino via mailop wrote:

>> On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote:
>>
>> I trust that you are applying RFC 7489 section 7.1. where appropriate.
>> If the domain for dmarc reports is not the same as the requesting
>> domain, you must check that the report domain is willing to accept these 
>> reports.

>This is unrelated, but yes, I believe DMARC considers that when deciding 
>when/whom to send the reports.
> In this case,

> $ dig +short TXT _dmarc.github.com
> "v=DMARC1; p=reject; pct=100; rua=mailto:dm...@github.com;

> so reports for "github.com" are sent to a @github.com address, so it's not an 
> "external destination" in the sense of RFC7489 [*]
> It just so happens that the MX for github.com is google, but that should not 
> have any impact -- aside from the fact that google seems to apply 
> "organizational settings" or policies that effectively prevent the report 
> from being delivered, but whether this is google's fault or (in this case) 
> github's is something that I, as a sender, cannot know..
> [*] for an example of a big server not doing this (i.e. not publishing the 
> proper records) see gmx.net, where e.g. gmx.net says that reports should go 
> to dmarcrep...@gmx.net, but the corresponding _report._dmarc TXT record is 
> nowhere to be found.

Agreed, except that gmx.net does publish _report records. Not for gmx.net 
itself, but this is not an external domain, so no _report record is necessary.
Other than that broken DMARC setups seem somewhat common among SMB. Outright 
rejections as in the case of github.com are at least simple to handle. Worse 
are receivers who stuff the DMARC reports into ticketing systems or whatever 
and then come after you with multiple emails about ticket creation, survey 
requests and reminders.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Bernardo Reino via mailop 
Sorry for the additional noise, but I wrote "DMARC considers" where I meant 
"RSPAMD considers" :(


On Fri, 6 Oct 2023, Bernardo Reino via mailop wrote:

This is unrelated, but yes, I believe RSPAMD considers that when deciding 
when/whom to send the reports.


[...]

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Bernardo Reino via mailop 

On Fri, 6 Oct 2023, Andrew C Aitchison via mailop wrote:


On Thu, 5 Oct 2023, Bernardo Reino via mailop wrote:


 On Thu, 5 Oct 2023, Slavko via mailop wrote:


 Dňa 2. 10. o 18:34 Brandon Long via mailop napísal(a):

  I've raised a bug to take a look, this looks like a too broad dkim
  replay
  rule.


 I am not sure if that is the same, but in last two days i see these
 bounces from github's DMARC rua address for my DMARC reports:

** Message blocked **

 Your message to dm...@github.com has been blocked. See technical
 details below for more information.

The response was:

Message bounced due to organizational settings.

 The latest one contains in message/delivery-status (if that helps):

 Reporting-MTA: dns; googlemail.com
 Received-From-MTA: dns; prvs=064225bada=dmarc_rp...@slavino.sk
 Arrival-Date: Wed, 04 Oct 2023 18:21:05 -0700 (PDT)
 X-Original-Message-ID: <84e154c2366c2...@primex.skk>

 Final-Recipient: rfc822; dm...@github.com
 Action: failed
 Status: 4.4.2
 Diagnostic-Code: smtp; Message bounced due to organizational
 settings.
 Last-Attempt-Date: Wed, 04 Oct 2023 18:21:06 -0700 (PDT)


 I have the same issue. Unfortunately there's a lot of servers which
 request DMARC reports, but then outright reject them (or use an invalid
 address).

 My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing,
 slowly.


I trust that you are applying RFC 7489 section 7.1. where appropriate.
If the domain for dmarc reports is not the same as the requesting domain,
you must check that the report domain is willing to accept these reports.


This is unrelated, but yes, I believe DMARC considers that when deciding 
when/whom to send the reports.


In this case,

$ dig +short TXT _dmarc.github.com
"v=DMARC1; p=reject; pct=100; rua=mailto:dm...@github.com;

so reports for "github.com" are sent to a @github.com address, so it's not an 
"external destination" in the sense of RFC7489 [*]


It just so happens that the MX for github.com is google, but that should not 
have any impact -- aside from the fact that google seems to apply 
"organizational settings" or policies that effectively prevent the report from 
being delivered, but whether this is google's fault or (in this case) github's 
is something that I, as a sender, cannot know..


[*] for an example of a big server not doing this (i.e. not publishing the 
proper records) see gmx.net, where e.g. gmx.net says that reports should go to 
dmarcrep...@gmx.net, but the corresponding _report._dmarc TXT record is nowhere 
to be found.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] DMARC report rejections - was Re: Recent increase in GMail 421-4.7.28 responses

2023-10-06 Thread Andrew C Aitchison via mailop 

On Thu, 5 Oct 2023, Bernardo Reino via mailop wrote:


On Thu, 5 Oct 2023, Slavko via mailop wrote:


Dňa 2. 10. o 18:34 Brandon Long via mailop napísal(a):

 I've raised a bug to take a look, this looks like a too broad dkim replay
 rule.


I am not sure if that is the same, but in last two days i see these bounces 
from github's DMARC rua address for my DMARC reports:


   ** Message blocked **

Your message to dm...@github.com has been blocked. See technical
details below for more information.

   The response was:

   Message bounced due to organizational settings.

The latest one contains in message/delivery-status (if that helps):

Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; prvs=064225bada=dmarc_rp...@slavino.sk
Arrival-Date: Wed, 04 Oct 2023 18:21:05 -0700 (PDT)
X-Original-Message-ID: <84e154c2366c2...@primex.skk>

Final-Recipient: rfc822; dm...@github.com
Action: failed
Status: 4.4.2
Diagnostic-Code: smtp; Message bounced due to organizational
settings.
Last-Attempt-Date: Wed, 04 Oct 2023 18:21:06 -0700 (PDT)


I have the same issue. Unfortunately there's a lot of servers which request 
DMARC reports, but then outright reject them (or use an invalid address).


My list of no_dmarc_reporting_domains.txt (in RSPAMD) keeps growing, slowly.


I trust that you are applying RFC 7489 section 7.1. where appropriate.
If the domain for dmarc reports is not the same as the requesting domain,
you must check that the report domain is willing to accept these reports.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop