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

[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

[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

[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

[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

[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

[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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Jaroslaw Rafa via mailop]

Dnia  6.10.2023 o godz. 13:41:06 Marco via mailop pisze:
> > As does the standard mechanism used in browers for dealing with the
> > same type of situation.
> 
> Although they try IPv6 first and don't do a "protocol balancing", at
> least I haven't experienced that yet.

One can configure Postfix do do that. If someone doesn't configure this,
probably he/she is OK with the current behavior.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Am 06.10.2023 schrieb Stuart Henderson :

> On 2023/10/06 13:08, Marco via mailop wrote:
> > Am 06.10.2023 schrieb Bjørn Bürger via mailop :
> >   
> > > 15 yrs ago I would have agreed to Wietse Venemas view, but
> > > nowadays this kind of "solution" is just adding confusion and
> > > makes debugging harder for everyone, unfortunately.   
> > 
> > And sadly it creates a comfortable solution for admins of
> > non-functional networks instead of fixing stuff.  
> 
> As does the standard mechanism used in browers for dealing with the
> same type of situation.

Although they try IPv6 first and don't do a "protocol balancing", at
least I haven't experienced that yet.

> RFC 8305 9.3 has a suggested approach to dealing with this.

|   The algorithm proceeds as follows: if a positive  response (a
|   response with at least one valid  record) is received first, the
|   first IPv6 connection attempt is immediately started.  If a positive
|   A response is received first due to reordering, the client SHOULD
|   wait a short time for the  response to ensure that preference is
|   given to IPv6 (it is common for the  response to follow the A
|   response by a few milliseconds).

For me that read more like "try IPv6 first and fallback to IPv4 quick
if IPv6 doesn't work".
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Stuart Henderson via mailop]

On 2023/10/06 13:08, Marco via mailop wrote:
> Am 06.10.2023 schrieb Bjørn Bürger via mailop :
> 
> > 15 yrs ago I would have agreed to Wietse Venemas view, but nowadays
> > this kind of "solution" is just adding confusion and makes debugging
> > harder for everyone, unfortunately. 
> 
> And sadly it creates a comfortable solution for admins of non-functional
> networks instead of fixing stuff.

As does the standard mechanism used in browers for dealing with the
same type of situation.

RFC 8305 9.3 has a suggested approach to dealing with this.

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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Am 06.10.2023 schrieb Bjørn Bürger via mailop :

> 15 yrs ago I would have agreed to Wietse Venemas view, but nowadays
> this kind of "solution" is just adding confusion and makes debugging
> harder for everyone, unfortunately. 

And sadly it creates a comfortable solution for admins of non-functional
networks instead of fixing stuff.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recent increase in GMail 421-4.7.28 responses

[Slavko via mailop]

Dňa 6. 10. o 9:39 Marco via mailop napísal(a):

Am 06.10.2023 schrieb Slavko via mailop :


But this is not usual SPAM with fake or misconfigured rua mailbox, it
is domain (github.com) where i send reports for long time and only
last days it  returns NDR...


Have you tried to inform the postmaster of them to notice about the
problem?


Not yet, if problem will persist for more days, i will try it.

regards

--
Slavko

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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Stuart Henderson via mailop]

On 2023/10/06 11:13, Marco via mailop wrote:
> Am 06.10.2023 schrieb Stuart Henderson :
> 
> > Networks single-homed behind cogent can't connect to networks
> > single-homed behind he.net and vice-versa.
> 
> Is that related to PMTU-blackhole?
> Who is guilty for that?
> Why isn't that going to be fixed?

No, that's due to commercial policies of the companies. Nothing to do
with PMTU-blackhole in that case. It's been like it for years.

(And btw, MTU issues with PMTU blackhole mean that the connection
can succeed but delivery fails - so using a short connection timeout
does not help).

In any event, even without any of these problems, it is easily possible
to have an outage which affects only one of v4+v6. It's nice to still
have semi-working email when that happens (especially if email is needed
to get such an outage fixed!)

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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Bjørn Bürger via mailop]

Am 6. Oktober 2023 11:31:05 MESZ schrieb Jaroslaw Rafa via mailop 
:
>Here's a quite recent explanation from Postfix author, Wietse Venema

Ah, thanks. 

15 yrs ago I would have agreed to Wietse Venemas view, but nowadays this kind 
of "solution" is just adding confusion and makes debugging harder for everyone, 
unfortunately. 

Bjørn 


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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Am 06.10.2023 schrieb Bjørn Bürger via mailop :

> Some MTAs, like postfix for example, do load balancing across ip
> protocols. I have no idea, why they think, this might be a good idea,
> though.

At least sendmail doesn't seem to do that. :-)
I can understand very low timeouts for IPv6 and fast fallbacks and even
statistics for time-outs, so the servers won't be probed with IPv6
again for a certain amount of time, but I cannot see any reason for
balancing of IPv4 and IPv6 if a server offers both.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Jaroslaw Rafa via mailop]

Dnia  6.10.2023 o godz. 11:00:27 Bjørn Bürger via mailop pisze:
> 
> Some MTAs, like postfix for example, do load balancing across ip
> protocols. I have no idea, why they think, this might be a good idea,
> though. It's quite annoying.

Here's a quite recent explanation from Postfix author, Wietse Venema, sent
to Postfix mailing list in response to someone who (similarly to you)
complained, why Postfix doesn't do IPv6-only deliveries if the target host
has an IPv6 address:

==
The purpose of Postfix is to deliver mail, not to achieve world
domination for a particular IP protocol.

If a destination has IPv4 and IPv6 addresses, then an explicit
preference for one protocol type means that ALL DELIVERIES will
suffer delays when that protocol type has an outage.

Whereas with Postfix default settings, about half of deliveries
will be slow when one of those protocols has an outage (Postfix is
smart enough to use similar numbers of IPv6 and IPv4 addressess,
to avoid huge delays when, for example, a site has many IPvX and
few IPvY addresses, and IPvX has an outage, for {X=4, Y=6} or {X=6,
Y=4}).

For me, availability matters more than protocol religion.
==
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Jaroslaw Rafa via mailop]

Dnia  6.10.2023 o godz. 11:01:10 Marco via mailop pisze:
> > https://www.postfix.org/postconf.5.html#smtp_address_preference
> > https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols
> 
> Does the balancing test IPv6 first or is it just randomly?
> Does it use the first address that works?

It depends on the config setting set by server admin. May try IPv6 first,
may try IPv4 first. Yes, the first one that works is used.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Am 06.10.2023 schrieb Stuart Henderson :

> Networks single-homed behind cogent can't connect to networks
> single-homed behind he.net and vice-versa.

Is that related to PMTU-blackhole?
Who is guilty for that?
Why isn't that going to be fixed?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Stuart Henderson via mailop]

On 2023/10/06 11:01, Marco wrote:
> Am 06.10.2023 schrieb Stuart Henderson :
> 
> > On 2023/10/06 10:09, Marco via mailop wrote:
> > > Hello!
> > > 
> > > I have an IPv6 and IPv4 accessible server, both protocols work and I
> > > receive mails with IPv6 too.
> > > Although, I see that certain IPv6 capable servers send with IPv4 in
> > > some cases.
> > > I am not aware of any outages and the strange things is it is rather
> > > random which protocol they use.
> > > 
> > > relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6,
> > > but I can send to them via IPv6
> > > relay=bendel.debian.org [82.195.75.100]
> > > relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002]
> > > 
> > > What can be the reason for that?  
> > 
> > Postfix balances address families by default to avoid blockages if one
> > isn't working:
> 
> Isn't a timeout of some seconds enough for that?
> 
> Most people have a working connection and most servers too.

Define "working"... There are still more MTU blackhole issues with v6
than v4. Networks single-homed behind cogent can't connect to networks
single-homed behind he.net and vice-versa. There can be different
treatment by spam filtering etc (even if purely by virtue of one address
family having working reverse dns and the other not). And it works both
ways: v6 may be working but v4 not.

> > https://www.postfix.org/postconf.5.html#smtp_address_preference
> > https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols
> 
> Does the balancing test IPv6 first or is it just randomly?
> Does it use the first address that works?
> 
> Then that explains the behaviour.

Default is to select randomly (see the postconf(5) sections that I linked).

> > Perhaps some other MTAs have similar too.
> 
> All of the MTAs that create that effect use Postfix, so it seems to be
> related to it.

Perhaps it is the only one with the balancing feature then..
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Bjørn Bürger via mailop]

Am 6. Oktober 2023 10:09:23 MESZ schrieb Marco via mailop :
>Although, I see that certain IPv6 capable servers send with IPv4 in
>some cases.
> (...)
>I am not aware of any outages and the strange things is it is rather
>random which protocol they use.
>
>What can be the reason for that?

Some MTAs, like postfix for example, do load balancing across ip protocols. I 
have no idea, why they think, this might be a good idea, though. It's quite 
annoying.

Bjørn 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Stuart Henderson via mailop]

On 2023/10/06 10:09, Marco via mailop wrote:
> Hello!
> 
> I have an IPv6 and IPv4 accessible server, both protocols work and I
> receive mails with IPv6 too.
> Although, I see that certain IPv6 capable servers send with IPv4 in
> some cases.
> I am not aware of any outages and the strange things is it is rather
> random which protocol they use.
> 
> relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6, but
> I can send to them via IPv6
> relay=bendel.debian.org [82.195.75.100]
> relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002]
> 
> What can be the reason for that?

Postfix balances address families by default to avoid blockages if one
isn't working:

https://www.postfix.org/postconf.5.html#smtp_address_preference
https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols

Perhaps some other MTAs have similar too.

Some admins disable delivery over v6 completely because some receiving
sites are suspected to apply more stringent checks to mail coming
in over v6. Some just do this for specific sites (e.g. as shown in
https://www.postfix.org/postconf.5.html#smtp_dns_reply_filter),
some for everything.

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

Re: [mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Am 06.10.2023 schrieb Stuart Henderson :

> On 2023/10/06 10:09, Marco via mailop wrote:
> > Hello!
> > 
> > I have an IPv6 and IPv4 accessible server, both protocols work and I
> > receive mails with IPv6 too.
> > Although, I see that certain IPv6 capable servers send with IPv4 in
> > some cases.
> > I am not aware of any outages and the strange things is it is rather
> > random which protocol they use.
> > 
> > relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6,
> > but I can send to them via IPv6
> > relay=bendel.debian.org [82.195.75.100]
> > relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002]
> > 
> > What can be the reason for that?  
> 
> Postfix balances address families by default to avoid blockages if one
> isn't working:

Isn't a timeout of some seconds enough for that?

Most people have a working connection and most servers too.

> https://www.postfix.org/postconf.5.html#smtp_address_preference
> https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols

Does the balancing test IPv6 first or is it just randomly?
Does it use the first address that works?

Then that explains the behaviour.

> Perhaps some other MTAs have similar too.

All of the MTAs that create that effect use Postfix, so it seems to be
related to it.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recent increase in GMail 421-4.7.28 responses

[Bernardo Reino via mailop]

On Fri, 6 Oct 2023, Slavko via mailop wrote:


Dňa 5. 10. o 9:58 Bernardo Reino via mailop napísal(a):


 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.


But this is not usual SPAM with fake or misconfigured rua mailbox, it is 
domain (github.com) where i send reports for long time and only last days it 
returns NDR...


Yes, I also meant github. RSPAMD happens to be, in my case, the tool that takes 
care of DMARC reporting.


Its settings is strange in result, as they ask report and then refuse to 
delivery it.


Exactly. This happens often with servers (the two latest examples in my 
logs are github.com and mailinblue.com) which use a rua hosted at google, which 
then reject the messages (DMARC reports) because of a "policy that prohibited 
the mail that you sent" or "due to organizational settings".


Others simply don't bother/care and use an invalid rua..

I guess that e-mail is not only getting harder for private servers, but also for 
bigger ("professional") ones ¯\_(ツ)_/¯.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] IPv6 capable servers send with IPv4 to me

[Marco via mailop]

Hello!

I have an IPv6 and IPv4 accessible server, both protocols work and I
receive mails with IPv6 too.
Although, I see that certain IPv6 capable servers send with IPv4 in
some cases.
I am not aware of any outages and the strange things is it is rather
random which protocol they use.

relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6, but
I can send to them via IPv6
relay=bendel.debian.org [82.195.75.100]
relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002]

What can be the reason for that?

-- 
kind regards
Marco
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recent increase in GMail 421-4.7.28 responses

[Marco via mailop]

Am 06.10.2023 schrieb Slavko via mailop :

> Dňa 5. 10. o 9:58 Bernardo Reino via mailop napísal(a):
> 
> > 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.  
> 
> But this is not usual SPAM with fake or misconfigured rua mailbox, it
> is domain (github.com) where i send reports for long time and only
> last days it  returns NDR...
> 
> Its settings is strange in result, as they ask report and then refuse
> to delivery it.

Have you tried to inform the postmaster of them to notice about the
problem?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recent increase in GMail 421-4.7.28 responses

[Slavko via mailop]

Dňa 5. 10. o 9:58 Bernardo Reino via mailop napísal(a):

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.


But this is not usual SPAM with fake or misconfigured rua mailbox, it is 
domain (github.com) where i send reports for long time and only last 
days it  returns NDR...


Its settings is strange in result, as they ask report and then refuse to 
delivery it.


regards

--
Slavko

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