On Mon 04/03/2024 at 12:50, Andy Smith via mailop wrote:
> This best practices document is going to get out of date and be hard
> to maintain. Maybe we should make it a wiki? I am happy to help
> technically but I don't relish trying to navigate inevitable issues
> of disagreement between us all
On Mon 04/03/2024 at 01:41, Gareth Evans wrote:
> ...
> It seems FCrDNS (aka iprev) requires that
>
> "a given IP address has both forward (name-to-address) and reverse
> (address-to-name) [DNS] entries that match each other ... the forward
> and reverse lookup for the sending relay have to
From
https://www.mailop.org/best-practices
"Having SPF for your own domains is usually considered a weak signal ..."
Eh?
"... as is filtering on them"
Such as DNS filtering per
https://www.ionos.co.uk/digitalguide/server/security/dns-filtering ?
Can anyone add a little more
On Mon 04/03/2024 at 01:05, Benny Pedersen via mailop wrote:
> Gareth Evans via mailop skrev den 2024-03-04 01:17:
>
>> Received: from atlas.bondproducts.com (unknown [23.24.6.165])
>> by mx6.messagingengine.com (Postfix) with ESMTP id ...
>
> https://multir
On Sun 03/03/2024 at 18:55, Andy Smith via mailop wrote:
> Hi,
>
> On Sun, Mar 03, 2024 at 05:23:22PM +0000, Gareth Evans via mailop wrote:
>> (Error NOERROR looking up 23.24.6.165 PTR,Error Error NXDOMAIN looking
>> up 23-24-6-165-static.hfc.comcastbusiness.net. A l
On Mon 04/03/2024 at 00:17, Gareth Evans wrote:
> if the IP actually resolved.
If the host/domain actually resolved.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
I am dealing with a correspondent whose "ultimate" sending mail server's PTR
record contains a non-existent host. This is preventing delivery to gmail.
In this case (headers from a message received elsewhere):
--
Authentication-Results: mx6.messagingengine.com;
[...]
iprev=fail
